The AI-Native Delivery System: Why Coding Agents Expose Weak Engineering Practices

Published: at 01:35 AMSuggest Changes

The engineering director has a problem that looks like good news. Her teams can now turn a written issue into a pull request before the product manager has moved to the next meeting. Yet the review queue is growing and the people who understand older services carry more risk. Code has become cheap. Confidence has not.

That is the operating tension behind coding agents. They increase implementation choices; they do not settle the business decision, prove a change safe, or carry the pager when it fails. A weak delivery system therefore becomes visible sooner. Ambiguous requirements become executable ambiguity. Thin tests give generated changes a clean-looking but fragile path through CI. A risky release process receives risky releases more quickly.

A CTO should treat this as a delivery-system decision, not a tooling procurement exercise. The question is whether the organisation can convert a larger volume of machine-produced change into customer value without consuming its most experienced engineers in review, recovery and explanation.

DORA’s 2025 research is a useful corrective to the sales pitch. It describes AI as an amplifier of organisational strengths and weaknesses, associating adoption with improved throughput and product performance while finding a negative relationship with delivery stability. That does not make coding agents inherently destabilising. It shows where higher change velocity places pressure: version control, test quality, architectural boundaries, release practice and production feedback. DORA

An AI-native delivery system is a deliberate response to that pressure. It gives agents bounded work, gives engineers evidence they can trust, and gives leaders a way to decide where autonomy has earned the right to grow.

The bottleneck has moved into plain sight

Writing code was never the only constraint on delivery. Work waits for a decision, a usable specification, access to an environment, a security approval, a reviewer, a test run or a safe deployment window. In slower teams, those waits were easy to hide behind the visible effort of implementation. An agent removes some of that cover.

The predictable mistake is to count agent output as delivery progress. A team can close more pull requests while lead time rises, reviewers become a bottleneck, defect escape increases and incident work eats the apparent gain. The system has transferred work downstream to people least able to absorb it.

Measure the route from an agreed problem to a stable result in production. Include rework, review latency, deployment success, recovery time and the customer outcome. That is the unit of performance an engineering leader owns.

Give the agent a task contract, not a vague instruction

The improvement is unglamorous: make work explicit enough that a good human team could deliver it predictably. Every agent-assigned task needs a problem statement, acceptance criteria, relevant domain rules, non-functional constraints and a named owner for the outcome. It must also define the point at which the agent stops and a person decides.

A sound task contract states:

This is a practical control over freedom of action. Without it, an agent can select a locally plausible solution that breaks a domain rule, introduces an unsuitable dependency or expands into a cross-cutting refactor nobody intended. The reviewer then has to reconstruct the requirement from the code, which is an expensive way to discover that the work was poorly framed.

It also identifies work that should remain human-led. A thin slice through a poorly understood legacy domain may need discovery, a clear seam and an architectural decision before it needs implementation assistance. Sending an agent into that codebase with a broad request is a fast route to plausible output and slow learning.

GitHub’s own description of coding agents is telling: an agent can explore a repository, write code, pass tests and open a pull request for review. The final stage matters. Passing the tests available to an agent is evidence; it is not a transfer of accountability. Review still establishes whether the change addresses the intended problem, respects the architecture and can be operated safely. GitHub

Treat context as a platform product

Experienced engineers carry context that rarely lives in one place: why a boundary exists, which field is sensitive, where an earlier incident began, which workaround is temporary and which integration partner behaves strangely under load. An agent only has what the task provides or what it is allowed to retrieve.

Too many enterprises answer this by granting broad repository and knowledge-base access. More material can mean more noise, stale guidance and a wider security exposure. A large, uncurated corpus is not context. It is a search result with credentials attached.

Platform teams should make trusted engineering context easy to consume close to the work: versioned architectural decision records, ownership maps, API contracts, approved libraries, coding standards, threat models and operational runbooks. Each source should show its provenance and currency. Agent identities need the least privilege required for the task, with separate permissions for reading documentation, changing code, using build systems and touching deployment paths.

DORA’s AI Capabilities Model distinguishes a healthy data ecosystem from AI-accessible internal data. The point is not to connect every source. It is to make high-quality, accessible and appropriately governed context available in the delivery flow. DORA AI Capabilities Model

