--- title: "Overengineering Is Doubt Compiled" author: "Marc DeCaria" url: "https://marcdecaria.com/writing/overengineering-is-doubt-compiled" date: "2026-11-04" topics: ["AI & Technology"] words: 1033 summary: "Argues that vague warnings in a prompt work like fog that leads AI to build defensive layers nobody needs, and that clear decisions, named open questions and judgment during the build keep code lean." --- # Overengineering Is Doubt Compiled *By Marc DeCaria, November 4, 2026* ![](https://pbs.twimg.com/media/HWUoC17X0AAMaqu?format=jpg&name=orig) ## Overengineering Is Doubt Compiled Why your AI builds railings in the fog When you build with AI, it can’t see what’s in your head. All it gets is your words, whether you type them or say them out loud. But your words say more than you think. When you’re clear on what you want, you describe the thing itself. The AI has far less to guess about, so it builds close to what you meant, and fast. When you’re unsure, it shows. You start giving warnings instead of descriptions. Be careful. Don’t overengineer. Make sure you test everything. None of that tells the AI what to build. It only tells it something might go wrong. So it plays it safe. Sometimes a warning comes from experience, not doubt. You’ve watched an AI take a simple job and run with it, so you tell it not to overengineer. That’s fair, but the warning still doesn’t say where the line is. Experience does its best work as a specific boundary. “No recovery system in this version” says what the warning only hints at. Code can’t be unsure. Every line has to decide something. Any question you leave open, the AI answers for you, and it answers cautiously. It adds a fallback here, an extra setting there, a check for a case you never mentioned. Models already lean this way on their own. In a clear room that lean barely shows. In a foggy one it takes over. So piling on warnings won’t fix overengineering. Real requirements still belong in the prompt. “Never store card numbers” and “customer data never leaves this server” are decisions, not doubt. What doesn’t belong there is vague worry. Don’t give the AI your uncertainty and ask it to compensate. Give it your decisions, your boundaries, and your definition of done. That doesn’t mean pretending you’re sure. If something isn’t decided yet, say so plainly. “Refunds aren’t decided yet, leave them out” is clear. An open question you name becomes a boundary. It’s the doubt you don’t name that turns into fog. Real protections belong in the code where they do real work, like payment validation, permission checks, and data integrity. The rest of your caution goes into your process, with staging, testing, and approvals. All of this is happening whether you know it or not. You don’t have to believe in the fog for it to fill the room, and you don’t have to notice it for it to end up in your code. This piece doesn’t create any of it. It just describes it, so you can see it while it’s happening instead of finding the railings afterward. Here’s the picture to hold in your mind while you work. It isn’t how the AI works inside. Nobody fully knows what that looks like. A picture like this is a handle, not a mechanism, so judge it by whether it helps you see what’s happening in your own sessions, not by whether there’s really a room. If you catch yourself asking what the fog is made of, you’re looking at the picture instead of through it. When you start a session, picture the two of you stepping into a room together. The AI builds inside that room, and you’re the one who sets the light. When you’re focused and you know what you want, the room is bright. The AI can see the walls, the floor, and exactly where the thing goes. It walks straight to it and builds it. When doubt comes in, picture fog filling the room. You might not say the doubt out loud, and you might not even notice you have it, but it still fills the room through how you talk. Now the AI can’t see where the walls are. It doesn’t know the fog came from you. It isn’t standing outside the room deciding whether the fog is real. It’s inside, building, and all it knows is that it can’t see. So it does what anyone would do in a fog. It moves carefully and builds railings everywhere, plus extra supports and barriers in case there’s a drop it can’t see. When you look at the code later, those railings are what you’ll find. The extra layers, the fallbacks nobody asked for, the settings for situations that will never happen. That’s the shape the fog left behind. And it won’t look like a mistake. Railings look like careful engineering, which is why they get past review and stay. But not all the fog comes from you. The AI carries its own doubt into the room. It has learned that careful engineering means planning for every failure, so it adds protections even when the room is bright. Hand that code to another AI for review and it walks the room looking for drops, and it finds more places to put railings. Every new railing is more code, and more code is more places for something to go wrong. Before long the railings need railings. A payment module that only had to charge a card can grow a whole recovery system, and the review of that system turns up thirty new problems. You can describe the room perfectly and still end up there. That’s why clarity isn’t the whole job. You also have to hold the line once the building starts. When the AI proposes another layer, ask one question. Can this actually happen in my system, or are we building around something hypothetical? Good engineering isn’t the absence of railings. It’s knowing where the real drops are. A payment that runs unattended overnight needs protections that a customer standing at checkout doesn’t. Some railings belong. The ones guarding drops that don’t exist are the ones to take out. And sometimes the right call is to walk out of the room and go back to the simpler build that already works. So before you build, clear the room. Say what the thing is, where its boundaries are, and what done looks like. Then keep it clear while you build. Clarity sets the boundaries, and judgment keeps you and the AI inside them. A clear room gets you clean code, and a foggy room gets you railings.