A founder we talked to last quarter was about to sign offers for two senior engineers. Mid-market SaaS, real revenue, board pressure on roadmap. The plan was sensible by 2022 standards — double the senior bench, halve the time to the next big release. By the end of the conversation, she’d torn up one of the offers, signed the other, and routed the difference — roughly $280k all-in — into tooling, an agent setup, and a six-month engagement with someone who could teach the rest of the team how to operate the new stack.

A year ago that call would have looked reckless. Today it’s the call we’d have made too.

This post is about why the hiring math has shifted, what the new decision framework looks like, and what it doesn’t change — because plenty of the things founders worry about when staffing a technology team are exactly as hard as they were three years ago, and AI doesn’t touch them.

What actually changed about the work

The short version: AI agents amplify whoever’s driving them, but the amplification curve isn’t flat. It bends sharply with the seniority and shape of the person at the keyboard.

A senior engineer with a good agent setup ships meaningfully more than a senior without one. We’d put the number at 1.5–2× on most code-shaped work, higher on the well-trodden parts of the stack, lower on anything novel or load-bearing. The lift comes from delegation: the senior writes a tight spec, hands off implementation, reviews the diff, course-corrects, ships. Each loop is faster, and the senior’s attention compounds into more decisions per day.

A junior engineer with the same agent setup also gets a lift, but the shape is different. They can take on work that used to require a mid-level — drafts of features, refactors with a known target, well-scoped bug fixes. What they can’t do well, yet, is catch the moment the agent went sideways. They’ll ship a confident-looking PR with a quietly wrong abstraction in it and not know to push back. The lift is real; it just comes with a new failure mode that didn’t exist before.

Specialists get more from agents in their specialty than generalists do across the board. A senior backend engineer with five years on the same codebase can spec, steer, and review at a level the agent can’t fake. A generalist asking the agent to do something the generalist has never done themselves usually gets work that looks plausible and isn’t.

The headline isn’t “AI replaces engineers.” It’s that the production function changed — same inputs produce different outputs depending on who’s holding the lever. And the hiring decision is upstream of that.

The decision framework

Before signing the next engineering offer, three questions. Each one names a function the team needs filled. AI doesn’t fill any of them.

Who is the spec author on this team?

An agent is a force multiplier on execution. It’s still neutral on direction. The team needs someone who can sit down with the founder, the support tickets, and the half-formed feature request, and produce a tight, opinionated spec — these files, this acceptance criteria, this is in scope and this is not.

Specs are upstream of every line of code the agent will write. A team that can’t write good specs doesn’t get more output from agents — it gets more output of the wrong thing, faster. We’ve watched teams add an agent setup to a fuzzy product process and ship six weeks of work that had to be partially thrown out, because the agent had been faithfully executing a spec nobody actually agreed on.

If the founder is the spec author by default, that’s often fine when the company is small — but the founder’s time is the constraint, and an agent doesn’t help with that. If the spec author is supposed to be the engineering hire, that’s a different role than “senior engineer.” It’s closer to a tech lead, and the offer letter should reflect that.

Who is the reviewer on this team?

Agents generate plausible-looking work at scale. The team needs someone who can tell the difference between a clean diff and a confidently-wrong one — and the bar for that judgment is higher than it used to be, because the surface area of code the team is shipping has grown.

The reviewer function isn’t the same as “the engineer who happens to have the most commits.” It’s the person who can read 400 lines of generated TypeScript and notice that the agent added a third caching layer the codebase didn’t need. Or that a refactor passes the tests but breaks an unspoken contract in a sister service. Or that the dependency the agent reached for is fine in isolation and a poor fit for the team’s deploy story.

This is the function juniors can’t fill yet — not because they aren’t smart, but because the pattern-matching takes years. A team that runs agents without an experienced reviewer is shipping unreviewed senior-volume code with junior-volume judgment behind it. The cleanup eventually catches up.

Who is the escape valve on this team?

When the agent breaks — and it will — who recovers?

The failure modes aren’t the ones you’d expect. It’s less “the agent wrote nonsense” and more “the agent silently stalled mid-task, reported ‘done,’ and left half-committed files in two branches.” Or “the agent eagerly refactored a piece of code that was load-bearing in a way the agent didn’t know about.” Or “the agent shipped a PR that’s green in CI and wrong in production for reasons that take two hours to trace.”

