Most conversations about AI-assisted software development begin with the developer: Which coding assistant should we use? How much faster can it generate a feature? How many lines of code did it produce? These are reasonable questions, but they may be too small.
The software development lifecycle was built around an expensive constraint: translating intent into working code took a great deal of human time. AI is changing the cost and speed of that step. It can help people explore an unfamiliar codebase, draft tests, compare implementation choices, create documentation, and turn an idea into a prototype surprisingly quickly.
But faster code does not automatically produce better software. If requirements remain ambiguous, architecture is brittle, environments are difficult to reproduce, and feedback arrives slowly, AI may simply generate more work for the same constrained system. DORA's 2025 research describes AI as an amplifier of an organization's existing strengths and weaknesses. That feels like an important warning: the tool is not separate from the system in which we put it.
The bottleneck is moving
When implementation becomes faster, judgment becomes more important. What should we build? Is the behavior correct? Does it fit the architecture? Can we operate it safely? Is the additional complexity worth owning?
A lifecycle optimized for producing code can become overloaded when code is abundant. Reviewers receive larger changes. Security teams see more surface area. Test suites must distinguish plausible output from correct behavior. Operations teams inherit decisions that may have been generated faster than they were understood.
The scarce resource may no longer be code. It may be shared understanding and accountable judgment.
What I think needs to change
Begin with executable clarity
Requirements should become smaller, testable statements of intent. Examples, constraints, acceptance criteria, and operational expectations give both people and AI a better definition of done. A long document that leaves important decisions implicit will not become precise merely because an AI can read it.
Make experimentation cheap—and production deliberate
AI makes prototypes inexpensive. We should take advantage of that by comparing approaches before committing to one. But the path from prototype to production should remain explicit. Generated software needs an owner who understands its behavior and accepts responsibility for operating it.
Review decisions, not just diffs
Traditional review often focuses on changed lines. In an AI-assisted workflow, reviewers also need the reasoning: the problem statement, alternatives considered, assumptions made, evidence from tests, and risks that remain. The useful unit of review becomes the decision and its evidence, not only the code.
Build continuous verification into the workflow
Tests, security checks, observability, architectural constraints, and policy validation should provide rapid feedback while work is happening. The more quickly software can be generated, the less practical it is to rely on a late quality gate to find every problem.
Measure outcomes instead of output
Lines of code and feature counts were always weak measures. With AI, they become even less useful. The better questions concern lead time, reliability, customer outcomes, recovery, maintainability, and whether teams can make changes without fear.
What I am still working through
I do not think there will be one AI-native lifecycle. Regulated systems, internal tools, commercial products, and experiments have different consequences when they fail. The right balance of speed, evidence, and human review will vary.
I am also cautious about treating autonomy as the objective. The goal is not to remove people from software development. It is to help people spend more time understanding problems, making sound decisions, and learning from real use—and less time performing work that a machine can reliably assist.
My working idea is simple: organizations will get more value from AI when they stop inserting it into isolated steps and start redesigning the flow of intent, evidence, decisions, and feedback across the whole lifecycle.
Where has AI moved the bottleneck in your development process—and has your lifecycle changed in response?