Your AI coding agent gets a code review on every single commit. It gets test coverage checks. It gets mutation testing to prove the tests aren't fake. It gets a documented strategy for debugging when it goes wrong.
Your engineer got "good job, keep it up" at their last one-to-one. Eleven months ago.
I've been watching engineering leaders build the most rigorous feedback infrastructure I've ever seen for software. Meanwhile the humans writing the specs, reviewing the pull requests, and mentoring the juniors are still running on the same broken annual review cycle we've had since the 1990s.
It's backwards. And it's worth saying out loud before another team ships an agent framework with sharper accountability than its own management structure.
We Built Discipline for the Machines First
Robert "Uncle Bob" Martin spent four months researching what he calls Agentic Discipline, a set of practices for working with AI coding agents. The recommendations aren't vague. They cover testing and behavior-driven development, coverage and mutation testing, and explicit strategies for managing, debugging, and improving agent output.
Read the list again. Coverage metrics. Mutation testing to check the tests catch bugs, not merely run without errors. A management strategy and a debugging strategy, written down, for a tool nonexistent three years ago.
Now ask yourself how many of your engineers have a written, specific, current description of what "doing well" looks like in their role. Not a job description pulled from the hiring process. Something they were measured against last month.
Most leaders won't have an answer. We built rigorous feedback loops for the AI faster than we built them for the people who supervise the AI. Twenty years into agile, DevOps, and every management framework in between, and the machine got the tighter feedback loop first.
The Reason Isn't Mysterious
We didn't build rigorous feedback systems for AI agents out of visionary management thinking. We built them because an agent will happily produce broken code with total confidence, and broken code is expensive and visible fast. The incentive was obvious and immediate. Ship a bug, watch the build turn red, fix the process which let it through.
Bad management is expensive too. It's slower and quieter, which makes it easy to ignore. A team getting vague, infrequent feedback doesn't crash a build. It slowly disengages, stops raising problems early, and settles into doing the minimum required to stay off a performance improvement plan. There's no stack trace for it. There's attrition eighteen months later and an exit interview blaming "communication," which is corporate shorthand for a manager who never said anything specific enough to act on.
My own research found 99.5% of people have worked for at least one bad boss. Not "difficult." Bad. This figure should embarrass an industry willing to write a debugging strategy for a language model but not for the humans running the team.
Trust Isn't a Soft Metric, It's the Metric
Google ran a two-year study called Project Aristotle, analyzing 180 teams, 115 of them in engineering, across 250 different attributes, to work out what separates high-performing teams from average ones. The researchers expected the answer to be about who was on the team. Top individual performers. Experienced managers. Enough headcount.
They were wrong. The single strongest predictor of team performance was psychological safety: whether people felt safe enough to raise a concern, admit a mistake, or ask a question without getting humiliated for it. Google's conclusion was blunt. Even its most talented, highest-paid engineers still needed a psychologically safe environment before they'd contribute what they were capable of.
Compare this finding to how most engineering orgs run feedback today. One real conversation a year, scored against competencies nobody remembers agreeing to, delivered by a manager dreading it as much as the engineer is. It isn't a feedback system. It's a liability disclosure with a coffee attached.
What Agentic Discipline Looks Like for Humans
If you'd accept nothing less than mutation testing before trusting an AI agent's code, here's the equivalent bar for how you manage people.
Make feedback frequent, not annual. A once-a-year review is a coverage report run once a year on a codebase changing daily. It tells you almost nothing useful by the time you read it. Weekly or biweekly beats annual every time, because the correction lands close enough to the event to change behavior.
Make it specific. "Good job" isn't a test case. It doesn't tell your engineer what to repeat. Name exactly what worked, on exactly which piece of work, close enough to the moment for them to connect it to the decision they made.
Build a debugging strategy for people too. Good practice with a misbehaving agent means looking at the process, not only the output. Do the same when a team member is struggling. Is it a skills gap, an unclear expectation, or a fear of asking for help? Those need entirely different fixes, and you won't know which one you've got unless you ask.
Measure whether people feel safe enough to speak up. This is the part most leaders skip because it's harder to quantify than a build passing. Skip it and you're optimizing for the wrong thing, the same way you'd be optimizing for the wrong thing by shipping code with high coverage and zero mutation testing. It looks solid until it isn't.
I wrote about the mechanics of this in more detail on Step It Up HR, specifically how leaders turn mistakes into learning moments instead of blame sessions. The short version: the response to a mistake, human or AI, decides whether it happens again.
The Excuse Won't Hold Much Longer
I hear the same objection every time I raise this with engineering leaders: feedback for humans is harder than feedback for code, because people have feelings and context and bad days. Fair. But difficulty isn't a reason to skip a discipline. It's the reason to build one deliberately instead of leaving it to whichever manager happens to remember to schedule a one-to-one this quarter.
Nobody would accept "people have feelings" as a reason to skip test coverage on a payments system. The stakes for getting human feedback wrong are higher, not lower. A bad review doesn't throw a stack trace. It costs you a good engineer, quietly, over the following year, while you're busy congratulating yourself on your CI pipeline.
The Bar You Already Believe In
Nobody reading this would ship an agent to production without a testing strategy. You already believe in rigorous, specific, frequent feedback. You haven't pointed it at your people yet.
It isn't a technology problem. It's a discipline problem, and discipline is the one thing no leader should outsource to the model.
So here's the question worth sitting with this week: if your engineers got the same standard of feedback you demand from your CI pipeline, what would change first?