Spent this week wiring a semantic layer over three overlapping tables instead of standing up a fourth one, which got me thinking about the gap between what a tool makes possible and what it makes true. More tooling rarely means less work. Usually the opposite.
Cheaper code is a hiring problem, not a headcount cut
There's a piece going around arguing that AI won't empty the software factory, and the framing stuck with me. The idea is Jevons Paradox applied to engineering. When something gets cheaper to produce, demand for it goes up, not down. Code gets cheap to write, so people write more of it, so you need more people who can steer what gets written.
I see the C-suite math going the other way right now. If AI writes two or three times the code, the reflex is to cut heads and call it efficiency. That's the wrong read, and I think it's the read that gets a lot of leaders burned over the next 18 months.
Here's what actually changes. The expensive part of software was never typing. It was knowing what to build, catching the thing that compiles but returns the wrong rows, and owning the system when it breaks at 2am. AI moved the cost out of production and into review and judgment. Anthropic went from 2,500 merges a day to 30,000. Somebody has to decide which of those merges should exist, and that somebody is more senior, not less.
The role shifts before the org chart does
I felt this firsthand converting an agent framework. I tried to condense the files, over-condensed, and lost content that mattered. Threw the whole thing out and redid it with one rule: every piece of information lives in exactly one file. The AI could generate all day. The value was in the structure I imposed, which no model picked for me.
That's the foreman move. You're not laying the bricks anymore. You're reading the output, catching the fault line, and deciding what ships. One of the better write-ups this week makes the same point from the developer's seat: the win isn't vibe coding. It's learning to brief an AI like a product manager instead of a junior dev. Describe the outcome, not the artifact.
What this means for growing a team
If you're a tech lead staring at a hiring freeze justified by "AI handles it now," push back with the velocity numbers. More code generated means more review load, more integration surface, more ways to be quietly wrong in production. Your bottleneck moved downstream.
The career path shifts too. The help-desk-to-director climb used to run through "can you do the work faster." Now it runs through "can you judge the work and own what it produces." Those are different muscles. Hire and promote for the second one, because the first one is the part the machine got cheap.
3 things worth your time
1. Start with the work, not the AI tool
A working CIO argues you map the workflow and build the context layer before you pick a model. Matches what I keep running into: the model works fine. The disconnected data underneath is what sinks it.
2. Fast AI deploys, slow rollbacks
69% of IT teams can't undo a bad deployment in under an hour. Shipping speed went up. Recovery speed didn't. Worth auditing before AI starts writing device policies at scale.
3. Manage your AI agent like a new hire
Agents fail from being under-onboarded, not dumb. Give them the context and a page of priorities the way you'd brief a person on day one, and the output gets noticeably better.
If you're defending headcount against the "AI handles it now" argument this quarter, I'd love to hear how that conversation is going. Reply and tell me.