There was a time when the difficult part of building software was writing the software.
We 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.
We are getting better at building things, but not necessarily better at deciding what should be built.
And I think that is becoming one of the biggest engineering problems of our time.
The cheaper it becomes to build software, the easier it becomes to build unnecessary software.
Today, I can describe the feature and have an AI coding assistant generate much of the implementation.
When building something required significant effort, effort itself acted as a filter.
It also creates: code to maintain bugs to investigate dependencies to update documentation to maintain edge cases to handle users to support security concerns performance considerations monitoring requirements decisions future developers need to understand
This is why a 30-minute feature can sometimes create a six-month maintenance problem.
This is particularly dangerous with AI-generated code because the initial implementation can feel almost free.
Six months later, someone has to understand why seventeen components depend on it.
You can have beautifully written code inside an unnecessarily complicated system.
You can have perfectly implemented microservices where a single application would have been enough.
You can have an impressive AI agent where a deterministic workflow would have been safer.
User → Gateway → Service A → Queue → Service B → Agent → Tool Router → Vector DB → External API → Validation Service → Event Bus → Service C → Database → Response
If both systems solve the same problem reliably, System A may be dramatically better.
This is why I increasingly believe that simplicity is not the absence of engineering.
This is also why I have become cautious about the current obsession with AI agents.