I watched a demo of an AI reviewing a pull request last week. It caught a null pointer bug, flagged a security hole, and left three comments a senior engineer would have been proud of. All in about four seconds.
Then I sat in a leadership meeting the same week where nobody had an answer to a simple question: is the team okay?
Not "are they hitting sprint goals." Not "did the release ship." Simply: okay. Nobody had checked. Nobody had a system for checking. We built the machine reviewing code before it ships, and we still don't have one reviewing whether the humans writing it are burning out.
This gap is the story worth telling. Not AI replacing developers. The other half of the story nobody wants to fund.
The Numbers Tell Two Different Stories
Here's what's true about code right now: 22% of merged code at the median company is now AI-authored, according to DX's Q4 2025 AI-Assisted Engineering Impact Report. Daily AI users push it closer to 24%. It sat near zero three years ago.
Here's the catch. Veracode's 2025 GenAI Code Security Report tested 100+ large language models across 80 coding tasks and found 45% of AI-generated code contains a security vulnerability. Nearly half.
So companies raced to build tools catching this. Automated review, security scanning, agents flagging the bad diff before a human ever sees it. Good. This is the right response to a real problem.
Now here's the other number. Gallup's 2026 State of the Global Workplace report found global employee engagement fell to 20% in 2025, the lowest level since 2020, and the first two-year decline on record. Gallup puts the cost at roughly $10 trillion in lost productivity worldwide. Nine percent of global GDP, gone, because people showed up and checked out.
We built a review pipeline for code. We let the review pipeline for people rot.
Why This Isn't A Coincidence
I don't see these two numbers as unrelated. I see them as the same failure wearing two different outfits.
Automating code review says: we don't trust unreviewed output, and we're willing to build infrastructure to catch problems before they compound. A mature engineering culture talks this way.
Skipping a culture review says the opposite. It says: we'll trust people are fine until they quit, or burn out, or start shipping mediocre work because nobody asked how they were doing in eighteen months.
I built StepUp2Bat because I got tired of watching companies do this exact thing. They'd sink six figures into tooling and pipelines, then run an annual engagement survey everyone knew was theater. Nobody read the results. Nobody acted on them. The survey turned into the thing you did instead of knowing your people, not the thing telling you the truth.
An AI code reviewer runs on every single commit. Your culture "reviewer," if you have one at all, runs once a year and takes three months to produce a PDF nobody opens.
What Reviewing Your Culture Means, In Practice
I'm not talking about vibes here. I'm talking about the same discipline you already apply to code, pointed at people.
Frequency beats depth. Nobody catches a bug by reading the codebase once a year. You catch it by reviewing constantly, in small chunks, close to when the change happened. The same holds for a team. A quick pulse check every two weeks beats a forty-question survey every twelve months, because you catch the problem while it's still small and fixable.
You need a diff, not a snapshot. Code review works because it shows what changed, not the current state alone. Culture "review" usually measures a snapshot: how people feel right now. This tells you almost nothing. What you need is the delta. Is trust rising or falling since the reorg. Did burnout spike after the death-march release. A snapshot won't answer this. A trend line will.
Somebody has to own acting on it. A code review nobody merges is worthless. A culture survey nobody acts on is worse than worthless, because it teaches your team speaking up doesn't matter. If you're going to ask, close the loop. Tell people what changed because of what they said.
The Leadership Failure Is Older Than AI
I've written before about research I ran finding 99.5% of people have worked for at least one bad boss in their career. This number predates the whole AI conversation. It isn't new. What's new is the contrast getting sharper.
A machine now reviews a thousand lines of code in the time it takes you to get coffee, catching things a tired human reviewer would miss on a Friday afternoon. Meanwhile the average manager still has zero structured way to catch a top engineer sitting three weeks from quitting.
This gap used to be invisible because everything moved at human speed. Now the code side has sped up so hard the human side looks frozen by comparison. Leadership didn't get worse. Everything else got faster, and leadership stood still.
Stop Bolting Culture Onto The End
The instinct in most companies treats culture work as a separate track from technical work. Engineering gets the tooling budget. Culture gets an all-hands slide and a Slack channel nobody posts in.
This is backwards. If you're serious enough about quality to build an automated review pipeline for code, you already believe in continuous, structured feedback as a principle. You haven't applied this principle to the humans writing the code yet.
The tools for this exist now. You don't need a custom system to run a two-week pulse check or track a trust trend line over time. You need to decide it matters as much as the code does.
The Question Worth Sitting With
AI keeps getting better at catching what's wrong with your codebase. This part of the story is mostly solved, and it's only going to automate further from here.
The part nobody has solved, and better models won't solve it either, is whether anyone in your company does the equivalent work for your people. So here's the question I'd ask, in your shoes: if your code gets reviewed on every commit, and your culture gets reviewed once a year in a survey nobody reads, what does this tell your team about which one you genuinely think matters?