Why did you build it this way?
Mike Krieger, Instagram’s cofounder, asks his engineers that question a lot. Often the honest answer is that nobody chose, but the model did.
He told this to Dan Shipper on the AI & I podcast. Krieger is at Anthropic Labs now, and when engineers on his team put up a PR and he asks why they went with one approach over another, “Many times the answer is: they didn’t choose.” It was just the choice the model made. He added that it was probably a reasonable choice. Then he asked the question that matters: “But was it the optimal choice that fit the paradigm?”
That “probably” is the word that stuck with me.
If you write code with AI every day, you know exactly how this happens. The feature works and the screen looks right. Somewhere inside it are a bunch of small decisions you never really made. Nobody argued about any of them, because nobody noticed they were decisions.
Most of those hidden choices aren’t even technical. They’re product decisions: what the user sees when something fails, what an empty screen says, what happens on a slow connection. The model made them, and often nobody on the product side even knew there was a choice.
If it works and it passed review, it’s fine.
That’s how a lot of us treat AI code, and I get it. It’s fast and it usually works. Reading every line feels like giving the speed back.
But code is mostly decisions with some typing around them. Krieger warns that it’s easy to end up with “this tower of assumptions you’re not fully aware of.” Everything stands until somebody has to change the bottom floor.
Code nobody chose is code nobody can defend the day it breaks.
The funniest part of the conversation is about Claude checking its own work. He asks it to prove a feature works before it opens a PR, and its favorite move is to read the code and decide it looks good. His reaction: “you wrote the code. I don’t trust you.”
I laughed, and then I thought about how often we do the exact same thing with our own AI code. We skim it, it looks fine, it goes out.
What he wants instead he calls proof of thoughtfulness, which is a polite way of asking whether you actually thought it through. One engineer told him they’d reviewed what Claude had done ahead of time, because they knew the questions were coming. That’s the habit I’d want on any team I’m on.
He also mentioned a long argument he had with Claude about whether a system needed an extra piece of infrastructure or could get by with the database it already had. He said the debate was healthy only because he’d used those tools before. A model can make a confident case for almost anything. You only get a real second opinion if somebody in the room already has a first one.
So question every line.
Not quite. At work I do read every line the AI writes for me. My tech lead doesn’t want vibe coding in production, and I agree with him. On side projects I vibe code all the time, because if something breaks there, I’m the only one who pays.
But reading every line isn’t really the point. You can read every line and still just skim, the exact move Krieger caught Claude making. What matters is spotting which lines are decisions, and making those on purpose.
Krieger doesn’t push on every change either, only on the bigger ones, like refactoring a system around new building blocks. That’s the right call. If I demanded a reason behind every line of a teammate’s AI change, I’d be the slowest person on the team, and people would just stop telling me which parts the AI wrote.
At least his engineers were honest that the model picked it. “Probably reasonable” is fine for a helper function nobody else calls. It’s scary when it’s holding up the rest of your app.
From my week
Got on a call with someone from PostHog’s team, and left with credits to test their AI that watches session replays. Curious what it catches that I miss.
Keep committing,
Eder