Engineering headcount will stop tracking the backlog
Engineering's job becomes building and operating the shared capability that turns approved business requests into production changes, not implementing each one.
Businesses will deliver far more software while employing fewer engineers relative to what they deliver. In many organisations, engineering teams will get smaller in absolute terms too.
Engineering doesn't go away. There will still be hard technical problems, consequential decisions and systems that need careful stewardship. But the shape of the function changes. Fewer engineers will be dedicated to a product and its stream of feature requests. More will work on the shared capability that turns the business's intentions into production changes.
That is a different future from the one where every software engineer becomes a product engineer. I think it's the more likely one, and this post is about why: what engineers will own, how companies will allocate them, and why a bigger backlog will stop being an argument for a bigger team.
Demand stops translating into headcount
For many businesses today, engineering capacity is a major constraint on delivery. The business wants a new customer journey, a pricing change, an internal tool. The requests enter a backlog, someone estimates and prioritises them, and the team works through them. When the backlog gets painful enough, you hire.
The relationship was never perfectly linear. Better architecture and better tooling improve output. But engineering labour is a major input into each change. Even when the work is familiar, someone has to understand the request, find their way around the system, modify it, verify it and carry it through to release.
What changes is that marginal cost.
Engineering invests in a system that performs those activities repeatedly. Once it exists, the next request doesn't create another unit of human engineering work. It creates work for an automated process, with human attention reserved for the cases the process can't resolve within its authority.
The initial investment is large, and expanding into a new technical domain requires another substantial investment. But delivering more changes within an established domain takes progressively less human involvement. Ten times the requests shouldn't mean ten times the engineers. For a mature delivery system, it might mean almost no additional engineers.
The usual rebuttal is that cheaper software creates more demand for software. It will. Businesses will pursue changes they previously couldn't justify, and internal processes that never earned engineering time become candidates for automation. But that extra demand only keeps teams large if fulfilling it still requires engineers. If most of it is absorbed by automated capacity, delivery volume grows faster than the team operating it.
That depends on what happens to exceptions. Human attention is reserved for the cases the system can't resolve, and a low exception rate on its own doesn't guarantee flat headcount, because more delivery can still mean more interventions in absolute terms. The question that matters for staffing is whether total human intervention effort grows alongside delivery. Within established domains it should fall per request as engineers improve the system after interventions. Volatile requirements or unfamiliar domains may sustain it. The prediction depends on that balance.
Engineering headcount comes to reflect the complexity and limits of the delivery system, not the length of the backlog.
What the pipeline looks like
The delivery system I have in mind starts well before any code is generated. Its entry point can be Slack, Jira or whatever your business already uses to coordinate work. The surface matters less than the process behind it.
A request begins as an expression of intent and becomes a specification through iteration. Say the business wants to let customers pause a subscription. The request sounds simple, but the business has decisions to make. Which customers are eligible? For how long? What happens to billing, and to benefits already paid for? Are there contractual restrictions? What should support see?
The process exposes those questions and routes each one to its owner. Commercial stakeholders decide the commercial rules. Operations decides how exceptions are handled. Brand and design shape the customer experience. Legal contributes where it must. Product defines the intended behaviour and what an acceptable outcome looks like.
Technical feasibility is part of the same iteration. Automated analysis inspects the existing systems, identifies dependencies and surfaces incompatible assumptions. If the billing integration can't support the requested behaviour, that comes back before implementation starts, as a constraint, an alternative, or a technical change that needs an engineer first. The pipeline doesn't have to accept everything it's given.
A request becomes eligible for execution when the required questions are answered, each stakeholder has approved their part, and the system knows what a successful implementation means. What reaches implementation is far more than a prompt typed into a coding agent (an AI system that reads and changes code with some autonomy). It carries decisions, constraints, acceptance criteria and an attributable record of who approved what.
Implementation uses that specification alongside the organisation's authoritative requirements, makes the change, runs the appropriate checks and produces evidence that the result satisfies the approved request. Release then applies controls proportionate to the change: a limited-impact change moves quickly, a change to a financial workflow gets staged rollout, monitoring and automatic rollback.
An approved specification doesn't guarantee an outcome stakeholders will prefer once they see it. A result that fails an approved requirement is a defect. Where verification catches it, it blocks release; where it surfaces afterwards, it's corrected and, if needed, rolled back. A result that meets every requirement but raises a question about whether it's the right product is different. That can go back through the pipeline as a new request, or stay in place while the business watches whether it's better or worse in practice. Mandatory requirements always apply. Some questions about value can only be answered through use and time, and the pipeline doesn't need every one of them settled before release.
The system also has to know when it can't establish enough confidence to continue. That is where engineers stay involved: unsupported integrations, ambiguous behaviour, failed verification, and the cases that reveal a missing capability or a wrong assumption. The goal is to make those exceptions rare.
Making them rare is continuous work. Each intervention should, where practical, leave the system better able to handle the same kind of request next time: a new check, a clarified requirement, a supported integration.
This is a substantial system to build. Once it exists, it serves many requests without an engineer implementing each one. That is the mechanism behind the staffing change.
Will stakeholders actually do the work?
The model depends on the business producing complete, approved specifications, and that is where it is most likely to fail. Low-code platforms, internal platform teams and self-service initiatives have made versions of the same promise, and incomplete requirements and thin stakeholder engagement are recurring reasons they fell short.
Two features of the model make it more workable.
First, the pipeline doesn't wait for a finished document. It interrogates the request. It asks the eligibility question, the billing question and the support question one at a time, directs each to the person who owns it, and shows them what the system already knows. Answering a pointed question is a much smaller ask than writing a specification, and it's the kind of work a product owner or operations lead is already doing in meetings, just without a record.
Second, the cost of not answering becomes visible. Today an incomplete request still gets built, because an engineer fills the gaps with their own judgement and the business finds out later whether they guessed right. In this model, an unanswered question stops the request, and the system shows which question is outstanding and whether anyone owns it. That changes the incentive.
What doesn't change is that some requests will stall. Ownership is unclear, the decision-maker is overloaded, or two stakeholders disagree, and valuable work waits. The pipeline doesn't solve that, but it changes who carries it. A missing decision or an unresolved owner becomes visible to the business, rather than something an engineer quietly resolves on its behalf.
Why not everyone becomes a product engineer
The product engineer argument runs: if AI makes writing code cheap, engineers should spend the time saved understanding customers and deciding what to build. In a small company that's often right. When there are only a few people, strict role boundaries create more overhead than they remove, and a founder who can sell, design and build has an obvious advantage.
I don't think it generalises. Understanding a decision and owning it are different things. An engineer needs to know why a change matters and what failure would mean. That doesn't make them the right person to set commercial strategy, approve a brand interpretation or decide which customer segment to prioritise. Those decisions already have owners, and larger organisations have good reasons to keep it that way.
There's another response to cheap implementation: make the business more capable of expressing what it wants, and make engineering more capable of executing it reliably. Under that model, company-specific knowledge moves out of individual engineers' heads and into specifications, policies and evaluation criteria the delivery system can use. The engineer stays accountable for the reliability of delivery without personally carrying each request across every organisational boundary.
Some engineers will keep working deeply inside products, because some products demand it. But I don't expect "everyone becomes a product engineer" to describe the dominant response in the businesses that use software to run their operations.
Engineering owns the system of delivery
In this model, engineering is responsible for the machinery that makes business requirements executable. That is far more than connecting a language model to a repository.
The organisation needs a reliable way to know which requirements apply to a change, to tell current policy from obsolete documentation, and to connect an approval to the version of the specification it approved. It needs to give agents the access their work requires and stop them acting beyond it. It needs to evaluate whether the output is correct, release it safely, observe what happens and recover when the result is unacceptable.
Requirements come from everywhere. A brand team saying an interface must use a particular font has supplied a binding requirement in its domain. So has an architecture team mandating an authentication mechanism, or operations defining how a workflow handles an exception. The sources might be Confluence, a design system, a service catalogue or a governance platform. Stakeholders own the substance. Engineering owns the mechanism that makes those requirements available, enforceable and traceable through delivery: knowing which sources are authoritative, which version applied when the change was approved, what to do when two conflict, and whether a document is expressing a preference or drawing a mandatory line.
Some requirements can be checked mechanically. A font, a dependency restriction or an infrastructure configuration has a clear automated test. Others need richer evaluation (an eval is a repeatable assessment of an AI system's behaviour or output against specified criteria) or explicit stakeholder review. The pipeline has to support both without quietly treating the hard ones as optional.
The automation itself also needs managing. A model update changes implementation behaviour. A tool update changes what an agent can reach. A new policy invalidates assumptions in an existing workflow. The delivery system needs versioning, evaluation, controlled rollout and observability, like any other consequential production system.
So the work becomes recognisably operational. Where does the process fail? Why do requests need intervention? Which checks are unreliable? If engineers keep repairing the same class of generated change by hand, the system is leaving its most important lesson unlearned. The enduring contribution is the improvement that makes the next hundred changes work.
The automation work we already know about
Part of the reason I expect this shift is that many businesses I've worked in have had a large gap between their delivery ambitions and their engineering practices, and faster code generation makes that gap more dangerous, not less.
Automated deployment with a safe way back has often been missing. Test coverage has been thin in both depth and variety: basic unit tests, and much less attention to integration, end-to-end or evaluation coverage. Pull request review has been weak, and third-party dependencies have been trusted without much scrutiny of what they do.
Generating implementation faster doesn't fix any of that. It sends more changes through those weak controls. If you can't establish whether a change is safe, more changes mean more uncertainty. If your deployment is fragile, faster implementation sends more work at a fragile release process. If review means someone skimming a large diff, more generated code finds the limit of that control quickly.
So there's a real engineering job before a business can depend on autonomous delivery: useful test coverage at each level of behaviour, deployment that is incremental, observable and reversible (blue/green, where a new version runs alongside the old and traffic switches over, is one option, not a prescription), and dependency choices assessed against organisational requirements rather than whatever the agent reached for.
That transition is expensive. A business may need engineers building the delivery system while still maintaining its products. But the transitional workload doesn't tell you the eventual shape. Once a capability exists, its purpose is to retire recurring human work. A deployment improvement serves every release. A policy integration serves every request. A reliable eval catches a whole class of mistake without anyone rediscovering it in review.
Engineering's pets-to-cattle moment
Infrastructure went through this already. I used to put servers in data centres myself: install whichever flavour of Linux the job called for, then configure Apache, mail servers, layer 2 authentication, game servers. Each machine had a name, and I knew its quirks. Those servers were pets, and the industry's answer was to treat them as cattle instead: standardised, replaceable, managed as a fleet through common systems. Attention moved from the individual machine to automation, reproducibility and recovery.
Implementations are next.
Today a codebase accumulates personal knowledge. Engineers know its history, its awkward corners and the reasons behind decisions nobody wrote down. Changing it depends on that familiarity. In the model I'm describing, the specification, the requirements and the evidence of correct behaviour become more durable than any particular implementation. Code still matters, but there's less reason to treat every piece of it as a unique object needing continuous personal attention.
This is how I already work. I build Atty House in my own time as the sole engineer, but I approach it as the stakeholder who wants the outcome. I hold its structure to a high bar: how a house's knowledge is modelled, who can see what, where every answer's evidence comes from. I don't value the code or its delivery pipeline for their own sake. I want them to work dependably with as little ongoing effort from me as possible; their worth is the outcomes they produce. When something goes wrong, I fix the change, then ask what in the system that produced or verified it would have caught it. Not every defect points to a systemic cause, but the fixes that improve the system are the ones that keep paying, so that's where I spend the effort.
Scaled up, engineering starts to look like fleet management. Which implementations are operating outside policy? Which dependencies need replacing? Which generated changes are failing verification? Which classes of request keep consuming human attention? Those questions concern many workloads at once.
The analogy has limits. Customer data isn't disposable. State transitions have lasting consequences. Some systems will always depend on deep specialist knowledge, and you can't standardise away a difference just because it's inconvenient.
But it explains why engineering will become more transferable between companies. Changing jobs today means absorbing a large amount of local product behaviour and undocumented history. More of that knowledge can live in explicit specifications, policies and evals. Each company will still have its own brand rules, industry constraints and risk tolerances. The engineering work of connecting those to implementation, verification, deployment and recovery looks much the same from one company to the next.
That is what lets a smaller group of engineers support a broader range of products. They don't need to personally own the detailed behaviour of every workload. They need a system that represents those details accurately and applies them reliably.
What this does to teams
A larger roadmap becomes a weaker argument for a larger engineering team. A persistent technical bottleneck, an unsupported class of work, or an unacceptable rate of intervention becomes a stronger one.
Platform engineering, deployment automation, security controls, evaluation, policy enforcement and incident response all become central. That doesn't mean each becomes a job title; a thin team combines several. Nor does it mean everyone currently implementing features moves into an equivalent number of new positions. A shared capability exists precisely to serve work that used to need many people. The new responsibilities are more consequential without absorbing all the labour displaced elsewhere.
Measurement changes with it. Counting tickets closed or changes authored stops being useful. What matters is how much work proceeds safely without intervention, how often the first implementation is acceptable, and how well the system detects and recovers from failure. Those have to be read together: high automation achieved by approving poor changes is a failure, and so is zero incidents achieved by blocking everything.
Getting to that maturity is a programme of work, not a setting. It takes people, budget and a sponsor, the way moving from on-premise infrastructure to the cloud did, or replacing a home-grown identity system with Auth0 or Okta. Standing a capability up is different work from running it, and the staffing it takes during the migration says little about the staffing it takes afterwards.
The next business change
The question I keep coming back to is simple: how much human engineering work should the next business change require?
Today the answer is usually "a lot", even when the request looks like work the organisation has done many times before. I expect that answer to shrink.
The business still has to decide what it wants. Stakeholders still own their requirements and approve the consequential decisions. Feasibility still has to be established, and the result still needs verification, controlled release and observation. Engineering's job is to make all of that function as a dependable system.
As that system improves, new demand increasingly uses a capability that already exists. More delivery becomes possible without a proportional increase in the people operating it. Engineering becomes less attached to individual product changes, more transferable between companies, and thinner relative to the business it supports.
A growing backlog will then describe demand on that capability. Engineering headcount will depend on what the capability cannot yet do.