Operating models and transformation
What AI-native software delivery actually means
A working definition connecting intent, context, execution, acceptance and learning in AI-assisted software delivery.
Joan ArandaAI-native software delivery needs a definition that helps people make decisions. If it merely describes a team using AI, it tells us little about how the team works, what it can delegate or why its output should be trusted.
I propose treating it as a delivery system designed to incorporate AI-generated work, with explicit intent, sufficient context, acceptance conditions and the ability to learn from each execution. This is a working definition, not an industry standard.
“Native” does not require automating everything. It means the organization has considered these capabilities when designing how it produces and validates software. Human judgment can remain central.
Five questions for examining the system
Before selecting a tool or adding agents, I would examine five questions. They do not require five documents: a small task may answer them briefly.
| Part of the system | Question | Useful evidence |
|---|---|---|
| Intent | What behavior do we need, and what is out of scope? | Examples and acceptance criteria |
| Context | What constraints and decisions must the work respect? | Relevant contracts, rules and invariants |
| Execution | What can be delegated, and within which boundaries? | Task scope and permissions |
| Acceptance | How will we assess the result, and who accepts it? | Tests, review and explicit responsibility |
| Learning | What should be retained for the next task? | Reusable decisions, failures and evidence |
The answers also depend on the connections between these parts. A clear specification can omit an important constraint. An implementation can pass available tests while failing to address the original intent. An accepted change can leave a valuable decision unrecorded.
A deliberately small example
Consider a fictional reservation application. We want to allow cancellation when at least 24 hours remain before the reservation starts. This is neither a real client nor a production experience.
The intent seems simple, but we need to establish which clock is authoritative, what happens exactly at the boundary and which states permit cancellation. We also need to decide whether repeating the operation can release capacity or send a notification twice.
Context includes existing behavior and consumers of the operation. Execution can be delegated within a selected module. Acceptance requires boundary and state cases as well as integration review. Learning preserves the clock decision and the reason for preventing duplicate effects.
Generating the function is one part of this journey. AI’s usefulness depends on its contribution to the whole system and the costs it introduces in understanding, review and correction.
What changes for an engineering leader
This definition changes the investment question. Alongside “Which tool should we add?”, we can ask “Which part of the delivery system is limiting us, and which capability needs improvement?”.
If intent is ambiguous, more execution capacity may produce more proposals to rework. If context is missing, relevant constraints need to become accessible. If acceptance depends on an overloaded reviewer, more generation does not remove that bottleneck. If errors recur, learning across tasks may be missing.
This does not imply that every organization should centralize those capabilities in the same way. A small team can use lightweight coordination. Multiple teams sharing systems may need more explicit agreements.
A definition is not a guarantee
A workflow with documents and validation gates can create bureaucracy. It can also create an illusion of control when the evidence fails to assess important behavior. Each mechanism should justify the decision it improves or the uncertainty it reduces.
Nor does a label demonstrate productivity. DORA’s research describes AI as an amplifier of the existing organizational system. That observation encourages examination of the system; it does not predict the outcome for a particular team.
My criterion for using the term is this: we can explain what work is delegated, which conditions allow it to be accepted and how the experience changes the next execution. If we can only list tools, the definition is not yet helping us understand how we deliver.
References
- DORA, State of AI-assisted Software Development 2025: organizational context, not evidence for this fictional example.
- Birgitta Böckeler, Understanding Spec-Driven-Development: further reading on different approaches and specification maintenance.
The five questions and fictional example are an original editorial proposal prepared for this publication. They do not describe internal hiberus assets.