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 watched engineering teams roll out AI coding tools over the past two years — not in theory, across actual teams building actual products — and the pattern that keeps showing up isn’t headcount reduction. It’s standard elevation. 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 stops being “can we build this?” and starts being “should we, and will it hold?”
Gergely Orosz surveyed 216 software professionals for The Pragmatic Engineer in 2024, asking how they actually use AI tools — not what they plan to, not what the vendor claimed, but what they reach for on an average Tuesday. Engineers found AI genuinely useful for specific things: getting unstuck in unfamiliar codebases, writing boilerplate tests, scaffolding new services — narrower and more practical than the marketing would suggest.
What also surfaced: more experienced engineers noting that code was being generated but not understood. A staff engineer describing a colleague who shipped an entirely AI-generated function, with AI-generated tests, neither of which were reviewed carefully enough to catch what was wrong underneath. A software architect describing an interview candidate who, when stuck on a debugging problem, copied the code into ChatGPT, waited for an answer, and when none came, stopped — 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 isn’t the constraint anymore. Knowing whether what you shipped is right — whether it’ll hold under load six months from now, whether the abstraction makes sense or just looks clean — that part didn’t get easier. It got more consequential, because there’s more output to evaluate and less time spent generating it.
Bessemer Venture Partners put it precisely: when anyone can spin up a functional prototype with natural language prompts, the competitive advantage shifts toward people who can identify the right problems and craft solutions that hold. Product sense, system-level judgment, the ability to look at 300 lines of AI-generated code and know quickly whether it’s correct — none of that comes from the model.
What I’ve seen in practice: the engineers who thrived with AI tools weren’t the fastest to adopt them. They were the ones who already had good instincts about what the codebase should look like. They treated AI output the same way they’d treat 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 gave them more output to be responsible for.
The hiring question changes as a result. Raw coding speed matters less — the model handles a meaningful chunk of that now. What’s harder to find is engineers who can evaluate code well, who understand the system they’re building into deeply enough to catch when an AI suggestion 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. 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 distinguish a real solution from a plausible-looking one. Those things compound with time in ways a model can’t replicate.
The org chart doesn’t shrink — what changes is what earning a spot on it actually requires.
If you’re working through how to run engineering teams in this environment — what to hire for, what to measure, what to stop optimizing — reach out. These are the conversations worth having.
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