AI-Native Development Is a Management Test

As the cost of building falls, the quality of organisational judgement becomes the constraint.

Most of the debate around AI-native development is still too focused on who gets to build. Will product managers need to code? Will engineers absorb more product work? Will prototypes replace written product thinking? Those questions matter, but they are not the questions I would put in front of a board or executive team first.

The more important question is what happens when an organisation becomes dramatically better at producing software before it becomes any better at deciding what should exist.

That question matters because AI-native development is not just a new way to build software. At its best, it is a new way for an organisation to learn. Customer signals can move closer to engineering. Assumptions can be tested earlier. Feedback can return to product thinking while decisions are still alive. Risk can be surfaced before it hardens into production. The dead space between intent, build, test, and learning can shrink dramatically.

That is the exciting version. But the prize is not automatic.

What interests me about the current wave of AI development is that we are removing one of the oldest constraints in software at exactly the same moment we are exposing new ones. The bottleneck does not disappear. It moves. Understanding where it moves may become one of the defining management challenges of the next decade.

I have seen this pattern often enough now. An organisation automates one part of the work, celebrates the release of pressure, then discovers that the constraint has reappeared somewhere else. The bottleneck moves from coding to requirements, from requirements to prioritisation, from prioritisation to governance, from governance to adoption. The technology changes. The management challenge remains.

For most of the history of software, production acted as a natural constraint. Building things was expensive enough that ideas encountered resistance. Requirements were challenged. Priorities competed. Trade-offs had to be made. Teams were forced into difficult conversations because implementation consumed real time, real effort, and real money.

Most people experienced that as friction. I increasingly think some of it was functioning as selection.

A surprising amount of software never existed because somebody eventually had to justify it. The cost and time of building forced a conversation. Why are we doing this? Who is it for? What changes if we succeed? What happens if we do nothing? The questions were not always answered brilliantly, but they were asked often enough that many weak ideas never made it into production.

That is why I find the current conversation around AI-native development so intriguing. Not because product and engineering are converging, although they are. Not because agents are becoming more capable, although they are. What interests me is that we are removing one of the oldest filters in software at exactly the same moment we are celebrating our ability to produce more of it faster.

Bain’s recent report is useful because it does not treat AI-native development as a simple tooling story. The headline numbers are dramatic, with expectations moving toward hybrid human-agent teams and major productivity gains, but the deeper point is about operating change. Bain says successful pilots are satisfying, but real value comes from end-to-end transformation that reinvents workflows, teams, and measurement.

The value is not in scattering AI agents across isolated tasks. It is in redesigning the way work moves from customer signal to product intent, from product intent to engineering execution, from engineering execution to feedback, and from feedback back into the next decision.

That is why the expectation gap matters. If organisations genuinely expect agent-assisted engineering to become a dominant mode of software work, they cannot leave the surrounding system untouched. You cannot move from occasional AI assistance to AI-led development while keeping the same handoffs, same measures, same governance, same approval habits, and same unclear ownership.

The ambition is exciting, but it creates a management obligation.

If agents are going to work across requirements, code, testing, iteration, and feedback, then leaders have to redesign the workflow those agents are entering. Otherwise, AI-native development becomes a faster production layer sitting on top of the same old ambiguity.

This is where Bain’s “context is king” point really matters. Agents do not become useful simply because they can generate code, draft requirements, write tests, or call tools. They become useful when they carry the right context through the work: product intent, architecture, code conventions, telemetry, security posture, risk policies, customer signals, and feedback.

Without that, they are not orchestrators. They are task accelerators attached to a system that has not learned how to absorb them.

That distinction matters because many organisations will confuse local acceleration with systemic improvement. A faster coding loop is useful. Faster test generation is useful. Faster requirements drafting is useful. But if those improvements do not change how the organisation learns, decides, measures, and governs, the value will be thinner than the activity suggests.

That is why rewiring end-to-end workflows matters so much. Agents cannot hover above a broken process and magically make it coherent. They have to be wired into the work with the right context, boundaries, review points, escalation paths, and evidence loops. Otherwise the organisation does not get transformation. It gets faster motion around the same old confusion.

This is also why I am suspicious of productivity as a success metric on its own. Productivity measures movement, but it does not necessarily measure direction. AI can make production faster, but speed only becomes valuable when it is attached to better selection, better feedback, and better organisational learning.

Otherwise an organisation can generate more features, more workflows, more dashboards, more internal tools, and more AI-assisted software while creating less clarity for customers and more complexity for itself.

Anyone who has worked inside a large organisation has seen this happen already. The problem was never a shortage of things. Most organisations are drowning in things. The problem is deciding which things are worth having, which things are worth maintaining, and which things should never have existed in the first place.

AI-native development increases the urgency of that problem because it lowers the resistance between intent and implementation.

If the intent is sharp, that is powerful. If the workflow is redesigned, that is powerful. If the measurement is credible, that is powerful. If agents are wired into the right context and bounded by the right judgement, that is powerful.

But if the intent is confused, the confusion now travels faster.

That is where the software pollution risk sits. Not in AI itself. Not in agents themselves. In the combination of cheap production, unclear judgement, weak measurement, and unreformed workflows. If organisations use agents to accelerate old habits, they may get more software, more features, more internal systems, and more workflow clutter without getting better products or better work.

The danger is not that AI-native development fails. The danger is that it works well enough to scale decisions that should have been challenged earlier.

In some ways, this reminds me of the earlier debate around writing and prototypes. As prototypes became easier to create with AI, some people concluded that product management writing itself had become less important. I never found that convincing.

An AI prototype can show that something can be built. It cannot answer whether it should be built. Writing, at its best, forces confrontation with ambiguity, contradiction, trade-offs, and intent. It is one of the ways organisations think before they act.

AI-native development presents the same challenge at a much larger scale. The ability to produce software faster is unquestionably valuable. The question is whether our ability to decide what deserves to exist is improving at the same rate.

Because if it is, this is genuinely exciting. Organisations can learn faster, respond faster, reduce waste, shorten cycles, and build better products with less dead space between signal and action. Customer insight can travel further. Product and engineering can operate in tighter loops. Expertise can arrive earlier. Decisions can improve because reality arrives sooner.

That is the opportunity I see in AI-native development: not more software for its own sake, but better organisational learning.

For boards and executive teams, this changes the question. The question is not simply whether engineering teams can build faster with AI. The question is whether the organisation has strengthened the judgement, workflow design, context layer, measurement, and governance needed to make that speed useful.

If those conditions are present, AI-native development could become a serious source of advantage. It could reduce waste, shorten learning loops, improve product-market responsiveness, and help organisations make better decisions earlier.

But if decision-making improves more slowly than production, the defining challenge of the next few years may not be a shortage of software. It may be an over-abundance of it.

The danger is not that organisations fail to build enough with AI. The danger is that they become capable of building almost everything before they have learned what deserves to be built.

The cost of building with AI is falling. The cost of being wrong is not.

◆

Stuart Winter-Tear
Author of UNHYPED
AI as Capital Discipline
unhyped.pro