Recovery from these failures isn’t a junior task. It needs someone who can read the agent’s logs, the git history, and the production telemetry side-by-side, form a hypothesis about what happened, and patch it. A team without that depth has no floor — when the agent breaks, the team is stuck waiting for it to unbreak itself, which it won’t.

The escape-valve role is often the same person as the reviewer, sometimes the same person as the spec author. On a small team it has to be — there’s nobody else. On a larger team you can split the functions across people, but you can’t skip any of them.

What the new shape often looks like

The teams shipping clean work with AI in the loop keep landing on one of three patterns. None of them are new. What’s new is the ratio.

One senior, multiple juniors. One experienced engineer holds spec, review, and escape. A handful of junior or mid-level engineers do the agent-assisted execution underneath. Two years ago this ratio would have starved the team for throughput — not enough senior bandwidth to keep juniors unblocked. Today the agent absorbs the execution gap. The senior’s attention is the constraint now, not the headcount.

One senior, no juniors, heavy agent use. A founder or early CTO running solo, agent doing the work a junior used to do. Throughput per dollar is excellent. The ceiling is low. It works exactly as long as one person can hold the whole codebase in their head — somewhere between 15 and 25 employees, in what we’ve seen, before the spec/review surface gets too wide for one set of eyes.

A fractional senior, a permanent team. The team runs day-to-day. An experienced operator drops in to write the hard specs, review the load-bearing PRs, and show up when the agent goes sideways. The permanent team learns by watching. We see this most in the $5M–$50M revenue band — too small to justify a full-time CTO, too large to run without senior judgment anywhere in the loop.

Different shapes, same answer underneath: somebody is filling spec/review/escape, on purpose. The pattern that doesn’t work is the old one — hire two more engineers at the level you already have, and hope it sorts itself out. That’s the 2022 playbook running against a 2026 production function. It doesn’t fail loudly. It just quietly compounds the gap.

A note on fractional engagements

The shape of fractional-CTO work has changed alongside the shape of teams. The spec/review/escape function is exactly what an experienced operator brings to a small company, and the function divides neatly into hours: a few hours a week on direction, a steady cadence on review, on-call depth when something breaks. It maps onto the new team shape unusually well — and it’s one of the reasons we’re seeing more inbound interest in the model than we were a year ago. That’s an observation about the market, not a pitch. The relevant question for any specific team is whether it can fill the function internally, externally, or some mix — not whether to fill it at all.

What this doesn’t change

AI in the loop changes the math on a hiring decision. It doesn’t change a lot of other things that founders sometimes hope it will.

A bad founding spec. Faster execution just gets you to wrong faster. The agent won’t catch this — it’s not built to. The reviewer might, if they have the standing to push back on direction. Most don’t. This one isn’t an engineering fix at all.

A team that can’t disagree productively. Healthy disagreement turns ten okay ideas into one good one. Teams that paper over disagreement with politeness — or route it through the founder as arbiter — don’t start disagreeing well just because they added agents. They stay polite. The agent just writes whichever answer was easiest to agree on.

A codebase nobody wants to touch. Agents struggle in legacy code the same way people do. The difference is they fail quieter — you find out months later the agent’s been working around a load-bearing comment instead of with it. More senior engineers might help here. More agent-augmented juniors won’t.

An underperforming vendor relationship. If the agency isn’t delivering, adding agents to your side of the table doesn’t change the dynamic. You still need the scope conversation, the accountability conversation, the outcomes conversation. Same as always. Upstream of tooling.

The cost of hiring badly. A bad senior is still a bad senior, agent or no agent. If anything the cost is higher now — that one person is carrying more of spec/review/escape than they would have three years ago. The bar went up. It didn’t go down.

The shape of the call

The hiring math has shifted, and the founders who get this right are the ones treating it as a function-by-function staffing decision rather than a headcount decision. Three questions, asked honestly: who writes the specs, who reviews the work, who recovers when the agent breaks. Each function has to land somewhere — on the founder, on a permanent hire, on an experienced operator dropping in part-time, or on some mix. The wrong answer is “the agent will handle it.” The agent will not handle it.

What we keep seeing in the engagements that go well is that the staffing math is the first conversation, not the last. The team that figured out who’s holding spec/review/escape before they wrote a single line of agent-augmented code is the team that’s shipping clean work six months later. The team that bought the tooling first and figured the staffing would sort itself is the team we’re unwinding for.

If you’re looking at a hiring decision right now and the math feels like it shifted under you, let’s talk. Happy to walk through how we’d frame it for your specific situation.