Buying an AI coding licence for every engineer changes an invoice. It does not make the organisation AI-native.
Consider a company which adds a chat window to the existing process: product writes a ticket, engineering implements it, QA waits for a build, operations receives a handover, and managers measure how many tasks crossed the board. The agent may shorten one stage while the rest of the system continues at the old speed.
That can be a useful improvement. It is not an operating-model change.
An AI-native organisation, if the term is to mean anything, redesigns work around a different constraint. Producing an implementation becomes cheaper and more parallel. Deciding what deserves to exist, expressing the outcome, validating it, integrating it and accepting responsibility for it remain scarce. The organisation has to optimise the whole path around those facts.
The Bottleneck Moves, It Does Not Vanish
When implementation accelerates, queues appear elsewhere.
Product decisions wait for clarification. Reviewers receive changes faster than they can understand them. Test environments become contested. Security and legal approval remain serial. Operations inherits more services. Customers still need somebody to decide whether the result solves their problem.
This is why individual productivity figures are a poor guide to organisational capacity. If an engineer can generate five changes in the time previously required for one, but review and deployment capacity do not change, the organisation has created a larger work-in-progress queue. Some of those changes will become stale before anybody examines them. Cheap production has manufactured expensive inventory.
OpenAI’s harness-engineering case study makes the shift visible. The company reports that three engineers, later seven, directed agents to create roughly a million lines of code for a new product in five months, without manually contributing code. The more important part of the account is what the humans built around the generation: isolated environments, repository-local knowledge, architectural checks, application-driving tools, observability and recurring clean-up.
OpenAI also says human QA capacity became a bottleneck and explicitly warns that the result depends on that repository’s structure and tooling. This is a first-party report about a greenfield internal product, not a controlled comparison with an ordinary team or evidence that a bank can reorganise the same way. It supports a mechanism, not a universal ratio: when execution becomes cheap, investment moves into the environment which defines and judges the work.
Redesign the Flow of Work
The practical unit of work should no longer be “a ticket for somebody to code”. It should be an owned change with an outcome, a risk boundary and a way to tell whether it worked.
A sensible flow looks something like this:
- A domain owner states the problem, constraints, non-goals and acceptance evidence.
- An agent works in an isolated environment with only the authority the task needs.
- Fast checks reject known bad states while the agent can still repair them cheaply.
- Review concentrates on changed contracts, consequential decisions, weak evidence and exceptions.
- Deployment authority follows the blast radius, with observation and recovery built into the release.
- Failures improve the specification, tooling or checks so that the same lesson becomes reusable.
None of these steps requires a fashionable job title. Small organisations may have one person performing several roles. The distinction is about responsibility: the person who asks for the outcome cannot quietly outsource its meaning to the agent, and the person who approves a high-risk action cannot point at the model when it goes wrong.
This also changes platform engineering. A central team can provide agent-ready workspaces, approved tools, reusable checks, cost visibility and audit trails. It should make safe paths easy for domain teams. If every prompt, model choice or exception requires a ticket to the central AI team, we have merely built a more modern queue.
Shared infrastructure should enforce boundaries. Domain teams should retain ownership of meaning.
Review Capacity Is a Design Constraint
An organisation should not generate more consequential change than it can validate.
That sounds obvious, yet many AI programmes reward the opposite. They celebrate accepted suggestions, pull-request counts, token consumption or elapsed time from prompt to patch. These are measures of activity at the cheapest stage. They say little about rework, escaped defects, operational load or customer value.
I would put explicit limits on work in progress and measure the whole loop:
- time from an agreed outcome to observed production behaviour;
- changes abandoned or substantially reworked before release;
- defects, incidents and support demand after release;
- time spent waiting for human decisions or shared environments;
- maintenance and inference cost after the feature ships;
- whether the intended user or business outcome changed.
Faster code generation should lead to smaller, easier-to-reject changes, not larger deliveries justified by the speed at which they appeared. When review capacity is full, start fewer tasks or invest in checks that can genuinely decide part of the workload. Starting another agent is not the answer to a human attention queue.
Agent review helps, but it is not fully independent. Two models can accept the same mistaken requirement, share the same blind spot or be persuaded by the same confident test. Use automated review to find likely hotspots and enforce known rules. Preserve human judgement for product meaning, novel risk and authority which cannot be recovered cheaply.
The aim is not to keep every previous approval ceremony. It is to know which decisions the ceremony was protecting before removing it.
Ownership Becomes More Important
Traditional hand-offs allow responsibility to become blurry. Product owns the requirement, engineering owns the code, QA owns the tests and operations owns the running service. When something fails between those descriptions, everybody can be locally correct.
Agents make that problem worse because they can produce a convincing artefact for every hand-off. A generated plan, implementation, test report and release note can all agree with one another and still solve the wrong problem.
I would prefer small capability teams with end-to-end ownership of a bounded domain. They decide what to change, provide the context, judge the result and observe it in use. Specialists in security, reliability, design or data still matter, but they contribute expertise and enforce cross-cutting boundaries rather than accepting ownership after the fact.
This is not an argument for eliminating managers or specialists. Coordination work which exists only to copy status between systems is a candidate for automation. Work which resolves competing priorities, develops people, handles conflict or accepts institutional risk is not equivalent to status transfer. Flattening an organisation chart without moving those responsibilities produces hidden managers and overloaded senior engineers.
Incentives need to follow the new work. Rewarding only visible feature output discourages people from strengthening tests, deleting needless code, documenting a domain or improving recovery. Those investments may be the most valuable work in an agent-heavy system because they improve every later run. Somebody must also own the unglamorous maintenance of prompts, tools, access policies and stale knowledge.
Case Studies Are Clues, Not Templates
The public examples do not describe one inevitable model.
OpenAI’s experiment pushes review and even some merge work towards agents inside a repository designed for them. Stripe reports that its Minions generate more than a thousand merged pull requests each week, while humans review the code. Both companies emphasise the surrounding development infrastructure. They differ on where human review sits.
Both reports are written by the organisations which built the systems. Both concern technology companies with strong internal platforms and experienced engineers. Pull-request volume is not product value, and neither report gives us a long-term view of architectural coherence, staff development or total cost. Their practices deserve study. Copying their headline numbers would be cargo culting with a larger compute bill.
The useful questions are local:
- Which work is constrained enough to delegate?
- Which evidence can a machine evaluate honestly?
- Where does judgement enter, and who has enough time to apply it?
- Which decisions need separation of duties?
- What new operational system will the generated software create?
An insurance platform, a game studio and a five-person consultancy should not arrive at the same answers. “AI-native” should not become another excuse to import a Silicon Valley org chart without its conditions.
The Labour Question Is Not Settled
It would also be dishonest to discuss smaller execution teams as if the consequences for employment were known.
The revised August 2026 Stanford Digital Economy Lab paper, Canaries in the Coal Mine?, found no evidence of widespread economy-wide job displacement in its payroll sample. It did find that employment among workers aged 22 to 25 in AI-exposed occupations was 19% below where it would have been if it had tracked less-exposed peers. The authors are careful to call these descriptive indicators rather than causal estimates and note differences between their sample and national benchmarks.
That is a reason for attention, not a licence for a dramatic forecast. We do not yet know how much of the change is cyclical, how quickly new demand will appear, which tasks will remain complementary, or how wages and bargaining power will move. We do know that removing junior work can remove the place where future senior judgement develops.
An organisation cannot rely on the market to supply experienced domain owners forever while it eliminates its own apprenticeship path. Juniors may write less routine code, but they still need controlled exposure to design, incidents, customer conversations, verification and the consequences of decisions. Pairing them only with an agent risks teaching tool fluency without institutional judgement. Pairing them with experienced owners while making the full reasoning and evidence visible could be better than the old queue of low-value tickets. That outcome requires design and time; it does not arrive with the licence.
Lay-offs followed by process discovery are the most dangerous order. A company may remove the people who understand its exceptions, then discover that those exceptions were the real specification.
Start With One Real Loop
I would not begin with a reorganisation. I would choose one bounded product area and compare its existing flow with an agent-assisted one.
Record the baseline: lead time, review delay, defects, operational interruptions and maintenance cost. Give the team a real outcome and the authority to change its process. Build the missing feedback mechanisms. Keep production and irreversible actions behind explicit gates until the evidence justifies more autonomy. Include a mix of experience levels so the experiment tests knowledge transfer rather than assuming it away.
After several changes, inspect where time moved rather than treating shorter implementation as success. Product clarification, review and operations may each absorb the time saved: improve the intake when clarification doubles, reduce work in progress or automate a narrowly scoped check when review is saturated, and treat more operational alerts as borrowing from the team’s future.
Scale the parts which improved the complete loop. Reject the parts which merely made a dashboard faster.
An AI-native organisation is not one in which everybody uses AI. It is one which has rebuilt its flow of work around cheap execution and scarce judgement, while keeping ownership attached to the consequences. The technology changes quickly. Accountability does not become optional just because the implementation arrived before lunch.