A tense break room visit

Priya, a junior on your team, shipped five pull requests this week. Five! Look at her go. Three years ago she’d have shipped one, maybe two, and one of those would have been a typo fix. The velocity dashboard is glowing. The standup is upbeat. Somebody in management is using the word “leverage.”

Meanwhile, your principal engineer Marcus hasn’t merged anything in eleven days. He’s been in the review queue. He looks like he’s seen things. You ask him how it’s going and he stares at you for a beat too long before saying “fine.”

When you dropped a spoon in the break room yesterday, Marcus jumped so hard he coated the entire room in a thick brown slurry of cold brew and oat milk.

Leaving Marcus to clean up the mess, you walked back to your room and stared at all of those green arrows on the dashboard. So much green quit looking like up and started looking like an imposter wearing up’s clothes.

Something is wrong here. Let’s talk about what.

Three People, All Shaken, All Quiet

It isn’t just Marcus, and it isn’t just you.

Marcus is drowning, but not the way you’d think. It isn’t the number of PRs in his queue. It’s what’s in them.

It’s the third implementation this month of a thing the codebase already does, in two other places, under two other names. It’s the new utility module that quietly duplicates half of an old utility module, because nobody – not the AI, not the junior – checked. The codebase isn’t getting better. It’s getting fatter. More code, doing less, every week.

He used to be the person who saw the elegant move others missed. Now he’s a fraud-detector for code that came out of a tool. Merge a bad PR, the codebase rots and it’s on him. Reject too many, he’s the bottleneck. Reject not enough, he’s “not adapting.” He doesn’t see any of this changing any time soon, and in the darkest part of his soul, he fears he’s the problem.

Down the hall, the promising and relentlessly positive Priya is sitting at her desk reading a code review comment for the fourth time. The comment says this doesn’t match how we handle errors elsewhere in the codebase. Her code works. The tests pass. Marcus is not wrong; she can tell that much. But she doesn’t understand the comment well enough to fix it.

She tries prompting differently. The new code also works, and maybe it’s a little bit better, but she can tell it’s not quite right. She feels like the middle layer between Marcus and the AI, and this whole application exists to cut out the middleman. So she sends it back up. The thing she can’t say out loud, even to herself, is that her code is shipping and she is not learning.

With a deadline looming, the silent voices are niggling at her conscience. If she misses it: the tools are right there, why didn’t you use the leverage. And if she hits it: imagine what we could do with half the team.

Three people, one trap: heads the tools win, tails the humans lose. Nobody in this trap is going to be the first one to say the thing we are measuring is the thing breaking us. You can’t take that to your boss. So everyone stays quiet, and ships more, and reviews more – and the dashboard stays green, and the sludge keeps creeping down the wall.

Let’s stop talking about our fictional team and start talking about us. Leave the stain on the wall. We’re not ready to mop it up yet.

I Can’t Prove It, But

If you’ve been substituting names from your own team, you’re not the only one.

I don’t have a survey. I don’t have a study. What I have is a few years of being in the rooms where this stuff actually shows up – teaching it, training teams on it, consulting on the messes it causes, and, if I’m being fully honest, making a few of the messes myself. That doesn’t make me right about everything. It does mean I’ve been in a lot of rooms where people stop performing once the door closes, and the thing they say once they stop performing is, with surprising consistency, some version of what you’ve been reading.

Here’s what I think is happening: this is everywhere. Not in some teams. Not in the bad ones. Everywhere. The flavors differ – different stacks, different team sizes, different ratios of seniors to juniors – but the shape is the same. Velocity up. Quality sliding. Seniors flinching. Juniors either stuck or already fired. Managers measuring numbers they no longer trust.

I can’t prove it. The data we’d need is the data we aren’t collecting, because the things going wrong aren’t the things our dashboards know how to count.

But I’m saying it anyway, because the silence is part of the disease. Every team I talk to thinks their version of this is a local failure. They are embarrassed. They don’t bring it up at conferences. They don’t write the blog post. So everybody quietly assumes everybody else figured it out, and the silence holds, and the stain spreads.

You did not figure it out. They did not figure it out. Nobody figured it out yet. And we can’t get anywhere better from here as long as we’re each pretending, in our own little office, that the thing on our wall is the only one of its kind.

Consumable, Reviewable, and Right

A warning: if I tell you what’s wrong with AI-generated code right now, half of it will be stale by the time you read this. The specific design failures keep moving. The misshapen code Copilot produced in 2023 is not the misshapen code Cursor produced in 2024 is not the misshapen code our Claude Code agents are producing this week.

Let’s talk about what doesn’t move.

Good code, regardless of who wrote it or how, has always had to be three things: consumable, reviewable, and right. Consumable means a human reviewer can load it into their head. Reviewable means the pull request is shaped so a finite amount of attention can evaluate it without guessing. Right means it fits – not the abstract idea of a codebase, but this codebase, with its particular idioms, its particular layering, its particular history of decisions that look arbitrary until you’ve been here long enough to know they aren’t.

Those three properties used to come for free, because writing code was slow. The cost of typing forced a kind of natural shape. The act of writing was the act of designing, whether you noticed or not.

That cost is gone. And so is the shape it used to give us.

The code isn’t consumable anymore because chunk sizes have grown exponentially, are growing, will keep growing. The senior has fifteen minutes. So, the code isn’t reviewable. Pull requests are one shot deliveries instead of conversations. They don’t tell the reviewer what changed, why it changed, where the reviewer’s attention should land. The author had a prompt and an output. The diff is a result, not an argument. And the code isn’t right – right is local. The code is fluent in the language. It’s competent in the abstract. It’s misshapen for here. Error handling from somewhere else. Architectural patterns from somewhere else, and so on. And the math doesn’t add up anymore.

