Agentic Coding Changed Our Team Shape, Not Our Headcount

We have been running agentic coding tools across every production project since January, so we are past the honeymoon phase and past the backlash phase. Time for an honest field report.

The headline: our team is the same size it was a year ago, we ship roughly twice the surface area, and the job of a senior engineer here looks meaningfully different than it did in 2024. Anyone telling you these tools change nothing is not using them seriously. Anyone telling you they replace engineers has never shipped a client site with a hard launch date.

What actually got faster

The wins are real but they are not where the demos suggest. Greenfield scaffolding was never our bottleneck. What changed our week-to-week velocity:

• Migrations and refactors that used to be "someday" projects now happen in an afternoon. We moved a legacy client codebase off a deprecated CMS SDK in two days. That was a three-week estimate last year.
• Test coverage went up because writing tests stopped feeling like a tax. Agents are relentless about edge cases humans get bored of.
• Cross-stack fluency improved. Our frontend engineers now confidently touch infrastructure code with an agent pairing on the parts they do not know cold.

What did not get faster: deciding what to build, understanding a client's actual constraints, and debugging the genuinely weird stuff. If anything, those got relatively more expensive, because they are now most of the job.

Review is the new writing

The biggest cultural shift is that code review became the center of gravity. When an agent can produce five hundred lines in the time it takes to refill your coffee, the scarce skill is reading those lines with real skepticism. We rewrote our review norms this spring around one principle: the person who prompted the change owns it exactly as if they typed it.

We also got strict about diff hygiene. Agents love to helpfully reformat things they were not asked to touch, and that noise is where bugs hide. Our pre-review checklist now includes a hard rule:

# Reject any PR where the diff touches files
# outside the stated scope of the task
git diff --stat main...HEAD

If the stat list surprises you, the PR is not ready. Simple, boring, effective.

The junior engineer question

Everyone in the industry is wringing their hands about what happens to junior engineers, and we think the panic is half right. The old on-ramp, where you learn the craft by grinding through small implementation tickets, is genuinely eroding. Agents eat those tickets.

But the conclusion most people draw, hire fewer juniors, seems backwards to us. We are instead changing what juniors do: more time reading production code, more time in review alongside seniors, earlier exposure to client conversations. The goal is to compress the path to judgment, since judgment is now the whole game. Grace on our team has been mentoring with this model and the early results are encouraging.

Where we are cautious

We do not let agents near credentials, deploy pipelines, or anything touching client data without a human executing the final step. We treat generated dependencies with suspicion until a person has actually read the package. And we budget explicit time for engineers to code without assistance, because the skill of writing from a blank file still underpins the skill of evaluating what an agent hands you.

The tools will keep improving through the back half of this year, and our practices will keep shifting. But the core lesson feels durable: these are leverage machines, and leverage amplifies whatever judgment you already have. Invest in the judgment.