# We Solved the How to Code Problem. We Still Haven't Solved "What to Build." > Source: > Published: 2026-09-22 13:15:03+00:00 We spent years trying to make coding easier. Better editors. Better frameworks. Better libraries. Better documentation. And now AI can write a surprising amount of the code for us. So we finally solved the problem. Right? Not exactly. We solved *"How do I build this?"* We still haven't solved the harder question: **"What should I build?"** And when building becomes cheap, building the wrong thing becomes cheap too. Every generation of developer tools has chased the same goal. Stack Overflow. GitHub. Package managers. Frameworks. IDEs. Autocomplete. Copilot. Now AI. The goal was always the same: reduce the distance between an idea and working software. And honestly, it worked. "I need a dashboard." AI: "Sure." "I need authentication." AI: "Sure." "I need an API." AI: "Sure." "I need tests." AI: "Sure." A few years ago, some of these things would have taken hours or days. Now you can get a working prototype surprisingly quickly. And that's where things get interesting. Here's the contradiction at the center of all this. Earlier: bad idea → expensive implementation → natural friction. The cost of building was itself a filter. Most bad ideas quietly died before anyone finished them. Now: bad idea → AI → working prototype. The friction is gone. **AI didn't just lower the cost of building good software. It lowered the cost of building unnecessary software.** This is where it gets personal, because I've fallen for this exact trap. You get an idea on a Friday. It sounds useful. You can already picture how it would work. AI makes the implementation feel almost effortless, so you start building. Ask AI for the initial architecture. Generate the UI. Wire up the API. Fix a few errors along the way. By Sunday, it works. And that's when you realize you never actually answered the most important question. **Who actually needs this?** I had an idea. It sounded useful. I could imagine exactly how it would work. AI made the implementation feel almost effortless, so I just... started. The weird part wasn't that I finished it. The weird part was realizing I'd spent hours answering "How?" without spending ten minutes on "Why?" The prototype worked perfectly. Nobody, including me, actually needed it. How do I build authentication? How do I cache this? How do I create this API? How do I deploy this? AI can help enormously with all of it. But "Should we build authentication for this?" and "Do users actually need this feature?" are different questions entirely. AI can accelerate implementation. It doesn't automatically provide judgment. Developers say it all the time: "It'll only take a few hours." But a few hours to build can become months of maintenance — bugs, dependencies, security, documentation, support, future feature requests, technical debt that someone has to carry. **The cost of writing the first version is no longer the whole cost of the software.** A feature that ships but nobody opens. A dashboard nobody checks. An abstraction nobody needed. A microservice that could have stayed a function. An AI-generated automation replacing a manual process that took thirty seconds anyway. **Finished doesn't mean valuable. Working doesn't mean worth maintaining.** The question used to be: *can you build it?* Increasingly, the question is: *can you decide whether it deserves to be built?* The valuable skills are shifting problem framing, asking better questions, understanding users, identifying real constraints, knowing when to stop, saying no. **When implementation becomes cheaper, judgment becomes more valuable.** Quite the opposite. AI is fantastic for prototypes, boilerplate, experiments, repetitive code, tests, documentation, and exploring unfamiliar APIs. It turns an idea into something tangible faster than anything we've had before. The problem isn't building faster. **The problem is confusing faster building with better decisions.** **1. What problem does this actually solve?** Not "what does this feature do" but what problem disappears because this exists? **2. Who actually has this problem?** If the honest answer is "developers, probably" that's worth investigating further before writing a line of code. **3. What happens if we don't build it?** If the answer is "nothing," that's your answer. **4. What's the simplest version that proves the idea?** Don't build the whole product. Build enough to learn something. **5. Would I still build this if AI didn't make it easy?** This is the signature question. AI can make bad ideas feel irresistibly cheap this question cuts through that. Productivity used to mean more code in less time. More commits, more features, faster implementation. But AI can help almost anyone produce more code now. That definition doesn't hold up anymore. **Productivity isn't how much code you produce. It's how much unnecessary code you avoid producing.** Writing code used to be expensive. It's becoming cheap. Good decisions are still expensive which problem, which user, which architecture, which trade-off, which things to deliberately ignore. The bottleneck is slowly moving from implementation to judgment. Maybe they'll be the ones who know what *not* to build the ones who can look at an impressive AI-generated prototype and say, "This is impressive. But we don't need it." That's not doing less engineering. That's doing more thinking before engineering. AI is making it easier than ever to turn ideas into software. That's incredible. But it creates a new problem. When almost anything can be built, the hard part becomes deciding what deserves to exist. We solved the "How to code" problem. Maybe we haven't solved the more important one yet: **what should we build?** And I'm starting to think that's where the real engineering begins. **What's something you built that you later realized didn't need to exist?** 😅 And if you could go back what would you have asked yourself before writing the first line of code?