23 posts tagged with "engineering-management"

There is a specific phrase that should make every engineering leader stop the meeting: "This will just work once the models get better." It is usually said with confidence, sometimes with a slide showing a capability curve bending upward, and it almost always marks the moment a roadmap quietly stopped being a plan and became a forecast.

The distinction matters more than it sounds. A plan is a sequence of things you control: code you will write, integrations you will build, tests you will run. A forecast is a bet on something you don't control — in this case, a model that doesn't exist yet, shipping on a schedule set by a vendor who has never promised you a date. When you scope a feature around "the context window will double" or "reasoning will be good enough by Q3," you have not de-risked the hard part of the problem. You have relocated it onto someone else's release calendar and called it done.

Your agent fleet opened forty pull requests this week. You reviewed the six that touched payment code, skimmed a few that happened to land while you had the tab open, and merged the rest on green CI. If someone asked you what your review policy is, you would describe something like this — and it is not a policy. It is a mood.

The numbers say most teams are in the same place. A recent large-scale study of agent-authored pull requests in popular open-source repositories found that 61% receive no recorded review activity at all, and of the ones that do get reviewed, most are reviewed only by other agents. Meanwhile the volume keeps climbing: agents now produce PRs, documents, support responses, and tickets at a rate no human review process was designed for. Reviewing everything is impossible. Reviewing nothing is malpractice. So teams improvise somewhere in the middle, with no stated rule, no measured coverage, and no way to say whether the current level of scrutiny is paranoid or reckless.

Manufacturing solved this exact problem a century ago. When Western Electric was churning out telephone equipment in the 1920s, inspecting every unit was economically impossible and shipping uninspected lots was unacceptable — so Bell Labs statisticians built acceptance sampling: a mathematically grounded discipline for deciding how much of a batch to inspect, when to reject the whole batch, and when a supplier has earned lighter scrutiny. It became MIL-STD-105 during World War II, then ANSI/ASQ Z1.4 and ISO 2859-1, and it still governs how a container of goods gets accepted at a port today. The mapping onto agent fleets is almost embarrassingly direct — and almost nobody in AI engineering has picked it up.

Your CODEOWNERS file encodes an assumption so old nobody remembers making it: the author of a diff knows whose turf they're on. A human engineer changing the billing service knows they're in billing territory. They scoped the change to their team's directories on purpose, and if they had to touch another team's code, they walked over — physically or on Slack — and gave a heads-up before the review request ever fired. Path-based review routing works because human authors pre-route their own changes.

Agents don't do this. An agent told to "migrate every deprecated logger call" sweeps the whole repository in an afternoon and produces a diff touching four hundred directories. GitHub dutifully consults CODEOWNERS, matches every glob, and fans the review request out to forty teams simultaneously.

Nobody asked those teams whether they wanted this change. Nobody warned them it was coming. And the "author" requesting their approval isn't a colleague they can grab for context — it's a bot account acting on behalf of someone in a different org who may not even know which teams got paged.

Every annual planning cycle in every engineering org runs on the same hidden equation: roadmap ambition divided by engineer output equals requisitions. It has been true for so long that nobody writes it down anymore. You size the work, you divide by what a team can ship in a year, and the remainder becomes a hiring plan. Finance builds the budget around it, recruiting builds pipelines around it, and managers build careers around it.

That equation quietly broke. In an agent-heavy org, the marginal unit of engineering output is no longer another senior hire — it is tokens plus the review bandwidth to absorb what those tokens produce. NVIDIA now hands engineers token budgets worth roughly half their base salary, and Jensen Huang has said he would be "deeply alarmed" if a $500,000 engineer consumed less than $250,000 of tokens a year. Whether or not you take the specific ratio seriously, the structural point stands: a company can now convert dollars into working code through two different doors, and the annual plan only has a form field for one of them.

Your next calibration meeting has a measurement problem nobody wants to name. The packet in front of the committee says one engineer shipped 340 PRs this half and another shipped 90. Five years ago that gap meant something. Today it mostly tells you who has the better agent harness, the more permissive review culture on their team, and the higher tolerance for merging generated code. The number on the slide measures the fleet. The committee is supposed to be evaluating the human.

This isn't a hypothetical drift that will arrive someday. Industry analyses estimate AI now writes on the order of 30% of committed code at companies that have adopted agents seriously, and a longitudinal study of 300 engineers found teams generating 98% more pull requests after agent adoption. Every output metric your review process inherited from the pre-agent era — lines changed, PRs merged, story points, velocity — is now a blended measurement of human judgment and machine throughput, with no attribution boundary between them. Calibration committees are comparing blended numbers as if they were still measuring people.

Your most productive engineer just gave notice. You know the drill: transfer the tickets, document the deploy process, hand off the on-call rotation, schedule the brain-dump sessions. The offboarding checklist has been refined over decades, and it covers everything the company thinks it owns.

Here's what the checklist misses in 2026: that engineer's home directory contains a personal CLAUDE.md tuned over eighteen months, a dozen custom skills that encode exactly how to navigate your gnarliest subsystem, memory files where their agent accumulated hard-won facts about your codebase, and harness settings calibrated through hundreds of sessions of trial and error. None of it lives in the repo. None of it transfers with the account.