Small batches are now a hard control

A coding agent can produce a change far too large to understand before a reviewer has opened the first file. Constrain the unit of change: separate schema migration, contract change, behavioural logic and interface work where the architecture permits. Use feature flags for incomplete paths. Require each production change to identify its rollback method before it enters the release queue.

Small batches are often described as a flow preference. With coding agents, they are a control. They provide a bounded working area for the agent, a comprehensible review surface for engineers and a precise failure signal for operations. When a release degrades a service, the team should be able to isolate and reverse one well-described change rather than untangle a week of generated output.

DORA identifies small batches, robust version control and rollback practice as capabilities that amplify beneficial AI effects. That is not process nostalgia. It is the mechanism by which a business keeps the option to learn without paying for every experiment in production.

Build the safety net to match the authority

Start with the paths where failure has material consequences: authentication and authorisation, payment or pricing logic, regulated reporting, privacy boundaries, destructive actions and production infrastructure. For each, establish evidence at the level that can actually fail. Local logic needs unit tests. Service boundaries need contract tests. Data and permission flows need integration tests. A small number of end-to-end checks should confirm the customer journey. Production needs service-level objectives, meaningful alerts, traces and business signals that reveal harm quickly.

Then apply proportionate policy. An agent may draft documentation, improve tests or remediate a defined category of static-analysis finding with low friction. Changes to identity controls, customer data, payment flows or infrastructure require named approval and stronger evidence. Dependency scanning, secret detection, licence policy and infrastructure checks belong in the ordinary pipeline. An “AI-generated” label must never become a route around the secure development lifecycle.

The practical test is severe: can the team detect, contain and reverse a bad agent-assisted change before it becomes a customer incident? If it cannot, increasing autonomous scope is an act of faith rather than engineering.

Review is a capacity design problem

Agents reduce the cost of producing code. They do not reduce the cost of proving that code deserves to run. Review debt therefore needs more than a new pull-request template.

Different changes require different forms of attention. A peer assesses intent, maintainability and local design. A domain owner checks policy and business semantics. Automated security and platform controls provide repeatable evidence. Operations confirms release readiness and observes the outcome. High-risk work should be routed intentionally through these responsibilities, rather than arriving by accident in the queue of the one senior engineer everyone trusts.

Make the agent’s contribution inspectable. The pull request should include a concise task summary, the internal sources consulted, files and permissions touched, tests run, known limitations and the rollback route. A full transcript is rarely useful. The accountable engineer needs enough evidence to understand the decision without conducting digital archaeology.

One practical case illustrates the point. A team using an agent to remediate a known static-analysis category can define the files in scope, approved fix pattern, test command and maximum change size. Review becomes confirmation of a bounded intervention.

Protecting senior engineers is a leadership responsibility. Pairing, architecture clinics and review rotation can distribute judgement, but the durable answer lies upstream: better task contracts, smaller changes, reliable guardrails and clear ownership. When generated work repeatedly requires heroic review, the delivery system is asking people to compensate for a design defect.

Scale on evidence, then use one leadership test

Start with a workflow where feedback is fast and the blast radius is contained: test creation for a bounded service, a well-understood internal integration, or remediation of a defined static-analysis category. Establish a baseline for lead time, rework, deployment success, recovery time and the relevant user outcome. Run the agent-assisted route long enough to expose its effect on review and production, not merely its first-day output.

Track the whole result. Are changes reaching users sooner without a worse change-failure rate? Is review latency falling because work is clearer, or rising because volume increased? Are rollback and recovery easier? Are engineers spending more time on customer and architectural decisions, or on generated rework? Which safeguard caught a failure, and which gap allowed one through?

Scale where evidence supports it. Redesign or stop where the agent increases queues, instability or cognitive load. Preserve options: expand controls that work and narrow authority that does not.

Here is the leadership test. Before granting a coding agent more authority, ask the engineering leader to name the person who would take responsibility for a bad change at 02:00, the evidence that person would have, and the fastest reliable way to reverse it. If those answers are vague, the agent has already been given more autonomy than the delivery system can safely carry.

Sources

Previous Post
Choose Your First Agentic Workflow by Reversibility, Not by Excitement
Next Post
The AI Adoption Gap Is a Workflow Problem, Not a Training Problem