{"slug": "we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build", "title": "We Solved the How to Code Problem. We Still Haven't Solved \"What to Build.\"", "summary": "A developer argues that AI coding tools have largely solved the \"how to build\" problem while leaving the harder question of \"what to build\" unanswered. The engineer recounts spending a weekend using AI to ship a working prototype that nobody, including the author, actually needed, illustrating how removing implementation friction also removes the natural filter that once killed bad ideas. The piece concludes that as implementation gets cheaper, judgment, problem framing, and the willingness to say no become the more valuable skills.", "body_md": "We spent years trying to make coding easier. Better editors. Better frameworks. Better libraries. Better documentation.\n\nAnd now AI can write a surprising amount of the code for us.\n\nSo we finally solved the problem.\n\nRight?\n\nNot exactly.\n\nWe solved *\"How do I build this?\"*\n\nWe still haven't solved the harder question: **\"What should I build?\"**\n\nAnd when building becomes cheap, building the wrong thing becomes cheap too.\n\nEvery generation of developer tools has chased the same goal.\n\nStack Overflow. GitHub. Package managers. Frameworks. IDEs. Autocomplete. Copilot. Now AI.\n\nThe goal was always the same: reduce the distance between an idea and working software.\n\nAnd honestly, it worked.\n\n\"I need a dashboard.\"\n\nAI: \"Sure.\"\n\n\"I need authentication.\"\n\nAI: \"Sure.\"\n\n\"I need an API.\"\n\nAI: \"Sure.\"\n\n\"I need tests.\"\n\nAI: \"Sure.\"\n\nA few years ago, some of these things would have taken hours or days. Now you can get a working prototype surprisingly quickly.\n\nAnd that's where things get interesting.\n\nHere's the contradiction at the center of all this.\n\nEarlier: bad idea → expensive implementation → natural friction. The cost of building was itself a filter. Most bad ideas quietly died before anyone finished them.\n\nNow: bad idea → AI → working prototype. The friction is gone.\n\n**AI didn't just lower the cost of building good software. It lowered the cost of building unnecessary software.**\n\nThis is where it gets personal, because I've fallen for this exact trap.\n\nYou 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.\n\nAsk AI for the initial architecture. Generate the UI. Wire up the API. Fix a few errors along the way.\n\nBy Sunday, it works.\n\nAnd that's when you realize you never actually answered the most important question.\n\n**Who actually needs this?**\n\nI 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.\n\nThe weird part wasn't that I finished it.\n\nThe weird part was realizing I'd spent hours answering \"How?\" without spending ten minutes on \"Why?\"\n\nThe prototype worked perfectly. Nobody, including me, actually needed it.\n\nHow do I build authentication? How do I cache this? How do I create this API? How do I deploy this?\n\nAI can help enormously with all of it.\n\nBut \"Should we build authentication for this?\" and \"Do users actually need this feature?\" are different questions entirely.\n\nAI can accelerate implementation. It doesn't automatically provide judgment.\n\nDevelopers say it all the time: \"It'll only take a few hours.\"\n\nBut 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.\n\n**The cost of writing the first version is no longer the whole cost of the software.**\n\nA 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.\n\n**Finished doesn't mean valuable. Working doesn't mean worth maintaining.**\n\nThe question used to be: *can you build it?*\n\nIncreasingly, the question is: *can you decide whether it deserves to be built?*\n\nThe valuable skills are shifting problem framing, asking better questions, understanding users, identifying real constraints, knowing when to stop, saying no.\n\n**When implementation becomes cheaper, judgment becomes more valuable.**\n\nQuite the opposite.\n\nAI 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.\n\nThe problem isn't building faster.\n\n**The problem is confusing faster building with better decisions.**\n\n**1. What problem does this actually solve?**\n\nNot \"what does this feature do\" but what problem disappears because this exists?\n\n**2. Who actually has this problem?**\n\nIf the honest answer is \"developers, probably\" that's worth investigating further before writing a line of code.\n\n**3. What happens if we don't build it?**\n\nIf the answer is \"nothing,\" that's your answer.\n\n**4. What's the simplest version that proves the idea?**\n\nDon't build the whole product. Build enough to learn something.\n\n**5. Would I still build this if AI didn't make it easy?**\n\nThis is the signature question. AI can make bad ideas feel irresistibly cheap this question cuts through that.\n\nProductivity used to mean more code in less time. More commits, more features, faster implementation.\n\nBut AI can help almost anyone produce more code now. That definition doesn't hold up anymore.\n\n**Productivity isn't how much code you produce. It's how much unnecessary code you avoid producing.**\n\nWriting code used to be expensive. It's becoming cheap.\n\nGood decisions are still expensive which problem, which user, which architecture, which trade-off, which things to deliberately ignore.\n\nThe bottleneck is slowly moving from implementation to judgment.\n\nMaybe 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.\"\n\nThat's not doing less engineering.\n\nThat's doing more thinking before engineering.\n\nAI is making it easier than ever to turn ideas into software. That's incredible.\n\nBut it creates a new problem. When almost anything can be built, the hard part becomes deciding what deserves to exist.\n\nWe solved the \"How to code\" problem.\n\nMaybe we haven't solved the more important one yet: **what should we build?**\n\nAnd I'm starting to think that's where the real engineering begins.\n\n**What's something you built that you later realized didn't need to exist?** 😅\n\nAnd if you could go back what would you have asked yourself before writing the first line of code?", "url": "https://wpnews.pro/news/we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build", "canonical_source": "https://dev.to/harsh2644/we-solved-the-how-to-code-problem-we-still-havent-solved-what-to-build-5e3g", "published_at": "2026-09-22 13:15:03+00:00", "updated_at": "2026-09-22 13:23:32.448676+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products", "artificial-intelligence"], "entities": ["GitHub", "Stack Overflow", "Copilot"], "alternates": {"html": "https://wpnews.pro/news/we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build", "markdown": "https://wpnews.pro/news/we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build.md", "text": "https://wpnews.pro/news/we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build.txt", "jsonld": "https://wpnews.pro/news/we-solved-the-how-to-code-problem-we-still-haven-t-solved-what-to-build.jsonld"}}