On their last day, IT deactivates the laptop, and months of compounded agent configuration — the difference between their agent shipping features unattended and everyone else's agent flailing — evaporates without anyone noticing it existed.

The pitch for overnight coding agents is seductive: you go to sleep, the fleet works, and you wake up to finished pull requests. What actually happens is subtler and more expensive. You wake up to a queue — six branches, two failed runs, a dependency bump you didn't ask for, and a refactor that is either brilliant or subtly wrong. The agents did produce code. But the deliverable that landed on your desk isn't code. It's a triage problem, and most teams have no workflow for it.

The numbers say this isn't a niche complaint. A telemetry study of more than 10,000 developers across 1,255 teams found that high-AI-adoption teams merged 98% more pull requests — while review time rose 91% and average PR size grew 154%. Follow-up data from 2026 is worse: production incidents per PR roughly tripled, and 31% more PRs now merge with no human review at all. The bottleneck didn't disappear when agents started working the night shift. It moved to 9 a.m., concentrated into the first ninety minutes of your day, and got a name: the morning review queue.

A polished eight-page design doc used to mean something before anyone read a word of it. The existence of the artifact was evidence: someone spent two weeks thinking about failure modes, arguing with themselves about tradeoffs, and pre-empting the objections they knew reviewers would raise. The document was a receipt for the thinking. Reviewers could triage by polish alone, because polish was expensive to fake.

That correlation is now dead. An agent produces a comprehensive, well-structured, diagram-laden RFC in under an hour — complete with an alternatives-considered section for alternatives nobody actually considered. The artifact survived; the signal it carried did not. And most engineering organizations are still running a review process that was designed, implicitly, around the old cost of writing.

"What did you do yesterday?" is the first question of every standup, and on a team that runs agent fleets overnight it has become impossible to answer honestly. The literal answer is: I wrote three prompts, went home, and woke up to eleven pull requests, four of which I have not read yet. The person reciting their update is not lying on purpose. The ritual is lying for them, because it was built around an assumption that no longer holds — that the unit of work is a human doing one thing at a time, serially, during business hours.

That assumption is load-bearing. It holds up the burndown chart, the sprint commitment, the velocity number, the "blocked / in progress / done" columns, and the whole choreography of who-tells-whom-what-when. Pull the assumption and the artifacts don't gracefully degrade. They keep producing numbers that look authoritative and mean nothing. A team can have a beautiful burndown and a green sprint while half its actual throughput happened between midnight and 6 a.m., attributed to no one, reviewed by no one, and reflected in no ceremony.

For decades, the path from junior to senior engineer ran through a pile of unglamorous work. You fixed the typo in the error message. You wrote the unit test for the function someone else built. You traced a null pointer through four layers of call stack at 2 a.m. and learned, viscerally, why defensive checks exist. Nobody designed this curriculum. It emerged because the cheap, low-stakes tasks happened to be exactly the tasks that built judgment.

That curriculum is being deleted. The work that used to train juniors — boilerplate, first drafts, trivial bug fixes, test scaffolding — is now the work we hand to an agent because it's cheap and fast. We optimized away the grunt work without noticing it was also the classroom. The result is a skill ladder missing its bottom rungs: we still have seniors at the top, we have AI at the bottom, and a widening gap in the middle where mid-level judgment used to form.

This isn't a hiring problem you can solve by posting more entry-level reqs. It's a learning problem. The tasks that taught are gone, and the tasks that remain — reviewing agent output, decomposing ambiguous problems, deciding what not to build — are the hard ones we used to assume people earned the right to do. If you want senior engineers in 2032, you have to deliberately manufacture the experiences that used to happen by accident.

A team I talked to recently spent three engineer-weeks shaving their average prompt from 4,000 tokens to 2,600. They were proud of it — a clean 35% reduction, real numbers, a nice graph in the deck. Then someone did the arithmetic the other direction. The savings came to roughly $1,800 a month. The three engineer-weeks they spent getting there cost something like $25,000 in fully-loaded salary. At that monthly run rate, the optimization pays for itself in about fourteen months — assuming the prompt never changes, the model never gets cheaper, and those engineers had nothing more valuable to build.

None of those assumptions held. The prompt changed twice in the next quarter. The model they were on dropped its input price by 40% on its own. And the feature those engineers didn't ship that month was the one the biggest customer had been asking about.

The quarter your team adopted coding agents, two things happened that nobody put on the same slide. Throughput went up — more pull requests, more merged code, more tickets closed. And your three most senior engineers got slower. Not lazy-slower. Drowning-slower. Their own commits dried up, their calendars filled with review, and the one-on-one refrain shifted from "here's what I shipped" to "I spent the week unblocking everyone else."

This is the seniority inversion. The people whose time was supposed to get more leveraged by AI are the ones who got buried by it. And it isn't a motivation problem or a tooling gap. It's a structural consequence of what agents actually do to the shape of work: they make generation cheap and verification expensive, and verification is the one task you can't hand to a junior or to another agent.