The dominant narrative around AI and software teams goes something like this: AI writes code faster, so you need fewer engineers to write it. The math is appealing in a boardroom. It’s also wrong about what actually happens.

I’ve spent the past two years watching engineering teams roll out AI coding tools, real teams building real products, and the pattern that keeps showing up is standard elevation, not headcount reduction. When the cost of execution drops, the threshold for what’s worth executing rises. You can ship a working prototype in an afternoon now. So can every team at every company you compete with. The question used to be whether you could build a thing. Now it’s whether you should, and whether it will hold.


In 2024, Gergely Orosz surveyed 216 software professionals for The Pragmatic Engineer, asking what engineers actually reach for on an average Tuesday rather than what the vendor marketing claims. The answers were narrower and more practical than the marketing would suggest: getting unstuck in unfamiliar codebases, writing boilerplate tests, scaffolding new services.

The survey also picked up a worry from more experienced engineers: code was being generated without being understood. One staff engineer described a colleague who shipped an entirely AI-generated function with AI-generated tests, and neither was reviewed carefully enough to catch what was wrong underneath. A software architect described an interview candidate who, stuck on a debugging problem, pasted the code into ChatGPT and waited. When no answer came, the candidate stopped, with no instinct of their own to fall back on. The tools raised the floor and stopped there.

The model writes the code. It can’t tell you whether the code should exist.


Lines of code per sprint stopped being the constraint. Knowing whether what you shipped is right, whether it will hold under load six months from now, whether the abstraction makes sense or just looks clean, didn’t get easier. It got more consequential, because there’s more output to evaluate and less time spent generating it.

Bessemer Venture Partners made the same point: when anyone can spin up a functional prototype with natural language prompts, the advantage shifts to people who can identify the right problems and craft solutions that hold. Product sense and system-level judgment don’t come from the model. Neither does the ability to read 300 lines of generated code and know quickly whether it’s correct.

In practice, the engineers I saw thrive with AI tools weren’t the fastest adopters. They were the ones who already had good instincts about what the codebase should look like, and who treated AI output like a pull request from someone six months into the job: read it, question it, check what’s being papered over. The tool extended their judgment. For engineers still building that judgment, it mostly handed them more output to be responsible for.


This changes the hiring question. Raw coding speed matters less, since the model now handles a meaningful chunk of it. What’s hard to find is engineers who can evaluate code well, who understand the system they’re building into deeply enough to catch an AI suggestion that is subtly wrong, the kind of wrong that won’t surface until it’s a production incident two quarters out.

Prasanna Tambe at Wharton frames it this way: as barriers to building fall, the scarce input shifts. Compute is rented and frameworks are commoditized. What doesn’t commoditize is proprietary understanding of the problem domain, accumulated knowledge of what users actually need, and the taste to tell a real solution from a plausible-looking one. Those compound with time in ways a model can’t replicate.

The org chart doesn’t shrink. What changes is what it takes to earn a spot on it.


If you’re working through how to run an engineering team in this environment, what to hire for, what to measure, what to stop optimizing, reach out.


Gergely Orosz — AI Tooling for Software Engineers: Reality Check (The Pragmatic Engineer)

Bessemer Venture Partners — AI-powered R&D: Vibecoding, Taste, and the Evolution of Full-Stack Design