Among engineering teams, almost everyone has AI in the editor, but far fewer have changed what work gets specified, reviewed or shipped. That’s where the frustration is: code is getting delivered faster, and everything downstream of code is remaining as slow as ever.
Sonar’s 2026 State of Code survey quantifies that: AI is now writing roughly 42% of committed code at the organisations surveyed, while 96% of developers say they do not fully trust that output to be functionally correct. The volume increased, but the confidence did not.
This guide walks through how what happens when AI goes beyond the editor and into the workflow. What specs and context look like to agents, where the humans remain, what tends to fail, and how to run a pilot without risking the production system on it.
Three stages, often confused for one
Teams describe very different setups with the same words, which makes benchmarking against peers close to useless. It helps to separate them.
McKinsey’s research on generative AI in software development describes a similar ladder, from a developer writing every line alone up to a small group directing several coordinated agents. Most companies that believe they are at the top are sitting on the first rung with a bigger tool budget.
What AI-native teams do differently
Four habits separate a team that has restructured from a team that has only bought licences.
Specifications you can check, not tickets you can argue about
A prompt is only an intention. A useful specification is testable: it defines the expected behaviour, the acceptance criteria, the architectural limits, and the edge cases that need to be handled. It gives the agent a clear brief and gives the reviewer a concrete standard for judging the result. Without that, teams end up reviewing code against half-remembered conversations, which is where many quality disputes begin.
Specs also go stale. Once a spec no longer matches the production code, it becomes worse than no spec because it gives everyone reading it confidence they have not earned.
Context treated as a maintained asset
Agents fail in a specific way: they produce plausible code based on incomplete information about your system. Architectural rules, domain vocabulary, prior decisions and security constraints need to live somewhere both agents and reviewers read from, and somebody needs to own keeping it current. Most of the quality difference between two teams running identical models comes down to this, not to model choice.
Agents with job descriptions
A working setup usually involves several narrow agents rather than one general one:
- A coding agent that implements defined slices of work
- A test agent that writes and maintains suites alongside the code
- A security agent that flags risky patterns and dependency changes
- A documentation agent that keeps specs and READMEs aligned with reality
- A planning agent that drafts implementation options for a human to choose between
Each one needs a defined scope and the same context as the others. Coordination between them matters more than the raw capability of any single model.
Nothing merges because it looks right
Generated output is a proposal until something proves it works. Automated tests, static analysis, security scanning, dependency and licence checks, architecture conformance, then a human reviewer for anything touching authentication, payments or customer data. Teams at Kindgeek apply the same rule on PCI DSS and GDPR-scoped systems: automate every check a machine can make, and require a named human approval for anything that reaches production or moves money.
The failure modes nobody mentions in the demo
The speed is real. So is the downside, and it shows up a few sprints later rather than on day one.
- Security defects at scale. Veracode’s 2026 GenAI Code Security Report found that around 44% of AI code-generation tasks introduced a genuine vulnerability, with an average security pass rate of 56% across the models tested. Verizon’s 2026 Data Breach Investigations Report adds the context that matters here: software vulnerabilities have passed stolen credentials as the leading way attackers get in.
- Packages that never existed. A USENIX Security study found close to one in five packages recommended by code-generating models were fictional. Attackers noticed and started registering the plausible names, a trick now called slopsquatting.
- Comprehension debt. Engineers approve output they haven’t fully understood, and six months later nobody on the team can explain a subsystem under incident pressure.
- Permission sprawl. Agents get broad repository and tooling access because narrowing it was inconvenient during the pilot, and the scope never gets tightened.
- Non-determinism. The same prompt produces different results on different runs, which makes reproducing a bug harder than it used to be.
None of these argue against the model. They argue for verification being part of the workflow rather than a stage somebody adds at the end.
A pilot you can run in one quarter
Rollouts that stick tend to follow roughly this order:
- Audit the baseline honestly: test coverage, documentation quality, and how precisely requirements already get written. Weak foundations here will produce weak results no matter which agents you run.
- Set access and tooling policy before any agent touches a repository. Scope, secrets handling, approved tools, audit trail.
- Pick two or three workflows that are high-value and low-risk. Test generation, legacy code analysis, dependency upgrades, technical documentation and incident runbooks all qualify. They share a useful trait: a clear spec and a cheap way to verify the output.
- Improve the context agents will read from, since that is what they actually work against.
- Write real specifications for the pilot work, with acceptance criteria somebody could test blind.
- Run it in a production-representative environment with the quality gates switched on. A pilot behind relaxed rules teaches you nothing about production.
- Measure agent output quality rather than assuming it. Track acceptance rate, override rate and rework.
- Scale what held up, and keep the gates as you grow.
Kindgeek began its own adoption on a MiCAR-regulated crypto-fiat platform with CI/CD test automation, where correctness was easy to verify, before moving agents anywhere near feature work. That order is deliberate. Start where a wrong answer is cheap and obvious.
What to track once it’s running
Delivery speed alone will flatter you. Pair it with quality and cost signals:
- Delivery: lead time for changes, deployment frequency, PR cycle time
- Quality: change failure rate, escaped defects, test coverage trend
- AI workflow health: agent task success rate, human override rate, rework after merge
- Cost: model spend per task, reviewer hours per change
The first two groups map onto the DORA metrics your organisation probably already reports, which makes the before-and-after comparison easy to defend in front of a board. The third group is the one teams forget, and it is the one that tells you whether the practice is improving or quietly degrading. Kindgeek treats a climbing human override rate as the earliest warning that context has drifted away from the code.
Where this leaves you
AI native software engineering is an operating model, not a purchase. The teams getting value from it are not generating more code than everyone else. They are the ones where an agent receives a clear instruction, has the context to act on it, and produces something a human can verify against a written criterion in minutes rather than hours.
If you want the deeper version of the SDLC and governance mechanics, Kindgeek’s guide to AI native software engineering walks through each stage in detail.
Pick one workflow where the value is measurable and a wrong answer is cheap. Write the spec properly. Put the gates in before the agents. Then decide what to scale based on what the numbers say, not on how impressive the demo felt.
Frequently asked questions
How is AI native software engineering different from using an AI coding assistant?
Using an assistant is an individual productivity change inside an unchanged process. The tickets, the review steps and the release cadence all stay as they were. The native model changes the inputs: specifications and shared context become the primary artifacts, agents handle defined slices of implementation and testing, and verification happens before anything is accepted rather than after a human eyeballs the diff. One gives you a faster typist, the other gives you a different operating model.
Is this just vibe coding with extra steps?
No, and the difference is traceability. Vibe coding, the term Andrej Karpathy coined in 2025, means accepting generated code with limited review and iterating by feeding errors back to the model. It suits prototypes and throwaway tooling. The engineering version keeps the generation speed but adds a requirement that someone can point at the specification a change satisfies and the test that proves it does.
Does AI-generated code still need human review?
Yes, particularly for anything touching authentication, payments, personal data or money movement. Generated code can read cleanly and still fail on edge cases, miss the actual requirement, or introduce a vulnerability the author never considered. Automated gates catch the mechanical problems cheaply, which frees reviewers to spend their attention on logic, risk and whether the change matches what was asked for.
What should a team fix before trying this?
Automated testing, written requirements, documented architecture and a working review process. Agents amplify whatever discipline already exists, so a team with thin test coverage and vague tickets will get faster production of unverifiable work. Fixing those gaps is worth doing regardless of whether you adopt agents, which makes it a low-regret first move.
How long before the investment pays back?
Teams piloting on well-chosen workflows such as test generation or legacy code analysis usually see measurable change within one quarter, because those tasks have clear specs and cheap verification. Broader delivery gains take longer and depend heavily on how good the context and specifications are. The honest answer is that payback tracks the quality of your engineering foundations more closely than it tracks model choice or budget.
