DEV Community: Jeremy Andrews

Nobody defends code reviews at 11pm

Jeremy Andrews — Tue, 09 Jun 2026 19:38:01 +0000

"How could you let this happen?"

I've been in that conversation. On both sides of it, at different points.
It's a versatile question.

The first time I heard it from above, we'd shipped something that shouldn't have shipped in the state it was in. Bugs that a proper code review would have caught. QA that got compressed in the final days because another part of the project ran late and the deadline didn't move.

Nobody decided to skip code review. Nobody said "let's just ship it broken." What happened was simpler and more predictable: the deadline was fixed, the timeline snowballed, and the back of the chain got squeezed. Code review and QA are always at the back of the chain. When time runs out, they're where the time comes from.

Everyone agreed at the start of the project that they mattered. Someone always raises it at the end, too. They're not wrong, but the deadline is rarely swayed by a good point.

I've done the same thing in how I talk about work. For a while, I praised speed without understanding what was being traded to get it. "You turned that around fast." Said with genuine appreciation. Received as instructions.

When I realized it, I tried to correct it.
Refused to let reviews be where the time came from.
Ensured they stayed in the planning estimate.
Made them a line item, not an afterthought.

It held until the next hard deadline, which arrived on schedule. Then the timeline snowballed again, for reasons that had nothing to do with code review, and the question was: what do we compress?

Same answer as always.

Engineers respond to incentives. We already know what happens when quality controls live at the end of a compressed schedule: they get cut. Critical thinking is increasingly vulnerable to the same pressure.

I know, because I've been the person setting those incentives. I didn't mean to. I praised speed.

Timelines were slipping long before anyone knew what a token was, but AI has made the path of least resistance feel productive. When you can offload work and still hit the deadline, it's genuinely hard to argue against in the moment. Especially when the alternative is staying late, losing the argument, and watching the code review get cut at 11pm anyway.

The obvious fix is to hand the review to AI.
Faster than a human.
No one has to stay late.
The process technically still happens.

Except AI reviewing AI-generated code means nobody has actually looked at it. The thing that slips through under pressure isn't always a syntax error. Sometimes it's the change that broke an assumption nobody documented.

The path of least resistance isn't laziness. It's what you get when you've asked people to be excellent under conditions designed to prevent it.

Speed pressure keeps building.
People get more depleted.
Exhaustion makes the easiest options more attractive.
The easiest options still hit the deadline.
Speed gets praised.

The loop runs itself, quietly, while everyone's still arguing about who let this happen.

One of the fixes I keep coming back to isn't structural.
Protected reviews.
Line items in the estimate.
I've tried those.
They tend to last until the next deadline, which is to say they don't last.

What I think actually sticks is what gets named. I'm not talking about a process doc. When someone pushes back on a compressed timeline and catches the thing that would have shipped broken, that has to come up in the next 1:1. It needs to be praised and I have to be the one to tell that story.

Process follows incentives. It's never the other way around.

What interests me isn't whether people are making bad choices.

They're humans. I know they are.

It's that the system reliably produces the outcome it claims not to want.

Everyone agrees code review matters... until the deadline, at which point it becomes a philosophical position.

Everyone agrees judgment can't be outsourced... until the velocity report.

And when something breaks, someone inevitably asks the question.

The mercy of hard things

Jeremy Andrews — Mon, 08 Jun 2026 01:27:10 +0000

The other day I watched an engineer spend three days on a piece of the codebase nobody had touched in two years.

Should've been a four-hour fix, except...

The senior who built it was gone.
The documentation was sparse.
The code only made sense if you'd been in the room when the decisions were made.

They could've asked me to rewrite it. I would have.

Instead they sat with it.
Read through the git history.
Traced the logic forward and backward.
Built a mental model of why each piece was there.

By the end, they didn't just fix the bug. They understood the system.

I asked them why they didn't escalate it.

"I needed to know how this worked," they said. "If I'd just had you fix it, I wouldn't know."

I checked in twice that week. Both times they were still in the thick of it. I had a deadline breathing down my neck and a fix I could've written before lunch.

I'm not going to pretend it was easy to watch.

That three-day tax on understanding used to be everywhere in engineering. It still is, but it's getting rarer and we're very proud of that.

The logic is tempting. Why spend three days when AI could spend three minutes? Why put junior engineers through the pain of understanding when they could generate a fix instantly? Why not move faster?

