One question every thirty seconds. That is the rate at which Sean Goedecke, a software engineer writing on his personal site this week, says he interrupts people who are explaining things to him. He grants that some of them find it frustrating. He recommends the habit anyway — and lately, he argues, it has become close to a professional necessity, because some of the explainers are machines.
Most of the questions are short and want short answers: requests for confirmation, along the lines of “so when you say X, you mean Y?” They exist because misunderstanding compounds. A small error absorbed early bends everything built on top of it, and those bent pieces generate misunderstandings of their own, and so on. Which is why, he writes, you cannot wait politely until the speaker finishes and ask everything at once.
He thinks most people skip the questions because they are not really trying to understand — they are content to trust that the person talking knows what is going on, and twice as content when that person is a well-respected or senior engineer. Skin in the game changes that. Once you are the one responsible for success or failure, the one who will leave the room and take the concrete actions, you find the questions arriving on their own.
The build in the head
When a plan is described to him at work, Goedecke writes, he constructs it in his head — visualizing the specific lines of code that an implementation would require. Details of solved problems get handwaved, but at minimum he is mapping how data flows between services and over the wire, how the services will authenticate to each other, and what data must be persisted and where it will live.
Vagueness is the tripwire. A service described as “storing data” when he knows it only talks to an ephemeral Redis store earns an immediate “hold on, how is that going to work?” That question usually exposes a missing dependency — service X must call service Y, which actually has a database — and a missing dependency, he notes, tends to suggest design changes.
Sometimes it exposes something worse. Years ago, he recalls, a neighboring team built a complex event-driven system of real elegance that made it completely impossible to silo customer data in a single datacenter — at a company whose flagship feature was that all your data lives in a single location. The system did not work and had to be effectively abandoned. Doing this interrogation in the meeting, rather than after weeks of implementation, he argues, can be enough to turn a failed project into a successful one.
An always-new colleague
Maybe you work only with reliable engineers who can be trusted to make the right decisions, he writes. But these days you probably also have colleagues who are inherently unreliable: AI agents. Goedecke works mostly with GPT-6-Astra and Claude Opus 5.5. These models rarely make code mistakes; they make design mistakes “all the time” — assuming two services can talk to each other when they can’t, forgetting that code must run both in the cloud and on-premises. The cause, he argues, is the lack of continuous learning: you didn’t know these things on your first day either, but you had time to pick them up. “Language models are always on their first day.”
So he peppers them. Do we do X elsewhere in this codebase? Does service Y really support this type of authentication, or are you assuming we’d have to go build that too? Is this subsystem necessary to satisfy requirement Z, or does it satisfy some requirement you assumed? Why does this file need to change at all?
He concedes some of those read like leading questions that might invite sycophancy, but says that in his experience good coding models are very happy to “robustly defend themselves.” And about half of the questions he asks, he estimates, end in an answer that convinces him the model got something wrong — a subsystem it should have reused, an authentication it should have done differently, an implementation it should have kept simple.
His conclusion is blunt: nobody understands complex software products, and anyone with deep domain knowledge of any corner of a codebase “will routinely find yourself correcting powerful AI models and principal engineers.” When the day comes that every answer convinces him, he writes, he will stop asking questions. Today is not that day. The thirty-second metronome runs on.