Building Engineering Runtime with AI — and designing it for an AI-first world

October 28, 2026 · Kishore Babu Gutta

When I started Engineering Runtime (ENGRT), I expected AI to help me write software faster.

It did. But learning how coding agents, models and tool interfaces work changed something more fundamental: how I design the product, how I build it, and how I think engineers may eventually evaluate it.

ENGRT is an execution layer for engineering operations. A human, CI job or AI agent can request work; the Runtime is meant to apply consistent controls for authority, policy, execution and evidence. It is not an AI model, and an agent's confidence is never a substitute for verification.

The most interesting lesson from building it with AI is not that one person can generate more code. It is that a product can be designed from the beginning for people who may approach it through their own AI assistants.

That second idea is a direction I want to test, not a customer result I can claim today.

What I actually use AI for as the builder

I use agents to help research technologies, challenge architecture decisions, refine proposals, implement bounded changes, review code, write documentation and investigate failures.

The workflow has taught me to separate an agent producing work from that work being accepted:

1. Research or dogfooding identifies a problem.
2. I decide whether it belongs in the product and what the intended outcome is.
3. An agent can prepare a proposal or implementation against that scope.
4. Tests and hands-on qualification determine what actually works.
5. Only reviewed evidence should justify release claims.

I keep decisions, issues, pull requests and evidence in durable repositories rather than relying on an agent remembering an earlier conversation. When one session ends, another can inspect the written record. That does not eliminate human decisions; it makes their history inspectable.

This is founder-reported experience from building ENGRT. It is not evidence that an unrelated customer can reproduce the whole process without guidance.

Seven layers of AI leverage

I now think about AI across a wider product lifecycle. Some parts are already in my own working process; others are hypotheses for an external user journey.

Layer	Where AI could help	Present status and accountability
Founder	Research, compare approaches, challenge decisions	Used in my workflow; I retain product judgment
Engineering	Implement, review, test and document	Used in my workflow; code review and qualification remain necessary
Product	Help understand and invoke version-specific operations	Early Runtime and capability flows exist; supported scope depends on the release
Distribution	Explain the product from public pages	I've explored how assistants interpret the website; discoverability is not adoption
Evaluation	Help an unfamiliar engineer investigate and trial ENGRT	A proposed customer-side experiment, not a completed design-partner result
Adoption	Interpret trial evidence and operational trade-offs	A human or enterprise decision, not an automated conversion
Learning	Turn failures and feedback into better product decisions	An ongoing process; improvements need independent verification

These are not seven autonomous products. They are seven places where AI may reduce repeated work without moving responsibility away from the engineer, customer or product owner.

The two sides of an AI-first engineering product

There is an important difference between the agent helping me build ENGRT and an agent helping someone else evaluate ENGRT.

My agents have project history, repository context and many iterations of working knowledge. A new engineer's agent should not need any of those private inputs.

It should start with the same public website and documentation that a person can read. It should understand which version is available, which providers and operations are supported, what still requires qualification, and how to reach the next safe step.

An agent explaining a website accurately is a useful content test. It is not proof that an engineer can install, evaluate or benefit from the product.

For the latter, the relevant question is whether an unfamiliar engineer can use ENGRT to achieve one real, independently verified engineering outcome.

A runtime that describes the version actually installed

AI models may remember outdated syntax. Engineering tools change faster than model training data.

That is why ENGRT's self-describing direction matters to me: the installed Runtime can provide version-aligned authoring information instead of forcing an assistant to guess the capability grammar. The exact supported interface and prerequisites should always come from the current documentation and the installed release.

I want assistants to read the available contract, find an existing capability where possible, and only author what is missing.

But knowing the grammar is not authority to execute. Authentication, target context, policy, compiled safety and verification remain distinct concerns. A newly written capability must not gain privileges simply because an agent created it.

Nor does a file or environment variable automatically isolate credentials from an agent with access to the same process or filesystem. Real deployment boundaries have to be tested, not assumed.

The customer experiment I want to run

Imagine an engineer asks their agent:

Can Engineering Runtime help our team review and enforce GitHub repository standards?

A credible first trial would be intentionally narrow:

1. The agent reads the public product documentation and identifies what is released, limited or unsupported.
2. The engineer approves an installation, a test repository and the specific access scope.
3. The agent inspects the installed Runtime contract and selects or proposes a suitable capability.
4. It starts with a low-risk read-only operation, then seeks explicit approval before any permitted mutation.
5. ENGRT performs the supported operation under its declared controls, and the evaluator reads the actual result.
6. Where the capability supports authoritative verification, the evaluator checks provider state independently and reviews retained evidence.
7. The engineer decides whether the experience solved a real problem better than their existing approach.

This is a proposed design-partner evaluation, not a report of one that has taken place. GitHub coverage, supported transports, safety behaviour and reconciliation all depend on the particular operation and qualified Runtime version. ENGRT does not make arbitrary workflows automatically safe or retryable.

Evidence matters more than a polished AI explanation

For that experiment, I would measure time to a verified outcome, incorrect assumptions, installation and identity friction, human interventions, unsupported operations, security boundaries and whether the evaluator wants to use the capability again.

A successful generated script or confident model response would not be enough. I would want actual provider read-back where supported, transparent failures, bounded credentials and a result another engineer can inspect.

In particular, I would not treat website crawler activity, an assistant mentioning ENGRT, or my own dogfooding as customer adoption or independent product validation.

That is the gap between an interesting product story and a trustworthy engineering outcome.

Where this leads

AI has already changed how I work on ENGRT: research, engineering, review and learning have become more connected to durable records and explicit evidence.

What remains to prove is whether this also makes ENGRT easier for a new engineer to discover, evaluate and operate with an unfamiliar agent. That requires real external trials and honest documentation of what fails.

I want to build a product that engineers can trust, regardless of whether the request starts in a terminal, pipeline or AI conversation.

Humans decide. Agents help. ENGRT governs execution. Evidence closes the loop.

For the current release, supported operations and limitations, see Engineering Runtime releases and the technical documentation. If your team wants to discuss a bounded evaluation, get in touch.