Three minutes gets you a fix. Three days gets you something else.

Systems have shapes.
Those shapes have reasons.
Understanding the reason is the actual work.

That's the thing that separates someone who can patch code from someone who can steward it. I've been both, sometimes in the same week.

Those three days weren't a gift I was giving them by staying out of the way. They were the part of the job that was changing my developer.

There's an argument going around that if you have an idea and Claude can build it, you have no excuse for not shipping. That's true, as far as it goes.

But the grind isn't dead weight. It's a filter. The person with a vague idea about "an AI agent for our workflow" and the person who's traced where the data goes and what breaks when the API times out are not the same person.

It used to be obvious before anything shipped, because nothing shipped until you'd earned it. That felt like a feature at the time, but mostly it was called a blocker.

What AI is actually collapsing isn't a barrier to capability.
It's a barrier to mediocrity.

That's a different crisis than anyone's talking about.

When execution was hard, you had to believe in the thing before you built it.
You had to think through the architecture.
You had to anticipate problems because debugging would be expensive.
You had to write documentation because the code would outlive your memory.

These weren't best practices.
They were necessities.
Having no shortcut made them automatic.

I complained about this at the time. The week of planning before writing a line of code felt like overhead. It wasn't.

Now you can spin up a system in an afternoon that would've taken weeks, held together with prompt engineering and middleware and a lot of hoping nothing breaks in production.

Not because you're lazy. Because you can.
Because nothing forces the hard architectural thinking upfront.

I've done it. Shipped a workflow last month that I couldn't fully explain if someone asked me to trace a failure through it.

It worked.
The demo was clean.
The tests passed.
I moved on.

That's the part that should worry me more than whether the engineer took three days.

The engineer could've used AI on day one. For the fix itself, they probably should have. They didn't, at least not until they understood what they were looking at.

I told them as much after the fact. They nodded, then asked if they could walk me through what they'd found. They were excited about it.

We were on a call five minutes later.

AI didn't create this moment. It just made the choice visible. You can move fast and hollow, or you can move with discipline.

You just can't hide from which one you're choosing anymore.

When the right answer is a smaller project

Jeremy Andrews — Sun, 07 Jun 2026 21:20:36 +0000

"I'd hate for us to throw the experience away when we just spent so much time and effort building it."

I heard that sentence a week after the data came in on a project we'd spent six months building. We still hadn't fully processed what the numbers meant yet.

I recognized it immediately. Not because it's inherently wrong, but because I've said versions of it myself over the years.

We set out to build a personalized recap landing page for a big annual conference. The kind of thing that felt like the event actually remembered you were there. Which sessions you attended. Which topics kept pulling you back. A tailored summary of your individual event experience.

Real engineering ambition.
Real design work.
Six months from a team that cared about getting it right.

But somewhere along the way, the API access we needed to do it right fell through.

No individual user data meant we couldn't actually personalize based on your unique experience. So we pivoted to segmentation: figure out which session topics someone attended most, assign them a persona.

You attended a lot of AI sessions? You're an AI Persona. Here's your badge.

In fairness, the badge was accurate. The segmentation worked. The problem was that accurately telling people something they already knew about themselves was not exactly the vision we'd pitched six months earlier.

The original idea kept getting diluted. We shipped it anyway. Given where we were, that was the right call.

The data came back thin.

Not zero. Not embarrassing. Thin enough to tell you something honest about how many people in that audience actually wanted this kind of experience.

That's a finding about appetite, not execution. The API falling through hurt the product, but I don't think it changed the fundamental signal.

I was still sitting with those numbers when the first conversations about next year started, and that's when I heard the sentence.

I understood the instinct completely. Six months of genuine effort from real people. Treating that as sunk cost and moving on feels like dismissing the work (and the people who did it).

But I kept turning it over. And eventually I landed on what was bothering me: the six months are already gone. We can't un-spend them. The question the data is actually answering isn't whether to throw the work away. It's what size of opportunity we were building for.

Thin numbers have a pretty clear answer to that question.

That context changes the next planning conversation significantly. Or at least it should.

It doesn't mean we do nothing next year. It means we need to ask seriously: what does this opportunity actually warrant?

Because there's a version of this project that takes two weeks. A lighter integration. Simpler segmentation. Something that ships fast and still tells you everything the six-month version told you, except you get nearly half a year back to spend somewhere else.

