AI-Native Engineering Is About What You Accept, Not What You Generate

“AI-native” has become one of those terms that sounds precise until you ask two people to define it.

Sometimes it describes an AI-native product: software whose core behaviour depends on AI models. Sometimes it describes an AI-native software lifecycle: a development process reorganised around agents. And sometimes it describes an AI-native organisation: teams, processes, and governance redesigned around AI.

These are different things.

A team can build a product with no AI in it and still engineer it in an AI-native way. Another team can build a sophisticated LLM product using essentially the same software process it used in 2019.

The terminology around engineers is equally confusing.

An AI engineer builds products powered by foundation models. That is an established role with increasingly clear technical requirements.

An AI-assisted engineer uses AI tools inside an otherwise conventional engineering process.

An AI-native engineer, as I use the term here, changes the way the work itself is organised: intent is specified for machines, implementation is increasingly delegated, and human effort moves toward verification, judgment, and accountability.

Interestingly, there is still no widely accepted industry definition of that person. Andrew Ng talks about “AI engineering skills.” Simon Willison uses “agentic engineering.” Birgitta Böckeler calls the surrounding discipline “harness engineering.” Academic work on Software Engineering 3.0 describes an “AI-native” paradigm, but not a standard industry job title.

So rather than argue about terminology, it is more useful to identify the underlying structural change.

Generation became cheap. Acceptance did not.

That is the central idea.

For decades, one of the scarce resources in software engineering was authorship. Someone had to write the implementation.

Our engineering systems evolved around that constraint. Sprint capacity reflected how much a team could produce. Code review scaled with how much humans could write. Hiring heavily tested whether candidates could produce code themselves.

AI changes that constraint.

Producing candidate implementations is becoming dramatically cheaper. Agents can generate code, tests, documentation, migrations, infrastructure changes, and alternative designs continuously and in parallel.

But deciding whether those artifacts are actually correct, safe, maintainable, and worth shipping has not become proportionally cheaper.

In some cases it has become harder. When you did not write the implementation yourself, you may not carry its reasoning and assumptions in your head.

This is why several otherwise different bodies of work are converging on the same observation.

Andrew Ng argues that engineering work is moving toward deciding what should go into the specification. Anthropic’s AI-native SDLC work argues that the bottleneck increasingly moves to the activities around implementation: planning, review, testing, deployment, and maintenance. Thoughtworks warns about “codebase cognitive debt”: the widening gap between what a system contains and what the team actually understands.

The shift is therefore deeper than “developers now use AI tools.”

AI-native engineering is an operating model in which intent is made machine-readable, generation is delegated, and scarce engineering capacity is increasingly concentrated on acceptance: verification, evidence, and accountability.

Four mental models make this easier to reason about.

1. The core loop: Intent → Generation → Acceptance

Instead of thinking first about tools, start with a simple loop:

Intent → Generation → Acceptance

The core loop: intent feeds generation, a wide bundle of generated candidates narrows at the acceptance gate, and feedback returns to intent

Intent

Intent describes what should exist and what constraints the result must satisfy.

For AI to act independently, that intent has to become much more explicit than it often is today: requirements, architectural constraints, acceptance criteria, non-functional requirements, edge cases, standards, and explicit non-goals.

And increasingly, this intent needs to exist as durable, versioned, machine-readable artifacts rather than being scattered across people’s heads, meetings, Slack conversations, and ticket comments.

This is one of the most important ideas in the emerging AI-native lifecycle.

Hassan et al.’s Software Engineering 3.0 describes development as increasingly intent-centric. Andrew Ng argues that engineers are shifting toward deciding what should be in the spec. Anthropic, AWS Kiro, GitHub Spec Kit, and Google Antigravity have all independently moved toward persistent specification or intermediate artifacts that both humans and agents can inspect.

The implication is important:

Specification quality increasingly determines generation quality.

This also helps explain why AI tends to produce more value in greenfield work than in legacy systems. Legacy systems often contain years of undocumented assumptions, implicit contracts, historical exceptions, and design decisions that exist only in the code or in people’s memories.

Before an agent can reliably change such a system, someone has to reconstruct the intent.

That reconstruction is often the real work.

Generation

Generation is the part AI is making cheap.

Given sufficient context and constraints, models can produce many candidate artifacts quickly: code, test cases, designs, plans, documentation, infrastructure definitions, database migrations, and operational procedures.

