What happens to Product and Engineering when execution becomes cheap?
The first thing most software teams notice when they start using AI seriously is that engineers can produce more code.
The second thing they notice is that everything around the code starts to feel slower.
This is becoming a familiar pattern. Implementation accelerates, but the rest of the organisation does not automatically accelerate with it. Review struggles to absorb the volume of work. Improve review, and testing becomes more visible as a constraint. Automate more of the testing, and Product needs to answer questions and refine decisions at a pace it was not previously designed for.
Then other constraints begin to appear. Leadership may not be able to decide between options quickly enough. Customers may not be able to absorb the amount of change being produced. The organisation may become capable of building ideas faster than it can work out whether those ideas deserve to exist.
This does not mean the investment in AI has failed. It means the productivity gain in one part of the system has exposed the limitations of another.
The bottleneck did not disappear.
It moved.
Engineering is where the change became visible first
It is understandable that many organisations initially treat AI as an Engineering productivity programme.
Engineering produces visible output. We can measure lead time, deployment frequency, cycle time, pull requests, and code generation. When an engineer turns a prompt into working software within a few hours, the change is difficult to miss.
But software delivery has never been only about producing code.
The traditional development model is largely a sequence of handoffs. Product identifies a problem and writes requirements. Design turns those requirements into an experience. Engineering implements it. QA validates it. Operations releases it. Customer-facing teams explain the change and help people use it.
We have spent years improving this pipeline, but much of its structure developed around a simple constraint: implementation was expensive.
When something took several weeks to build, waiting two days for a decision was inconvenient, but it could disappear inside the wider delivery timeline. When the same implementation takes a few hours, those two days become most of the work.
Making Engineering faster while leaving discovery, decision-making, validation, release, and adoption unchanged does not create a proportional increase in customer value. It creates a queue somewhere else.
Sometimes the constraint moves upstream into customer research, prioritisation, or product definition. Sometimes it moves downstream into testing, security, compliance, deployment, or adoption. Sometimes it moves into the leadership team because the organisation can now create possibilities faster than its leaders can decide between them.
Engineering is not the only function being disrupted.
It is simply where the change became visible first.
The old handoffs start to make less sense
For years, we have tried to make the handoff between Product and Engineering work better.
We introduced better ticket templates, backlog refinement, sprint planning, acceptance criteria, design reviews, and delivery ceremonies. Some of those practices are useful. Some were always compensating for the distance between the people defining the problem and the people implementing the solution.
That distance becomes harder to justify when the feedback loop compresses.
A product manager can now describe an outcome, work with an agent to produce a prototype, place it in front of an engineer or customer, and discover within hours that the original definition was wrong. An engineer can test a technical assumption before the next planning session. A designer can explore several interaction models without waiting for a complete implementation cycle.
This does not remove the need for different disciplines. Product, Design, Engineering, and Quality still bring different forms of judgement.
But it changes how they should work together.
Instead of spending most of their time preparing documents to be handed across organisational boundaries, they can operate in a much tighter loop. They can define something, build enough of it to learn, inspect the result, and change direction while the context is still fresh.
That may involve Product and Engineering reconnecting several times in one day rather than relying on a specification written on Monday and a ceremony scheduled for the following week.
At human implementation speed, that level of interaction might have felt excessive.
At agentic implementation speed, it may be the only sensible way to work.
When implementation becomes cheap, context becomes expensive
AI should not simply make every existing role faster. It should change what people and teams are able to own.
I have written before about the opportunity for engineers to move beyond execution-only roles and take responsibility for outcomes end-to-end. I still think that is important. But there is another side to it.
As implementation becomes cheaper, poor context becomes more expensive.
When an experienced engineer encounters an incomplete requirement, they will often pause. They will ask why something matters, challenge an assumption, or seek clarification before committing to a direction.
An agent may not pause.
It may make a plausible assumption and carry on.
Sometimes that assumption will be useful. Sometimes it will be completely wrong. Either way, it can produce the result extremely quickly.
This means that a specification is becoming more than a document describing work for another person. In an agentic development model, it increasingly behaves like an executable instruction.
That does not mean Product should produce enormous documents or return to heavy waterfall processes. The faster feedback loop should make that unnecessary. It does mean that clarity, customer understanding, technical context, and explicit trade-offs become more important.
The cost of poor judgement is no longer always a six-month project that fails loudly. It may be hundreds of small, inexpensive implementations that gradually make the product harder to understand.
When building becomes easy, deciding what deserves to be built becomes harder.
Product and Engineering become a learning system
This is where I think the more fundamental organisational change begins.
Product and Engineering have often behaved like two departments negotiating a contract. Product defines the work. Engineering estimates it. Product prioritises it. Engineering delivers it. Each side tries to make the agreement clearer and more predictable.
That model made some sense when execution capacity was the scarce resource.
If Engineering could only complete a limited number of initiatives each quarter, Product needed a backlog, prioritisation frameworks, detailed planning, and confidence that the chosen work was worth the investment.
Those needs do not disappear. Resources, attention, and customer tolerance remain finite.
But implementation is becoming less useful as the organising constraint.
Product and Engineering should increasingly behave as one learning system. Product brings customer context, market understanding, commercial priorities, and a view of the problem. Engineering brings technical judgement, system context, implementation options, and an understanding of what can be tested cheaply. Design makes possible futures visible. Quality helps define what confidence should look like.
Together, they shorten the distance between observing reality, forming a hypothesis, testing it, and deciding what to do next.
This is different from simply delivering more features.
Faster implementation can make it easier to build the wrong thing. A working prototype is not evidence that the problem matters. A completed feature is not evidence that the original assumption was correct. More output does not necessarily mean more learning.
The useful measure is not how much software the organisation can generate.
It is how quickly the organisation can improve the quality of its decisions.
Smaller teams should mean less coordination, not simply fewer people
The commercial conversation around AI often moves quickly towards headcount.
If a smaller group can produce what previously required a larger organisation, it is reasonable to ask whether the organisation still needs the same number of people.
But I think this misses the more interesting opportunity.
The opportunity is not merely fewer people. It is less coordination.
Every handoff introduces some context loss. Every additional organisational layer creates latency. Larger groups need meetings, planning processes, management structures, and ceremonies partly because coordinating the group becomes a significant activity in itself.
Some of that coordination was necessary because delivering a complete outcome required several specialists working in sequence.
AI gives experienced people leverage across a wider surface area. A backend engineer can work effectively across a frontend. A product-minded engineer can own a vertical slice. A product manager can interrogate a codebase and understand the implications of a proposed change. A designer can produce more complete prototypes without waiting for a separate implementation cycle.
This should allow smaller units to own broader outcomes with fewer handoffs.
That does not mean simply removing half the people from an existing team and expecting the same structure to work. A smaller team with weak context, unclear authority, poor technical foundations, or a permission-seeking culture will simply become a smaller bottleneck.
Smaller autonomous teams need clearer decision rights, stronger guardrails, better access to customers, broader skills, and genuine authority to act.
The structure will also depend heavily on context. A new product experiment, a mature enterprise platform, and a regulated financial system should not be organised in the same way.
I do not think there is one future team design.
But I do think the general direction is towards smaller units, broader ownership, fewer handoffs, and tighter feedback loops.
Quality cannot rely mainly on manual inspection
As generation speeds up, the next constraint is trust.
If AI can generate thousands of lines of code faster than humans can read them, line-by-line review cannot remain the primary mechanism through which we create confidence.
Trying to match machine-speed generation with human-speed inspection simply creates another queue.
The answer is not less engineering discipline. It is more systematic discipline.
Quality, security, testing, and observability need to be designed into the delivery system rather than applied at the end. Product definition should include thinking about behaviour, risk, edge cases, and expected outcomes. Testing should begin alongside the specification. Generated work should be reviewed independently, particularly when the original system may otherwise reinforce its own assumptions.
Deployment needs its own confidence mechanisms. Progressive releases, canary deployments, automatic rollback criteria, telemetry, and explicit production thresholds all become more important when the volume and speed of change increase.
None of these ideas is new.
What changes is that they are no longer optional signs of engineering maturity. They become necessary foundations for operating at this speed.
The accountability still belongs to the human.
The question changes from:
Did I personally inspect every line?
To:
Do I have enough evidence to trust this change?
That evidence may come from automated tests, independent review, behavioural validation, security analysis, production telemetry, and a safe rollback path.
I explored this in more depth in The Agentic SDLC: When the Bottleneck Becomes Trust. The broader point here is that trust itself becomes an architectural concern. It cannot depend mainly on adding more people to the end of the process.
Customer context becomes harder to copy
There is another consequence of cheaper implementation.
General software capabilities become easier to reproduce.
AI can generate common features, established patterns, familiar interfaces, and standard technical approaches. It can inspect what competitors offer and help a team build something similar with far less effort than before.
What it does not automatically possess is the context specific to your customers.
It does not inherently know which workflow is painful enough to change behaviour, which technical limitation is creating a commercial problem, why customers use the product in unexpected ways, or which apparently simple request points towards a deeper unmet need.
This is why I think engineers should move closer to customers, not further away.
Joining customer calls, reviewing support conversations, understanding usage patterns, and seeing the commercial consequences of technical decisions should not be treated as distractions from delivery. They are part of the context needed to make better decisions.
When execution is abundant, proprietary context becomes more valuable.
The advantage may not come from having access to a better model. That difference is likely to narrow quickly.
It may come from understanding something meaningful about your customers that competitors cannot easily reproduce.
The apprenticeship paradox
There is one part of this transition that I am much less certain about.
Where do the next generation of senior engineers come from?
Junior engineers have traditionally learned through repetition, code review, debugging alongside more experienced people, smaller implementation tasks, production incidents, and gradual exposure to architecture and trade-offs.
Some of that work looked inefficient.
But some of it was also the apprenticeship system.
We are now designing smaller teams, increasing the leverage of senior people, automating more implementation, reducing manual review, and expecting individuals to own broader outcomes.
That may be a much more productive system.
But who is training the junior?
AI will be an extraordinarily capable tutor. It can explain concepts, propose alternatives, review work, generate examples, and provide immediate feedback at a scale no human mentor can match.
I do not think that is the same as developing judgement.
Judgement comes partly from lived experience. It comes from watching a good idea fail in production, understanding why a technically elegant solution was wrong for the business, working through a legacy system, handling an incident under pressure, and making decisions when none of the available options is clearly correct.
There is a risk that we create a generation capable of producing software at extraordinary speed before developing the experience needed to recognise when the output is wrong.
I still believe we should hire junior engineers.
What I do not know is whether we have yet designed the new apprenticeship model.
If we optimise only for today’s productivity, automate the work through which engineers historically learned, and remove the environments where experience was transferred, we may solve the cost of software production while weakening the system that creates experienced engineers.
How do we deliberately develop senior judgement when much of the work that used to create it is now performed by AI?
I think that remains an open question.
What the organisation is really optimising for
Looking back at what I have been writing and observing over the last few months, I think I have been circling the same idea from different directions.
AI is not simply making software development faster.
It is changing where organisational friction lives.
Engineering was the first place where the shift became obvious, because the output is visible and relatively easy to measure. But the change does not stop there.
Product has to improve the speed and quality of decisions. Engineering has to move from code production towards broader ownership and judgement. Quality has to move from downstream inspection towards continuous verification. Leaders have to spend less time coordinating work and more time designing the conditions in which people and agents can operate safely with greater autonomy.
AI amplifies the system it enters.
In an organisation with clear ownership, strong foundations, access to customer context, and the ability to make decisions quickly, it can create significant leverage.
In an organisation with unclear priorities, weak quality practices, fragmented ownership, and slow decision-making, it can generate confusion more quickly.
The durable advantage will not be access to the best model.
It will be the ability to understand where the bottleneck has moved, redesign the system around it, and repeat that process as the constraint moves again.
Execution is becoming cheaper.
That makes context, ownership, judgement, and trust more valuable.
Engineering is where we noticed the change first.
I do not think it will be the last place.