When the data tells you the opportunity is smaller than the investment, the answer probably isn't "let's just build it better."

Sometimes it's: right-size the project to match what we know.

The tricky part is that sunk cost reasoning almost never announces itself as sunk cost reasoning.

It announces itself as loyalty. As not wanting to waste good work. As giving a team's effort the respect it deserves.

These are real and reasonable feelings. They belong somewhere in the conversation.

They're just not planning criteria.

What six months of work actually produced was a finding: this opportunity is smaller than we thought going in. The smart move is to let that finding shape the next decision, not work around it because it's uncomfortable.

Have you been in a room where the data pointed one direction and the planning cycle went another?

I'm curious whether right-sizing ever actually won, or whether the room kept reaching for the six-month vision because walking away from the experience felt worse than ignoring the data.

Share your experiences below!

Notes from a hammock

Jeremy Andrews — Sat, 23 May 2026 02:55:33 +0000

I am writing this from a hammock.

Not metaphorically. I've been spending more and more of my time away from screens, trying to remember what thinking feels like without a notification interrupting every four minutes. I have a Remarkable tablet now. E-ink, no Chrome tabs, no Slack unread count haunting me from my peripheral vision. I read on it. I take notes on it. It is, embarrassingly, one of the better decisions I've made in the last few years.

This writing started there. Not as any sort of content strategy, but as a quiet place to muse.

I have a sociology and psychology background that I use every single day, which often surprises people to learn since I'm an engineering manager. The path wasn't linear. I graduated into a bare job market, picked up where I left off the previous summers at the NC Department of Transportation, doing everything from data entry to assisting with fatal crash investigations (you know, normal job stuff).

I eventually ran into an old friend at a poker game, someone I hadn't seen in years, who needed someone he could trust on a two-man dev team after his partner abruptly left the company. That conversation landed me at an agency for nearly a decade doing website optimization, A/B testing, and personalization. Which is, when you think about it, the applied science of understanding how humans make decisions and designing systems that help people get where they're trying to go.

The sociology degree wasn't a detour. It was the whole point.

Now I manage a development team and spend a meaningful portion of my days watching the AI conversation unfold, feeling a specific kind of unease I've been trying to articulate. Here's my best attempt.

Judgment is a muscle. A functional capacity that gets stronger the more you use it and weaker the more you outsource it. Psychologists call this cognitive offloading: the habit of shifting thinking onto external tools. The research shows it doesn't just change what we do, it changes how we approach problems even when the tool isn't there.

When people repeatedly have decisions made for them, they gradually stop trusting their own judgment. Not because they become less capable, but because the loop gets interrupted: making the call, sitting with uncertainty, being wrong and recalibrating. The muscle doesn't disappear overnight. It quietly becomes less reliable, and eventually you stop reaching for it even when you could.

We've already run a version of this experiment. We handed our attention spans to engagement algorithms for fifteen years and then wondered why it became harder to sit with a complex idea. The systems weren't designed to destroy depth. They were designed to maximize engagement, and it turned out that depth was friction, so the systems smoothed it out. The result isn't that people became lazier or less intelligent. It's that the environment stopped requiring them to sustain attention, so sustaining attention got harder.

AI is a different technology with a different purpose, but the dynamic is worth taking seriously. Every time someone outsources a judgment call they were perfectly capable of making, about tone, about approach, about whether something is actually a good idea, that capacity gets just a little smaller.

One call doesn't matter. Millions of calls, across a workforce, over a decade, and you haven't built a more efficient society. You've built one that is very good at reviewing AI outputs and not much else. Which is, coincidentally, a workforce that is significantly easier to manage, to commoditize, and to eventually replace.

I'm not anti-AI. I'm building agentic systems right now, and I think the version of this future where machines absorb the tedious, grinding work and people get their time back for things that actually matter is real and worth building toward. That future requires deliberate thinking about which judgment calls we hand off and which ones we protect.

Right now that deliberateness is mostly absent from the conversation. The race is to automate. The question of what we're training people out of along the way tends to get scheduled for a later meeting that never happens.

So that's what this is. A place to read carefully, think slowly, say the uncomfortable thing without dressing it up, and openly ask what we're actually optimizing for and who pays when the optimization is wrong.

The hammock helps. Sometimes the best thinking happens when the machine isn't in the room.