This is where most current AI tooling concentrates.

But generation alone is not engineering.

Acceptance

Acceptance answers a different question:

Should this artifact be trusted?

The acceptance mechanism might be unit tests, integration tests, formal verification, static analysis, security checks, performance experiments, production telemetry, an independent model, or a qualified human reviewer.

The important property is independence.

The generator should not be the sole judge of its own output.

If an agent generates both an implementation and the tests that “prove” it correct, those tests may still be useful, but they are not a sufficiently independent acceptance mechanism.

Once generation becomes abundant, acceptance becomes the scarce resource.

If you double generation capacity while leaving verification capacity unchanged, you have not necessarily doubled engineering throughput.

You may simply have moved the queue from implementation to review.

2. Autonomy × Consequence

A natural question follows:

How much human review should AI-generated work receive?

“Review everything” does not scale as autonomy increases.

“Review whatever feels risky” does not produce a reliable engineering system.

A better model is to consider two variables:

Autonomy × Consequence

How independently is the system acting?

And how serious are the consequences if it is wrong?

Autonomy times consequence: low-autonomy, low-consequence changes can be auto-accepted; the diagonal band requires review; the high-autonomy, high-consequence corner stays a human decision

When both are low, automatic acceptance may be entirely reasonable.

When consequence is high, the acceptance burden should increase even if the change appears straightforward.

When both autonomy and consequence are high, explicit human approval or stronger independent verification should usually remain mandatory.

This pattern is not unique to software.

Aviation assurance frameworks grade AI by autonomy. Semiconductor engineering is developing autonomy levels for design agents. FDA guidance evaluates AI partly through the interaction between model influence and decision consequence.

Different industries arrived at essentially the same mechanism because the underlying problem is the same.

For software teams, the practical version can be simple. Define three categories.

Auto-accept. Low-consequence changes with strong automated verification.

Review required. Changes where automation can do most of the work but independent human or system-level validation remains necessary.

Human decision. High-consequence decisions that should never be delegated end-to-end.

The important step is not choosing exactly three categories. It is making the policy explicit.

Without one, autonomy becomes a personal judgment made differently by every engineer on every task.

3. Agent = Model + Harness

Birgitta Böckeler’s formulation is one of the most useful mental models in this space:

Agent = Model + Harness

Models increasingly become shared commodities. Two teams may use exactly the same underlying model and achieve very different results.

The difference is everything around it.

The harness determines what the agent can see, what constrains it before acting, and what checks its work afterwards.

Böckeler divides those controls into two useful categories.

Guides influence behaviour before the agent acts: specifications, architectural rules, coding standards, instructions, reusable skills, examples, policies, and context.

Sensors observe the result and create feedback: tests, linters, type systems, CI, security scanners, runtime telemetry, review systems, and other verification mechanisms.

Agent equals model plus harness: guides constrain the model before it acts, sensors observe the result afterwards, and the evidence they produce tightens the guides

This explains why simply buying better models eventually produces diminishing returns.

The model may be capable of solving the problem, but it cannot reliably act on information it cannot see or constraints it does not know about.

Sourcegraph captures this neatly: an agent’s productivity ceiling is constrained by what it can see, and in a large codebase its default view is only a fragment.

The competitive advantage therefore moves from access to the model toward the quality of the surrounding engineering system.

A good harness also changes the purpose of human involvement.

The goal is not to eliminate humans from the loop.

It is to move human attention toward the places where human judgment changes the outcome.

4. The oracle rule

The cross-domain research suggests another useful principle:

AI goes native fastest where a cheap, trustworthy oracle already exists. It progresses more slowly where determining correctness is expensive, slow, or fundamentally human.

An oracle is simply a mechanism that can tell us whether an answer is acceptable.

Software has an unusual structural advantage here.

We have compilers, type systems, unit tests, integration tests, static analysis, formal methods, observability, and reproducible execution. In many situations, we can ask “is this correct?” thousands of times per day at very low cost.

Compare that with other engineering domains.

Chip design may require expensive simulation.

Drug discovery ultimately needs physical experiments.

Medical systems may require clinical evidence.

Mechanical designs may require physical tests or high-fidelity simulation.

The oracle spectrum: well-tested services sit at the cheap-rejection end, with legacy systems, chip design, medical systems, drug discovery and product strategy progressively further toward expensive or absent oracles

The difference is not primarily whether AI can generate plausible candidates. It can.

