Seif Mamdouh

If You Don't Understand It, Don't Fucking Ship It

TL;DR

Agents can now write more code than you can review, and that makes understanding, not generation, the bottleneck.

  • This post takes Addy Osmani's AI Engineer World's Fair keynote. His rule: "explain it or don't ship it" and runs it through my day job building agents at RecuraAI.
  • Three traps to watch for:
    • Cognitive debt: code exists in your repo that nobody on the team understands.
    • Cognitive surrender: the AI's answer becomes yours before you've formed one.
    • Orchestration tax: ten parallel agents ≠ ten of you; attention doesn't parallelize.
  • Let agents run the inner loop: implement, test, report.
  • The outer loop: deciding, verifying, owning what ships is the engineering job now.
  • If you can't explain the diff, don't merge it.

The merge button moment

You know the moment. The agent hands you a diff. Tests pass. The build is green. The PR description is beautifully written; better than anything you'd write at 6pm on a Thursday. Your cursor is hovering over merge.

And if you're honest with yourself, you cannot explain what half of it does.

I hit this moment constantly. I build agents for a living at RecuraAI. Which means several times a week I'm staring at code I didn't write, in a system I'm responsible for, deciding whether it ships to clinics that will notice if it's wrong.

I recently just watched Addy Osmani's closing keynote at the AI Engineer World's Fair, and he gave the moment a name. His operational rule for this era is six words: "explain it or don't ship it."

Not because humans have to type every line. Not because AI code is bad. But because someone has to understand the work well enough to defend it when it breaks.

The agent can follow your runbook. It cannot inherit the consequences.

The question flipped

The talk's sharpest move is flipping the question we've all been asking. "What can the agent do?" is a dead end that list grows every model release, and building your identity around it means being obsoleted quarterly. The better question: what can only a human be answerable for?

Osmani frames the engineer's real output as a verdict: does this ship, do we block it, do we redirect it, do we accept the risk? Quality work produces evidence. A verdict assigns responsibility. And you cannot assign responsibility to a process that vanishes when the tokens stop streaming.

The industry data he cites makes this concrete in an uncomfortable way. Per Sonar's 2026 research, nearly everyone 96% is skeptical of AI generated code. But only about half of engineers consistently verify it before committing. Sit with that gap. We distrust the code and ship it anyway, because generation got cheap and verification didn't. That's not a tooling gap. That's distrust without bandwidth, and it's how systems rot while every individual PR looks fine.

Three traps I keep falling into

Osmani names three failure modes. I recognize all of them from my own weeks, which is exactly why they stung.

1. Cognitive debt

Cognitive debt is the gap between how much code exists in your repo and how much any human on your team genuinely understands. Tests passing doesn't close it. A merged PR doesn't close it. You can have a green build and a team that can no longer explain the system it's shipping.

I felt this hardest with our EMR sync pipeline. An agent can extend a data mapping across a new EMR platform in an afternoon. That's work that used to take me a week. But the first time one of those mappings did something subtly wrong in production, the question wasn't "did the tests pass?" It was "who understands how this platform's scheduling model actually differs from the other 31?" If the answer is nobody, an agent wrote it, you didn't save a week. You borrowed it, at interest, from your future self during an incident.

2. Cognitive surrender

Delegation says: do the work, then show me enough evidence that I can judge it. Surrender says: your answer is my answer, before I've formed an opinion of my own.

The Wharton study Osmani cites is the scariest stat in the talk: when the AI was wrong, 73% of people went with the wrong answer anyway, and felt more confident doing it. The failure mode isn't using AI. It's borrowed confidence. I catch myself doing this with agent-written explanations more than agent-written code: the agent tells me why its approach is correct, the reasoning sounds airtight, and I adopt it wholesale without ever generating my own hypothesis to compare it against. That's not review. That's outsourcing the part of my brain that was supposed to be the check.

3. Orchestration tax

Running ten agents in parallel does not create ten of you. Every loop you spin up generates decisions that route back to the same place: your head. Merge this? Re-run that? Is this failure real or flaky? I've had days with five Claude Code sessions open where I produced enormous amounts of code and made zero good decisions, because my attention was sliced too thin to actually judge any of it.

Osmani's fix isn't fewer agents. It's designing your attention like a system. Decide where you enter the loop, what evidence you require at that boundary, and what you refuse to re-litigate. Attention is the resource that doesn't parallelize; budget it like one.

The outer loop is the job

The model took away from the talk

  • agents get the inner loop:
    • investigate
    • implement
    • test
    • report

That's capability, and I'm happy to hand over.

  • The outer loop is still engineering:
    • decide
    • verify
    • approve
    • own

That's agency, and it doesn't delegate.

The boundary between the loops isn't "human glances at AI output." The boundary is evidence. The agent returns diffs, test results, logs, traces, screenshots, whatever the work requires. Then the engineering starts: was this worth doing, is the evidence sufficient, does it ship under my name?

This is also where I'll plug my own obsession: verification has to be cheap, or people skip it. That Sonar gap (96% skeptical, ~50% verifying) exists because review costs attention and attention is the scarce thing. The answer isn't discipline; discipline doesn't scale past Thursday. The answer is building harnesses where verification is structural: tools that validate actions, checks that assert ground truth, loops that are bounded by construction. That's the entire thesis of my Guardrails, Not Prompts series, where I took a deliberately weak model with a frozen prompt and made it reliable purely by making verification part of the harness instead of a virtue the human has to supply. You don't close the trust gap by trying harder. You close it by making the honest path the cheap one.

Your signature outlives your skills

The career framing in the talk is worth stealing. Osmani calls your edge over the models "alpha," and points out every kind of it decays: speed decayed, recall decayed, verification is decaying into harnesses right now, even taste erodes as models train on our preferences. Half-life of a skill edge: roughly one model release.

But the half-life of a signature is much longer: your name on shipped work, the credibility that you understand what you put into production and stood behind it when it broke. That's measured in a career, not a release cycle. Skills earn leverage. Accountability is what converts leverage into trust. When something fails at 2am, nobody asks which model wrote the code. They ask who understood the risk, who accepted it, and who owns the blast radius.

So no, fewer keystrokes doesn't mean less engineering. It means the engineering moved up a level, to the part that was always the hard part: judgment with your name attached.

Build with the agents. I do, aggressively, every day. Let them run the inner loop. But before your cursor hits merge, ask the only question that still belongs entirely to you: can I explain this?

And if you don't understand it, don't fucking ship it.