What Is Agentic Engineering?

The first week with coding agents almost always looks like a miracle. Code appears faster than anyone can read it; a prototype that would have taken a fortnight lands by Thursday. Then the second week arrives. The reviews start to lengthen. Architecture questions surface that nobody asked. A change that compiled and passed every test turns out to have quietly crossed a boundary an experienced engineer would never have crossed. The speed was real. The trust was not — and that gap is the whole subject of this piece.

Agentic engineering is not a tool you install. It is a delivery model. Where a copilot autocompletes the line you are typing, an agent works toward a goal: a system that, as Anthropic puts it, "acts toward a goal with a degree of autonomy, rather than responding to one prompt at a time" — reading a codebase, planning a sequence of actions, executing them with real tools, checking the result and adjusting. The human states intent; the system explores, plans and implements.

That inversion is the whole story. For a decade the developer wrote the code and the machine helped at the margins. Now the machine drafts the change across many files, runs the tests and proposes the commit — and the developer’s job is to decide whether it should ship. The interesting question is no longer how the code gets written. It is how it gets trusted.

Why acceptance is the new bottleneck

There is an economic logic under the hype, and it is older than AI. When a resource becomes abundant, value moves to whatever sits next to it and is still scarce. Generation just became abundant — a competent agent produces a plausible change in minutes. So what is scarce now? Acceptance: the judgement that a change is correct, safe and worth shipping. The bottleneck does not disappear. It moves one step downstream — from writing the change to trusting it. The whole job of agentic engineering is closing that distance, and it has a name: the Acceptance Gap.

This is not just theory. A large 2025 study of more than 456,000 agent-authored pull requests found that agents are dramatically faster than humans — and that their pull requests are accepted less often. Speed went up; acceptance did not follow. An independent randomised study by METR went further, finding experienced developers were actually slower on tasks they knew well, even as they believed AI had sped them up. Both point the same way: the speed narrative is unreliable, and generation was never the constraint.

The bottleneck is not generation. It is trust.

Hold that idea and the rest of the discipline falls out of it. If acceptance is the governing constraint, then context, evaluation, governance, architecture and delivery are not separate topics — they are all ways of narrowing the gap. That is why this one shift reorganises everything downstream.

The harness is the product

If acceptance is the constraint, the engineering moves to the harness around the model — not the model itself. Models are commoditising. A better model raises generation, not acceptance. The harness is where the differentiation, and the real work, now sits: small, reviewable problem scopes; feedforward controls that set an agent up to be right the first time; and feedback controls — compilers, linters, type checkers, test suites — wired in as deterministic gates, so a failure self-corrects before a human ever sees it. We keep watching the same two teams play out side by side: one buys the smarter model and is quietly disappointed; the other builds better rails and pulls ahead. Buying a smarter model does not close the gap. Building a better harness does.

We kept expecting a better model to fix quality. What actually moved acceptance was the environment around it — shared instructions, repository structure, automated validation. The harness carried more of the reliability than the model did.

Context engineering is the new architecture

The biggest lever in that harness is context — the curated set of conventions, architecture decisions, contracts, examples and constraints an agent can see before it acts. Get it right and the agent behaves like someone who has read your codebase and sat in your design reviews. Get it wrong and it behaves like an intern on their first morning — every morning. So the work is to capture that context once and own it: shared, versioned instruction files baked into service templates, not prompts each developer retypes from memory. This is not a fringe idea any more. Thoughtworks now calls context engineering "a foundational architectural concern", and the AGENTS.md convention is stewarded as a vendor-neutral standard under the Linux Foundation.

Traditional software engineering organises code. Agentic engineering organises context. The primary asset of an AI-native organisation is no longer its codebase — it is its context layer.

The human moves up the stack

None of this removes the engineer; it changes their altitude. The work moves from doing to directing — and every role on the team shifts with it. This is the AI-native operating model, and it is the part most organisations underestimate.

• Engineer: from implementation to orchestration.
• Tech lead: from code review to context design.
• Architect: from solution design to constraint design.
• QA: from testing to evaluation design.

In practice this stays supervised — human-on-the-loop, not autopilot. Even the optimistic sources keep the human as the final authority on what ships; Thoughtworks still finds fully autonomous coding agents "unconvincing". Supervision is not a transitional phase. When acceptance is the constraint, the human judgement at the gate is the point.

Why the enterprise gap is wider

In a regulated enterprise, "accepted" means far more than "the tests pass". The same change still has to clear identity and access rules, payment and data-protection obligations, auditability, operational supportability, change governance — the quiet list that stands between a green build and a shipped feature. The bar is higher, so the gap is wider, and the harness matters more, not less. This is the uncomfortable part for anyone hoping AI lets them skip the disciplines: the harder your compliance reality, the more engineering the harness demands. AI does not get you out of the work. It moves the work to where the judgement is.

Measure what lands, not what’s typed

It follows that counting AI-generated lines of code is worse than useless. Measure delivery: the DORA flow and stability metrics — lead time, deployment frequency, change-failure rate, time to restore — plus rework rate, the share of the pipeline consumed by fixing work previously called done. Rework is the early-warning light for unchecked AI. Acceptance rate and rework, not output, are the numbers that tell you whether agentic engineering is working.

When we instrumented our own delivery, commits and lines told us nothing useful. Acceptance rate and rework told us everything — whether intent was actually reaching production.

Where it sits

Most organisations mistake experimentation for maturity. A handful of impressive demos start to read, internally, as "we do AI now". We see five stages instead: Experimentation, Assistance, Automation, Agentic Engineering, and the AI-Native Organisation. Agentic engineering is the fourth — and it is not a switch you flip. It is a stage you earn, by building the harness, the context layer and the operating model underneath it. That is the whole distance between adopting agents and adopting agentic engineering. It is also the subject of the rest of this series.