AI is great at writing code. It's terrible at making decisions

AI is great at writing code. It's terrible at making decisions. | untangle.work Skip to content ← Back to blog Let me be clear about something upfront: AI is genuinely good at writing code. Not perfect, but genuinely capable. It can produce working implementations faster than any human, in more languages than any individual developer knows. That’s not the problem. The problem is that writing code and making engineering decisions are two completely different activities, and AI only does one of them. Code is the easy part Here’s a thing that experienced engineers know but rarely say out loud: the hard part of software engineering was never typing the code. It was figuring out what to build, how to structure it, and — most importantly — what not to build. Every codebase is the product of thousands of small decisions: Do we use a library for this, or write it ourselves? Should this be one service or two? Is this abstraction worth the complexity it adds? Should we handle this edge case now, or is it premature? What’s the right boundary between these modules? These decisions aren’t about syntax or algorithms. They’re about trade-offs, context, and judgment. They require understanding not just what the code does today, but what it’ll need to do in six months. AI doesn’t make these decisions. It just generates whatever you ask for. And that distinction has consequences that compound over time. Prompts are not architecture When you build with AI, the architecture of your codebase is shaped by the sequence of prompts you gave. Not by deliberate design. Not by a clear understanding of domain boundaries. Just by the order you happened to think of things. Monday you asked for user authentication. Tuesday you asked for a settings page. Wednesday you asked for an API integration. Each prompt produced working code. But nobody asked: “How should these three things relate to each other? What are the boundaries? What data do they share and how?” The AI didn’t ask either. It just built three things, each internally coherent, with no shared understanding between them. Six months later, someone needs to change how user sessions work and discovers that the auth system, the settings page, and the API integration all handle sessions differently. Not because anyone decided to do it that way. Because nobody decided at all. The decision vacuum This is what we see in every AI-generated codebase we audit: not bad code, but a vacuum of decision-making. No architectural decision records. No explanation for why one pattern was used over another. No consistency in how similar problems are solved. Just a series of working implementations, each produced in isolation, glued together by whatever the AI suggested at the time. The code compiles. The tests pass (if they exist). The product works. But the codebase doesn’t reflect any engineering philosophy. There’s no “we do it this way because…” — there’s only “the AI generated it this way.” This matters because software lives longer than the prompts that created it. The codebase needs to be maintained by people who weren’t there when the prompts were written. If those people can’t understand why the code is structured a certain way, they can’t safely change it. You don’t notice until you do The insidious thing about decision-free code is that it works fine initially. AI produces code that runs. Users don’t care about your architecture. Revenue doesn’t depend on clean abstractions. But the cost compounds quietly: Each new feature takes a little longer because there’s more to work around Each bug is a little harder to find because the codebase doesn’t have a consistent model Each new team member takes a little longer to onboard because there’s nothing coherent to learn Each refactor is a little scarier because nobody knows the blast radius And then one day, the compound interest comes due. Someone needs to make a significant change, and they realize the codebase has no center of gravity. There’s no clear architecture to extend, only ad-hoc patterns to navigate. What this means in practice We’re not arguing against using AI. We use it too. It’s a tool, and a powerful one. But using AI without engineering judgment is like using a CNC machine without a blueprint. You’ll produce parts — lots of them, fast. But whether those parts fit together into something coherent depends on decisions the machine can’t make. If you’re building with AI, someone still needs to be the architect. Someone needs to make the decisions that the AI can’t: What’s the module structure? What patterns do we follow consistently? Where do we draw boundaries between concerns? What do we deliberately choose not to build? How do we ensure new code matches existing conventions? These don’t have to be massive upfront decisions. They can be lightweight. But they have to exist. A codebase without decisions is just a pile of files that happens to run. The uncomfortable truth Here’s what nobody in the “AI will replace developers” conversation wants to hear: AI made the writing part of code cheaper, but it made the thinking part more valuable. When code is cheap to produce, the bottleneck shifts to judgment. What to build, how to structure it, when to refactor, what to throw away — these are the decisions that determine whether your codebase is an asset or a liability two years from now. AI can’t make those calls. It’s not a judgment problem it can be trained out of. It’s a fundamental characteristic of the tool: it generates what you ask for. The asking is the engineering. If your codebase was built without enough asking, we can help sort it out . That’s literally all we do.