The difference is how cheaply those candidates can be rejected.

Within software, the same rule predicts where agents work best.

A service with fast CI, strong types, comprehensive tests, good observability, and clearly encoded contracts provides a strong oracle. Agents can act rapidly because incorrect changes are detected quickly.

A legacy system with flaky tests, undocumented contracts, slow deployment cycles, and poor observability has a weak oracle. Agents can still produce changes rapidly, but humans cannot cheaply establish whether those changes are safe.

For product strategy, architecture, UX, and long-term design decisions, there may be no mechanical oracle at all.

That leads to a more useful strategic question than “Which coding agent should we buy?”

Ask instead:

Where are our acceptance mechanisms weak, and what would it take to strengthen them?

Test quality, observability, type safety, formal checks, eval infrastructure, and specification quality used to look like engineering hygiene.

In an AI-native environment, they determine how much autonomy the organisation can safely exploit.

What this means for engineering organisations

If generation is no longer the primary constraint, the order of investment needs to change.

Establish an explicit AI stance

DORA identifies a clear and communicated AI stance as one of the organisational capabilities that amplifies the benefits of AI.

This sounds almost trivial, which is probably why many companies skip it.

Engineers should know:

where AI use is expected;
where it is permitted;
which data or systems may be exposed to it;
what requires independent review;
what may be automatically accepted;
and who owns the final decision.

Ambiguity creates both extremes at once: engineers who avoid useful tools because they are uncertain about policy, and engineers who over-delegate because no meaningful boundary exists.

A short, explicit policy is one of the cheapest changes an organisation can make.

Build the intent substrate before scaling the agent fleet

The temptation is to start with tools.

The research suggests starting with context.

Specifications, standards, interfaces, architectural constraints, operational knowledge, and design rationale need to become accessible to both humans and machines.

Anthropic’s lifecycle model uses persistent artifacts between stages. AWS Kiro treats specifications as first-class inputs. GitHub Spec Kit and Google Antigravity make intermediate artifacts central to agentic workflows.

This convergence is not accidental.

Agents need a durable representation of organisational intent.

Without it, more autonomous agents mainly produce more assumptions.

Invest in acceptance capacity before generation capacity

Most organisations already have access to very capable generation.

The scarce resource is increasingly the infrastructure required to trust what those systems produce.

That means investment in:

tests and evals;
independent checkers;
security analysis;
sandboxed execution;
observability;
policy enforcement;
change control;
and human review for consequential decisions.

This also helps explain the productivity “J-curve” described in DORA’s AI ROI work: organisations can experience additional verification cost before their engineering systems adapt enough to capture the benefits.

The mistake is interpreting that initial friction as evidence that better generation is needed.

Often what is missing is better acceptance.

Measure rework, not output

AI makes output metrics even less useful than they already were.

Lines of code, pull-request counts, commits, or agent activity can increase dramatically while the actual system becomes worse.

Thoughtworks explicitly cautions against using coding throughput as a productivity measure.

More useful signals include:

rework rate;
first-pass CI success;
escaped defects;
change failure rate;
how often specifications survive implementation unchanged;
review effort per accepted change;
and how frequently agent-generated work requires substantial human correction.

AI can manufacture activity almost without limit.

The interesting question is how much of that activity survives acceptance.

Treat cognitive debt as an engineering risk

Technical debt describes problems embedded in the system.

AI introduces another risk: problems in the relationship between the system and the people responsible for it.

Thoughtworks calls this codebase cognitive debt: the growing gap between a system’s implementation and the team’s shared understanding of it.

Two diverging curves: the system that exists grows steeply while the team’s shared understanding grows slowly, and the widening gap only becomes visible at an incident, audit or migration

This gap can remain invisible for a long time.

Then an incident occurs.

The system behaves unexpectedly, and nobody can explain why because large sections were generated, reviewed superficially, and never incorporated into the team’s mental model.

AI-native organisations therefore need to preserve understanding deliberately.

That may mean rotating engineers through review and incident roles, requiring architectural explanations for important changes, periodically working without assistance, or explicitly assigning ownership for system comprehension.

“Does the software work?” is no longer enough.

Teams also need to ask:

Do we still understand why it works?

Set realistic productivity expectations

The evidence does not support a universal “10x engineer” narrative.

Results vary enormously by task and environment.

Atlassian reports that a 65% increase in AI usage produced developer-velocity improvements that topped out at about 15%, with many organisations averaging around 10%.