So the code is gradually but certainly slipping, with compounded interest that eventually dooms us. The tools will keep getting better at producing code. They will not get better at making it fit your codebase, your team, your idioms. Closing that gap is human work, and it’s work the system isn’t currently doing.

The Symptom in the People

The cost of all this is paid by humans, in three places.

The senior pays in craft. Marcus’s review queue has stopped rewarding the things he’s good at. He used to be the person who saw the elegant move others missed. He’s not doing that work anymore. He’s pattern-matching against bloat. The judgment muscle is still working. It’s working on triage, not on craft.

The junior pays in learning. Priya is shipping more code than any junior in the history of the team, and learning less from it than any junior in the history of the team. The feedback loop that used to teach a junior – write something, get it wrong, understand why, write it better – has been replaced by something faster and dumber: prompt something, get something, send it up, prompt again. The system she is in does not produce learning, even when she does everything right inside it.

The manager pays in legibility. The VP is running her team on instruments she no longer trusts. The dashboards she has tell her about output, which used to correlate with health and now doesn’t. The things she actually needs to know – is the team getting better, is the codebase getting better, are we growing the seniors we’ll need in 2030 – don’t have numbers on any screen she can show her boss. She steers with what she’s got and pays in a low, constant anxiety that something is wrong and she can’t name it in a meeting.

These are not three different problems. They’re one problem with three different bills. The senior is being asked to do work the system doesn’t grow him through. The junior is being asked to ship code the system doesn’t teach her from. The manager is being asked to steer with instruments the system doesn’t read. None of them are doing their jobs badly. They are doing exactly what their roles ask for, inside a system that has quietly stopped delivering what their roles need in return.

This is the symptom we don’t talk about, because it doesn’t show up in code review. It shows up in the people getting worse at their jobs while looking like they’re getting better at them. And it’s a bill that compounds, every quarter, every release, every standup where everyone smiles and nobody mentions the brown spot on the wall that has gotten a little bigger since we started.

The Gap That Used to Save Us

For the entire history of programming until about three years ago, there was a gap between making a small mistake and that mistake mattering. You wrote something a little off. It sat there. By the time the wrongness came home, you’d had a week, or a month, or sometimes a quarter to learn enough about the system to recognize it when it arrived.

That gap wasn’t a feature anyone designed. It was a consequence of slowness. It was the medium in which judgment grew. Apprentices became craftspeople by being wrong in survivable ways, repeatedly, with enough time between the wrongness and the consequence that they could connect the two. That connection – between a specific mistake and its specific aftermath – is what judgment is made of. Take away the gap and you don’t just get faster failure. You get failure that doesn’t teach.

The gap is closing. A misshapen pattern in a Tuesday PR is in three services by Thursday. The next round of AI suggestions is learning from it before anyone has noticed it’s wrong.

The dominant feeling at the end of a hard week used to be I made a mess. The dominant feeling now is wow, that escalated quickly. Those are not the same. The first comes with a sense of agency – you did the thing, you can fix the thing. The second comes with a sense of velocity you don’t control. In short, we are running an apprenticeship system that was designed around a safety margin that no longer exists.

The Gift We’re About to Waste

After six sections of bad news, here’s the most important thing in this article.

If I am being honest, AI has taken something from all of us. It has also given us something.

Time. Real, daily, recoverable time. Time we used to spend typing, looking things up, writing the boring half of every function. That time used to disappear into the act of producing code. It doesn’t anymore. It lands on our doorstep every morning now, whether we asked for it or not. It is, by any reasonable accounting, a dividend.

The crisis isn’t that we have less of anything. The crisis is that we got more, and we are spending all of it on producing more code, faster, with fewer of the people who used to know how to keep code good. We are cashing the dividend the moment it arrives. We are not reinvesting any of it.

The version of this story where we keep doing that ends in a specific, predictable place. No juniors. Exhausted seniors. Brittle codebases. No pipeline of architects, because the people who would have grown into that role got fired in their second year for not being productive enough at things they were never going to be allowed to learn. That’s eating our seed corn.

There is another version.

In the other version, we treat the time AI gives us as exactly what it is – a gift, and a dividend we get to choose how to reinvest. And the only place to put it that has a future-shaped return is in the people who are going to be the seniors in ten years. Not by making them ship more. By making them better. By giving back the gap that used to grow judgment. By giving back the design conversation that used to live inside the work. By giving back the trash can.

More articles are coming. The next one is the cautionary tale – what it looks like when a company spends the dividend the wrong way for eighteen months. After that, the prescription, and the new direction.

But none of it will help anyone who hasn’t made one specific decision. There’s a pact, and it’s small, and we have to make it now.

The Pact

The pact is small. Some of the time AI is giving us belongs to the future of the craft, not to the next sprint.

That’s it. Everything in the rest of this series – the cautionary tale, the prescriptions, the new direction – assumes you’ve made it.

Doing nothing with it is a choice too. It’s the choice most of the industry is making right now. It looks like productivity. It feels like leverage. (Sorry. Had to.) And it ends with no future, because futures don’t build themselves out of the people you fired for not being good enough yet.

We’ve been given time. Let’s spend it on the people who’ll still be here when we’re not.

The stain is still on the wall. Marcus is still in the queue. Priya is still pressing accept. None of them know yet that there’s another way. That’s what the rest of this series is for.

See you in the next one. It’s the cautionary tale. Bring popcorn.

— Bruce