# Why AI Didn't Reduce Engineering Headcount Will AI shrink engineering teams? The teams I advise need more engineers, not fewer: the work moved to review, agent-facing interfaces, and the environments agents work in, and the next hires are landing outside the engineering org. **Published:** August 13, 2026 **Category:** Software Development **Tags:** AI Development, Engineering Teams, Future of Tech ![Why AI Didn't Reduce Engineering Headcount](/blog/ai-engineering-headcount/gate.png) --- AI made writing code cheap, and the teams I advise need more engineers than before. The demand moved. Reviewing and verifying what machines produce now eats the hours typing used to, and the next hires are landing in departments that never had an engineering line. Count engineers by who sits in the engineering org and you'll understate what's coming. A year ago I wrote [From Typing to Thinking](/blog/ai-developer-evolution), arguing that AI turns developers into architects. The discourse around it shortened that to "fewer developers, more architects", repeated often enough that a journalist asked me about it recently. The architects half is right, and developers do spend their days on design and judgment now. The fewer half is what costs companies money, because they plan headcount cuts for a function whose workload is growing. ## Why cheap code means more engineers Spreadsheets grew the accounting profession instead of shrinking it, because once counting got cheap everyone wanted more counting, in more detail. Cheap capability raises expectations faster than it removes work. Software is doing the same thing now, where a backlog that was uneconomic last year is economic this year, so it gets built, and someone has to own it in production. Teams I work with ship a roadmap three times the size of last year's, plus work that didn't exist three years ago. Some of that new work lands at every company. Your product needs an interface agents can operate, and your development systems need rewiring for the new way of coding. Tests have to run against real external systems. An agent needs somewhere to load the application and click through it, with production traces and session recordings flowing back to it. Ship AI features and you get a second pile on top of that, evaluation systems and LLM observability and harnesses for the models themselves. None of this work is exclusively senior. ## The bottleneck is review, and the fix is architecture AI multiplies the volume of change while human review capacity stays flat, and that gap shows up within weeks of a tooling rollout, as more code merged more slowly, because a process built for human-sized diffs is absorbing machine-sized ones. Verification does get cheaper, but only after you build the machine that does it: agent fleets that test, feedback loops that let a model check its own work, evals that track regressions over time, CI gated on types and security. You pay for that once, up front, and none of it shows up on the subscription invoice from your AI vendor. Building that machine is what architecture means now, and it isn't scalability diagrams; it's the systems and containers around the code, the parts that decide whether an agent can operate your software and see what it did. Get it right and the reviewer's job shrinks: the agent implements a change, spins up a sandbox, uses what it built, and the pull request arrives with a video of the working session and production traces attached. Get it wrong and every change is a black box that a human checks by hand. One client, an analytics platform processing millions of events a month, shipped AI features whose output nobody could unit-test. They're nondeterministic, so a passing test suite said nothing about whether the answer was good. We built an evaluation system that scores traces across dev, preview and production. It catches quality regressions before release, and it cut manual review of AI output by more than half. That cost line didn't exist three years ago. Across the teams I've advised, the productivity gains against a pre-engagement baseline came from this work and barely at all from the coding tool itself. Rebuilding review and CI is what made the output trustable in production. ## Three skills that were not on job specs three years ago **Agent-facing interfaces.** Making your product operable by agents, whatever the product does. A database tool should let an agent spin up a database. A 3D application should let an agent build a model and check the result. That surface might be an API, an MCP server or a sandbox the agent can drive, and all of it needs measuring, down to the point where the agent gives up. A product an agent can't operate is invisible to the fastest-growing class of user. **Feedback-loop engineering.** Building the environment coding agents work in, both the agent your customer points at your product and the agent your team points at your codebase. The loop decides the output. Agents need a place to run the software against real external systems, use it, and read back what happened. It also holds the calls your team keeps repeating, so the development cycle compresses instead of re-arguing the same decision. I built a full software factory on this principle, Claude and Codex agents with self-improving loops, and it took a prototype from brief to deployed in hours instead of days. If the product is itself AI, add evaluation on top: what counts as good output, scored at scale, before a customer finds the regression. **Writing code machines can work in.** On a marketplace I built, one explicit design goal was laying out the codebase so coding agents could work in it safely, with clear boundaries, typed errors and small surfaces. Code legibility is an architectural requirement now, and it decides how much AI leverage a team actually gets. All three are the same job. [The environment matters more than the product](/#manifesto) is how I put it on the home page. What reaches the agent decides the result, so the person who builds the environment sets the ceiling for everyone working in it. ## The next engineers will not sit in engineering A marketing team that would have hired another marketer now hires someone to build the marketing loop instead, the enrichment pipelines and campaign automation and agents working the manual middle of the funnel. Swap in sales, support or recruiting and the hire looks the same. Each of those functions is mostly workflow, and workflow is now cheap to build and expensive to keep doing by hand. So engineering headcount lands in departments that never had an engineering line. The junior-developer-type hire who builds the tools, once needed only inside engineering, is now wanted on every team. It also raises the floor on what those departments are expected to produce, the same way spreadsheets raised it for finance. ## Two things this breaks **"Just hire more seniors."** That answer fails in about ten years. The path from junior to architect used to run through typing code, that rung is now missing, and nobody has put anything in its place. Stop hiring juniors for five years and you have no seniors in ten. What I see working is the mixed team, juniors who are native to AI-first workflows next to seniors with years of production judgment. The juniors get judgment no model gives them, and the seniors get workflows they'd never adopt from a slide deck. **Billing by the developer hour.** A vendor selling developer hours is paid for exactly the thing AI made cheap, so their incentive runs against their client's. Hours have also stopped measuring the work. Agent loops run in the background and problems get solved while I sleep, so an hourly bill measures my attention instead of the output. Clients feel this before they can name it. They stop asking "how many developers" and start asking "when is it live." I price on outcomes, and the longer case for selling outcomes instead of hours is in [Sell Yourself as a Business, Not Just a Coder](/blog/developer-as-business). ## Where this leaves your headcount plan If you run an engineering org, the question isn't how many developers AI lets you cut. It's who builds the interface your agents work through, who builds the verification machine, who owns the tripled backlog in production, and which of your other departments hires its first engineer. Teams treating cheap code as a reason to shrink are cutting the line that stopped being the constraint. --- ## Links - Blog post: https://andrey-markin.com/blog/ai-engineering-headcount - All blog posts: https://andrey-markin.com/blog - Contact: https://andrey-markin.com/#contact