DORA’s ROI work shows a strong difference between greenfield and legacy work: the easier it is to express intent and verify the result, the larger the gain.

That is exactly what the oracle model predicts.

The sensible organisational expectation is therefore not a universal multiplier.

It is:

large gains where intent and verification are strong; modest gains where they are weak; and potentially negative short-term returns while the surrounding engineering system catches up.

What this means for engineers

The same Intent → Generation → Acceptance loop also provides a useful model for individual capability.

Intent: decide what should be built

The first skill is specification.

Not “prompt engineering” in the narrow sense, but expressing a problem precisely enough that another actor can solve it without constantly asking what you meant.

That includes:

constraints;
acceptance criteria;
edge cases;
non-functional requirements;
explicit non-goals;
and the reasoning behind important design decisions.

But specification is only half of intent.

The harder skill is deciding what is worth building in the first place.

When implementation becomes cheaper, choosing the correct problem becomes more valuable.

Andrew Ng calls this “shaping the build.”

Product judgment, architectural judgment, domain expertise, and systems thinking therefore become more important, not less.

Böckeler reached a similar conclusion from practical agentic development: after successful coding-agent sessions, she found that her decades of programming experience mattered enormously because she was constantly steering, correcting, and evaluating the agent.

AI does not eliminate engineering foundations.

It increases the leverage of people who have them.

Delegation: decide what machines should do

AI-native engineers need to become good at allocating work.

What should an agent handle?

How large should the task be?

How much context does it need?

Should one agent perform the task, or should multiple independent actors participate?

Where should state live?

When should the agent stop and ask?

What should never be delegated?

That last question matters.

Knowing when not to use AI is part of AI fluency.

The right degree of autonomy depends on consequence, reversibility, observability, and the strength of the acceptance mechanism.

This is a more durable skill than expertise in any particular coding agent.

Tools will change quickly.

The ability to design a reliable delegation boundary will not.

Acceptance: decide what is trustworthy

This is the capability I expect to become most valuable.

An AI-native engineer does not merely know how to get an agent to generate an answer.

They know how to establish whether that answer deserves to be accepted.

That means designing tests and evals, understanding the failure modes of LLM judges, using property-based or mutation testing where appropriate, applying formal methods to critical properties, analysing security implications, and knowing when automated evidence is insufficient.

It also means producing an evidence trail that allows somebody else to understand later what happened and why.

This changes the definition of engineering ownership.

You may no longer author every line of a system.

But if you approve the change, you still own the outcome.

A practical capability ladder

A useful way to think about progression is:

A four-level capability ladder from assisted practitioner to AI-native lead, with the decisive transition marked between levels two and three

Level 1 — Assisted practitioner. Uses AI for bounded tasks and reviews the output closely.

Level 2 — Agentic practitioner. Works through agents routinely and maintains a personal harness: instructions, context, reusable skills, checks, and workflows.

Level 3 — AI-native engineer. Designs the acceptance mechanism as deliberately as the generation process. Can own outcomes even when they did not author the implementation line by line.

Level 4 — AI-native lead or harness owner. Designs the standards, evals, platforms, autonomy policies, and governance within which other engineers and their agents operate.

The important transition is between Levels 2 and 3.

It is not about generating more.

It is about owning acceptance.

Many strong engineers are currently becoming extremely capable at delegation while remaining comparatively weak on formal acceptance machinery.

That is probably the highest-leverage gap to close.

If I had to recommend one project for an engineer who wants to become genuinely AI-native, it would be:

Build an evaluation or verification harness for a real system.

Not a demo.

Something where incorrect output matters and where you have to define what “correct” actually means.

What changes next

The research also suggests several broader shifts.

Organisational knowledge becomes executable

Today, much organisational knowledge lives in documentation written primarily for humans.

Increasingly, important procedures will become packaged as versioned, discoverable instructions and skills that agents can execute.

That brings enormous leverage, but also familiar governance problems.

Which skill is authoritative?

Who owns it?

Which other skills depend on it?

How is it versioned?

How do you know whether it is obsolete?

The same problems organisations learned to manage with libraries, APIs, microservices, schemas, and infrastructure modules will reappear at the knowledge layer.

AI-accessible knowledge will become infrastructure.

And unmanaged knowledge will become another form of technical debt.

Intermediate artifacts become the unit of human oversight

