# Judgment: The Skill AI Can't Give You > Source: > Published: 2026-07-08 00:00:00+00:00 # Judgment: The Skill AI Can't Give You *Shipping fast with AI but don't fully trust the code? I help developers 1:1 turn AI-built apps into something they understand and own. How it works →* Every time I hear the phrase *coding is solved*, I worry about where this industry is heading. Yes, AI writes the code, you review it, ship it, move on. Is there still value in writing the code yourself and going deep into the problem? Yes, and I think it matters more than ever. AI is genuinely transforming how we write software. But the conclusion some people draw from this transformation reveals a dangerous misunderstanding of what makes developers effective. ## The Illusion of Execution Here's what AI actually does well: it generates syntactically correct code, fast. It autocompletes, scaffolds, and produces working implementations of well-defined problems. If you know exactly what you need and can specify it precisely, AI will get you there faster. But that "if" is carrying enormous weight. [Kahneman](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow) calls these System 1 and System 2: fast and intuitive vs. slow and deliberate. The danger is that overusing AI shifts you into System 1 mode: prompt, accept, ship. It feels productive. You're reading code, making micro-decisions, approving changes. But if you never form your own opinion before asking AI, you're not evaluating. You're rubber-stamping. The problem isn't speed. The problem is that the bottleneck has moved. Writing code was never the hard part by itself. Defining the right problem, understanding the domain, making design tradeoffs: that was always the real work. AI doesn't eliminate that work. It just makes it tempting to skip, and hands you false confidence while you do. ## Bad Thinking Scales Faster Now When a developer with shallow understanding uses AI, they produce more shallow code, faster. When a developer who doesn't understand their domain uses AI, they get confident implementations of possibly wrong abstractions. When someone who can't evaluate tradeoffs uses AI, they ship whatever the model suggests. AI solutionism is the same pattern. "Claude will figure it out" isn't a design decision, it's an abdication. You can't prompt your way out of not knowing what you want. ## Modeling Is the Real Bottleneck Eric Evans wrote [Domain-Driven Design](https://en.wikipedia.org/wiki/Domain-driven_design) in 2003, and its core insight has only become more relevant: the hard part of software is understanding the domain deeply enough to model it correctly. Which is why a language model can't do this work for you. It can produce code that compiles and runs. But whether that code captures the right concepts, draws boundaries in the right places, and represents the business accurately? That's context you possess. A practical example: I built a 1,069-line Rust web app with AI before I stopped to ask whether it needed to be a web app at all. It didn't. Asking the right question turned it into a 156-line GitHub workflow ([full article](https://belderbos.dev/blog/design-over-code/)). The code was never the bottleneck. Mapping the problem to the right solution was. Now with AI we produce more code than ever, but how much of that actually matches business problems and makes it to the finish line? I think it's far less than the hype makes us believe, so the net gain is also smaller than we think. On the flipside, the cost of potential skill atrophy is a high price to pay. ## Systems Break After "Working" Software that works today often fails tomorrow, and the reason is usually structural. Systems have feedback loops, delays, and nonlinear behaviors, as Donella Meadows lays out in [Thinking in Systems](https://en.wikipedia.org/wiki/Thinking_In_Systems:_A_Primer). A change that looks correct in isolation can cascade into failure when deployed into a complex environment. The structure of a system determines its behavior more than the quality of any individual component. AI can produce excellent pieces. It cannot compose them into the right whole. Writing more code with AI doesn't build that instinct. Learning to *think in systems* does: asking what happens when this fails, what the second-order effects are, what assumptions you're making about the environment. It requires going deeper on certain features and parts of the code base. Optimizing for how much code you can generate pulls you away from exactly the depth you need now. AI can assist you asking these kinds of questions, but it always starts from your experience. See also: [AI Is an Accelerator, Not a Compass](https://belderbos.dev/blog/ai-accelerator-needs-direction/). ## Simplicity Is a Competitive Advantage John Ousterhout's [A Philosophy of Software Design](https://www.amazon.es/-/en/Philosophy-Software-Design-2nd/dp/173210221X) makes an argument that cuts against the AI zeitgeist: complexity is the root cause of most software problems, and managing complexity requires taste. Taste is the ability to recognize when a solution is more complicated than it needs to be. It's knowing when to stop adding features. It's seeing that a clever abstraction is actually obscuring the problem. It's choosing boring technology over exciting technology because boring works. By itself AI has no taste. It will happily generate elaborate solutions to simple problems. It will add layers of abstraction because that's what the training data contains. It will produce enterprise-grade scaffolding for a script that should be fifty lines. Robert Pirsig, in [Zen and the Art of Motorcycle Maintenance](https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance), a book I am reading again after many years, wrote about Quality as something ineffable but unmistakable. You know it when you see it. Good design has a feeling of rightness that transcends whether it technically works. AI can produce code that works. It cannot produce code that feels right. Again, that judgment is yours. ## Taste Is the New Seniority The developers who adapt best tend to have the widest range of experience, not the narrowest specialization. David Epstein's [Range](https://en.wikipedia.org/wiki/Range:_Why_Generalists_Triumph_in_a_Specialized_World) makes the general case: generalists outperform specialists in complex, unpredictable domains, because breadth creates connections that narrow expertise misses. This maps directly to AI-augmented development. The developers who thrive will be the ones who recognize patterns across domains, who bring experience from different contexts, who ask questions from somewhere outside the model's training data. AI gives you answers. It doesn't tell you what to ask, which tradeoffs matter, or when the answer is wrong despite looking plausible. That's the work that remains human, and I don't see that going anywhere anytime soon. ## Precision Is Communication I left out the skill that most directly defines developers who proficiently use AI: communication, and the ability to exactly express what they want. Somebody put it well in a comment on one of my LinkedIn posts: "Issues with quality happen when there is too much left undecided. So prompt in smaller chunks... with clear, concise and accurate descriptions of what that looks like. Those with linguistic skills go fast, others do not." He's right, and this goes back to judgment. You can only write an accurate description of what good architecture looks like if you already know what good architecture looks like. The vague prompt and the "Claude will figure it out" abdication are the same failure in different clothes, something you haven't decided yet. Precision is needed. This is why the up-front investment keeps paying off, the same reason it always did. The detailed spec, the written-down conventions, the interfaces you define before generating against them: that work encodes your decisions so the model is less likely to guess, and you can tell when it does. It's the same muscle as explaining a tradeoff to a teammate or a non-technical stakeholder, just aimed at a model instead of a person. The right words make you faster. But this all stems from experience and clear thinking. ## How to Use AI Without Degrading Your Thinking None of this means you should use AI less. I use it every day. Sometimes with mixed feelings, because it leads to multi-tasking and increased delegation, but I do get value from it. The key however is to use it **deliberately** and **critically**: - **Form your opinion first.** Before prompting, decide what you think the solution should look like. Then use AI to challenge or extend your thinking. If you can't articulate what you expect, you're not ready to prompt. - **Evaluate, don't rubber-stamp.** When AI produces code, ask: what assumptions is this making? What tradeoffs did it choose? Would I have made the same choices? If you can't answer, you don't understand the code well enough to ship it. - **Stay close to the domain.** The parts of software that AI can't help with are the parts that require understanding context it doesn't have. Spend more time talking to people, understanding the core business domain, and modeling the actual problems. That's where your leverage is. - **Practice without AI.** Spend some time each week writing code without assistance. The skill atrophies if you don't use it. Whether or not coding skill is like riding a bike, the nuance of what makes code effective quickly blurs when you stop writing it. You lose the ability to evaluate what AI produces. You lose the ability to think through problems yourself. - **Stay uncomfortable.** AI makes everything feel productive, it pleases and is overly confident. That can lead you astray. The moments that build judgment are the ones where you struggle, where you're uncertain, where you have to think through it yourself. If everything feels easy, you're probably outsourcing more than execution. It's also counter intuitive, but the more you struggle, the better you'll get. And I've seen time and again that producing software, using AI or not, is inherently hard. ## Don't Outsource Your Judgment "The one thing that's going to be truly future proof is judgment ... In an era when you can do everything, the question is which of these things matter." — Gokul Rajaram AI is not replacing developers. It is opening a gap: those who just want working code, and those who want working code they can stand behind. The latter requires deep learning of concepts, just like in pre-AI times. I think we'll see the hare and the tortoise play out again. AI can make you faster now, but the developers who take the time to understand the problem, think through the tradeoffs, and build judgment will be the ones who produce better software and therefore be faster in the long run. Shipping fast with AI is the easy part. Knowing what to keep, rewrite, and trust is the hard part. I work with developers 1:1 to audit AI-built codebases, trace the real control flow, and make them something you can explain and own, without leaning on a chatbot. [How 1:1 coaching works →](/coaching/#own-project)