{"slug": "i-think-developers-are-building-too-much-software", "title": "I Think Developers Are Building Too Much Software", "summary": "A developer argues that modern software development has become too easy to start, leading teams to build unnecessary complexity, and that AI coding assistants have worsened the problem by removing the friction that once forced engineers to ask whether a feature was worth building. The developer contends that unnecessary architecture is a form of technical debt that is hard to recognize and that removing components is often the better engineering decision.", "body_md": "There was a time when the difficult part of building software was writing the software.\n\nToday, that is increasingly not true.\n\nWe have better frameworks, better libraries, better APIs, better cloud infrastructure, better developer tools, and now AI can generate a significant amount of the code for us.\n\nYet I keep seeing the same pattern:\n\nWe are getting better at building things, but not necessarily better at deciding what should be built.\n\nAnd I think that is becoming one of the biggest engineering problems of our time.\n\n**Software Has Become Too Easy to Start**\n\nThink about what it takes to build an application today.\n\nYou can generate a frontend in minutes.\n\nConnect an API.\n\nAdd authentication.\n\nAdd a database.\n\nDeploy it.\n\nAdd an AI model.\n\nGive the model access to tools.\n\nAdd an agent.\n\nAdd another service.\n\nAdd monitoring.\n\nAdd a queue.\n\nAdd a vector database.\n\nAdd an orchestration framework.\n\nBefore long, you have a surprisingly sophisticated architecture.\n\nAnd sometimes you have solved a problem that didn't actually require any of it.\n\nThis is the paradox of modern software development:\n\nThe cheaper it becomes to build software, the easier it becomes to build unnecessary software.\n\n**AI Made This Problem Bigger**\n\nAI has changed the equation even further.\n\nPreviously, I might have spent several hours implementing a feature.\n\nToday, I can describe the feature and have an AI coding assistant generate much of the implementation.\n\nThat is incredibly useful.\n\nBut it also removes an important friction.\n\nWhen building something required significant effort, effort itself acted as a filter.\n\nYou naturally asked:\n\n\"Is this worth building?\"\n\nWhen implementation becomes cheap, that question becomes easier to ignore.\n\nYou can simply build it.\n\nAnd then build another version.\n\nAnd then add another feature.\n\nAnd then add an agent because the agent framework looks interesting.\n\nThe cost of implementation falls.\n\nBut the cost of complexity does not disappear.\n\n**Every Feature Creates a Future Problem**\n\nA feature rarely costs only what it takes to build it.\n\nIt also creates:\n\nThis is why a 30-minute feature can sometimes create a six-month maintenance problem.\n\nThe original implementation was cheap.\n\nThe system became expensive.\n\nThis is particularly dangerous with AI-generated code because the initial implementation can feel almost free.\n\nYou ask for a feature.\n\nThe code appears.\n\nIt works.\n\nYou move on.\n\nSix months later, someone has to understand why seventeen components depend on it.\n\n**Complexity Is a Technical Debt You Can See Too Late**\n\nDevelopers are generally good at recognizing obvious technical debt.\n\nPoor naming.\n\nDuplicated code.\n\nMissing tests.\n\nOutdated dependencies.\n\nLarge functions.\n\nBut there is another type of technical debt that is harder to recognize:\n\nunnecessary architecture.\n\nYou can have beautifully written code inside an unnecessarily complicated system.\n\nYou can have excellent abstractions that nobody needed.\n\nYou can have perfectly implemented microservices where a single application would have been enough.\n\nYou can have an impressive AI agent where a deterministic workflow would have been safer.\n\nThe individual components can all be technically correct.\n\nThe overall system can still be wrong.\n\n**I Am Increasingly Suspicious of \"More\"**\n\nMore services.\n\nMore abstractions.\n\nMore tools.\n\nMore frameworks.\n\nMore automation.\n\nMore agents.\n\nMore integrations.\n\nMore dashboards.\n\nMore features.\n\nMore AI.\n\nNone of these things are inherently bad.\n\nThe problem starts when more becomes the default definition of progress.\n\nSometimes the best engineering decision is to remove something.\n\nRemove a dependency.\n\nRemove an abstraction.\n\nRemove a service.\n\nRemove an AI step.\n\nRemove a feature.\n\nRemove an entire workflow.\n\nThat can be harder than adding something.\n\nBecause adding demonstrates activity.\n\nRemoving requires judgment.\n\n**The Best Architecture Might Look Boring**\n\nThere is something I have increasingly come to appreciate about good systems:\n\nThey can look surprisingly boring.\n\nImagine two solutions.\n\nSystem A\n\nUser → API → Database → Response\n\nSystem B\n\nUser → Gateway → Service A → Queue → Service B → Agent → Tool Router → Vector DB → External API → Validation Service → Event Bus → Service C → Database → Response\n\nSystem B looks more sophisticated.\n\nBut sophistication isn't the same thing as quality.\n\nIf both systems solve the same problem reliably, System A may be dramatically better.\n\nNot because it uses newer technology.\n\nBecause it has fewer things that can break.\n\nThis is why I increasingly believe that simplicity is not the absence of engineering.\n\nIt is the result of engineering judgment.\n\n**This Is Where AI Agents Fit Into the Conversation**\n\nThis is also why I have become cautious about the current obsession with AI agents.\n\nAgents are useful.\n\nThere are problems where dynamic decision-making, tool selection, iteration, and autonomy genuinely create value.\n\nBut if a deterministic workflow can solve the problem, an agent may simply introduce additional uncertainty.\n\nThe question shouldn't be:\n\n\"Can I turn this into an agent?\"\n\nThe better question is:\n\n\"Does this problem actually require autonomous decision-making?\"\n\nThat distinction matters.\n\nI wrote about this in more detail in my article “Stop Building AI Agents. Start Building AI Systems.”\n\nThe broader principle is the same:\n\nDon't optimize for technological sophistication. Optimize for the outcome.\n\n**We Need a New Engineering Question**\n\nFor a long time, developers were encouraged to ask:\n\n\"How do I build this?\"\n\nThen we learned to ask:\n\n\"How do I build this well?\"\n\nI think there is another question we need to put before both:\n\n\"Should this exist at all?\"\n\nThat question applies to much more than software.\n\nShould this feature exist?\n\nShould this service exist?\n\nShould this automation exist?\n\nShould this database exist?\n\nShould this AI component exist?\n\nShould this entire application exist?\n\nSometimes the answer will be yes.\n\nBut sometimes the answer will be:\n\nNo.\n\nAnd that's not failure.\n\nThat's engineering.\n\n**AI Makes Judgment More Valuable, Not Less**\n\nThis is perhaps the most interesting consequence of AI-assisted development.\n\nIf AI continues making implementation faster, then implementation itself becomes less differentiated.\n\nThe valuable skills move upward.\n\nUnderstanding the problem.\n\nDefining the right requirements.\n\nChoosing the right architecture.\n\nRecognizing unnecessary complexity.\n\nKnowing when not to automate.\n\nKnowing when not to use AI.\n\nUnderstanding trade-offs.\n\nEvaluating whether something actually works.\n\nAnd, perhaps most importantly:\n\nknowing what not to build.\n\nAI can generate ten possible implementations before you've finished explaining the problem.\n\nThat makes judgment more important, not less.\n\n**Before You Build the Next Thing**\n\nI've started thinking about software decisions through a much simpler filter.\n\nBefore building something, ask:\n\nIf you cannot explain the problem clearly, stop.\n\n\"Someone might use this\" is not a strong enough answer.\n\nNot the most impressive.\n\nThe simplest.\n\nThink beyond today's implementation.\n\nMaybe a manual process is perfectly acceptable.\n\nMaybe a rule, query, function, or conventional application is better.\n\nThis is the question I think we ask far too rarely.\n\nSometimes nothing happens.\n\nAnd that may be the best outcome.\n\n**The Builder's Paradox**\n\nWe are entering an unusual period in software development.\n\nBuilding is becoming incredibly easy.\n\nBut deciding what deserves to be built may become increasingly difficult.\n\nThat creates a strange paradox:\n\nThe better our tools become, the more important restraint becomes.\n\nWhen writing code was expensive, we naturally avoided unnecessary code.\n\nWhen infrastructure was difficult, we naturally avoided unnecessary infrastructure.\n\nWhen software development becomes increasingly assisted by AI, we will need a different constraint.\n\nJudgment.\n\nNot everything that can be built deserves to exist.\n\nNot every workflow needs automation.\n\nNot every application needs AI.\n\nNot every AI application needs an agent.\n\nAnd not every technical problem needs a technical solution.\n\nMaybe the next great developer skill isn't building faster.\n\nMaybe it's learning to look at a problem and confidently say:\n\n\"We don't need to build this.\"\n\nWhat do you think?\n\nAre developers becoming better at building software or simply better at building more of it?\n\nNote: Looking for deeper insights into the future of artificial intelligence? Head over to ReThynk AI to access our latest research, magazine articles, and developer resources. [Click Here](https://rethynkai.com/)", "url": "https://wpnews.pro/news/i-think-developers-are-building-too-much-software", "canonical_source": "https://dev.to/jaideepparashar/i-think-developers-are-building-too-much-software-1l1i", "published_at": "2026-09-11 03:36:19+00:00", "updated_at": "2026-09-11 03:56:32.904794+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-agents", "artificial-intelligence"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/i-think-developers-are-building-too-much-software", "markdown": "https://wpnews.pro/news/i-think-developers-are-building-too-much-software.md", "text": "https://wpnews.pro/news/i-think-developers-are-building-too-much-software.txt", "jsonld": "https://wpnews.pro/news/i-think-developers-are-building-too-much-software.jsonld"}}