One of the strongest convergences in current tooling is the return of explicit intermediate artifacts.

Anthropic persists artifacts between lifecycle stages.

AWS Kiro works from specification files.

GitHub Spec Kit produces structured markdown artifacts.

Google Antigravity makes reviewable artifacts central to its workflow.

Why are independent systems converging here?

Because humans cannot economically review unlimited generated output.

Instead, we increasingly review the intent, constraints, plans, and evidence that produced the output.

That makes intermediate artifacts useful not only for agent coordination, but also for auditability and governance.

They may eventually become as important as source code itself.

The control plane moves earlier

Traditional engineering governance has relied heavily on CI/CD because that is where changes converge.

Agentic development weakens that assumption.

Agents can perform large refactors, generate migrations, modify infrastructure, and coordinate many changes before the traditional pipeline sees anything.

Governance therefore has to move closer to the execution environment itself.

Permissions, sandboxes, context boundaries, policy enforcement, and continuous verification become part of the development control plane rather than checks attached only at deployment time.

Verification becomes more valuable as generation becomes cheaper

This pattern already appears outside software.

In semiconductor design, probabilistic generation can explore larger solution spaces, while deterministic simulation and formal verification remain responsible for sign-off.

The cheaper candidate generation becomes, the more valuable trustworthy rejection becomes.

The same economics apply to software.

The durable engineering advantage will increasingly lie in building excellent oracles.

The junior-engineer pipeline becomes a serious problem

There is an uncomfortable contradiction here.

Current research and practitioner experience consistently say that domain foundations and engineering judgment remain crucial.

At the same time, AI increasingly automates the tasks through which junior engineers historically developed those foundations.

Entry-level technology hiring has also contracted sharply.

We are therefore removing some of the work that taught engineers how systems behave while simultaneously increasing the value of the judgment that experience created.

That is not a reason to reject AI.

It is a reason to redesign apprenticeship deliberately.

Organisations need to ask a question they have mostly avoided so far:

If AI performs the beginner work, where will future experts come from?

I do not think the industry has a convincing answer yet.

The real risk is not bad generation

AI-generated code will sometimes be wrong. That problem is obvious, and obvious problems usually attract controls.

The subtler risk is gradual loss of engineering discipline.

Simon Willison has described this as normalization of deviance.

You skip a detailed review once because the result is obviously fine.

Then again because it was fine last time.

Eventually you are no longer making a conscious decision to accept less evidence. It has simply become the normal workflow.

The organisational version is cognitive debt.

More and more of the system exists.

Less and less of it is truly understood.

You discover the gap only when the normal path fails: during an incident, a security investigation, a major migration, or the moment someone asks why the system behaves the way it does.

That is why I think acceptance, rather than generation, is the right lens for AI-native engineering.

The defining question is no longer:

How much can we get AI to produce?

It is:

What are we willing to accept, what evidence do we require before accepting it, and who is accountable when we do?

Answer those questions first.

Then generation can become as cheap and abundant as technology allows.

References

AI-native engineering and software engineering

Hassan et al., Towards AI-Native Software Engineering (SE 3.0), ACM Transactions on Software Engineering and Methodology, 2026.
Alenezi, The Rise of AI-Native Software Engineering, 2026 — competency taxonomy covering specification, verification, agent orchestration, foundations, governance, and continuous learning.
DORA, 2025 State of AI-assisted Software Development and AI Capabilities Model.
DORA, ROI of AI-assisted Software Development, updated 2026.

Engineering practice

Andrew Ng, The AI Engineering Skills Map, 2026.
Birgitta Böckeler, What is harness engineering?, MartinFowler.com, 2026.
Birgitta Böckeler, The role of developer skills in agentic coding.
Thoughtworks, Technology Radar Vol. 34, 2026.
Simon Willison, Vibe coding and agentic engineering are getting closer than I’d like, 2026.

AI-native lifecycle

Anthropic, The AI-Native SDLC Playbook, 2026.
Atlassian, AI-native software development in Jira.
GitHub, Spec Kit.
AWS, Kiro.

Assurance beyond software

FDA, Health Canada and MHRA, Good Machine Learning Practice for Medical Device Development.
FDA, Predetermined Change Control Plans for AI-Enabled Device Software Functions.
EASA, Concept Paper: Guidance for Artificial Intelligence Applications, Proposed Issue 03.
EE Times, From AI-assisted EDA to AI-mediated engineering.