Code is Cheap Now, Software Isn't
LLMs have effectively killed the cost of generating lines of code, but they haven’t touched the cost of truly understanding a problem. We’re seeing a flood of "apps built in a weekend," but most of these are just thin wrappers around basic CRUD operations and third-party APIs. They look impressive in a Twitter demo, but they often crumble the moment they hit the friction of the real world.
The real cost of software isn’t the initial write; it’s the maintenance, the edge cases, the mounting UX debt, and the complexities of data ownership. These "fast" solutions are brittle.
Building a quick prototype or proof of concept might be great to start out, but mature, production-level applications are going to be in use for a significant period of time, all the while being enhanced, having bugs fixed, and conflicts about how certain features should work. Being able to look at the different use cases from users to create the best paths is so utterly critical...and time consuming.
Lately, I’ve seen plenty of doomsaying on Hacker News, Reddit, and Twitter about "the end of software engineering." This misses the point entirely. We aren't witnessing the end of the profession; we’re entering a new era of it.
The value of an engineer is shifting away from the "how" of syntax and toward the "what" and "why" of systems. Real engineering lies in the abstractions and the architecture. It’s about knowing how to structure a system that lasts, understanding why a specific rate-limiting strategy is necessary, knowing how to manage a distributed cache, and knowing exactly where not to store your environment variables.
AI often feels powerful because it hides the complexity, but as an engineer, your job is to manage that complexity, not ignore it. The tools have changed, but the fundamental requirement for engineering rigour has never been higher.
Just wait until you start trying to decide how to lay out your project...
While AI is undeniably good at writing code, it remains poor at architecting maintainable, distributable, and scalable systems. This is where non-technical leaders who think they can fire their development teams are making a significant mistake. Until we see the arrival of an artificial intelligence that renders this entire discussion moot, believing that technical expertise can be replaced by a prompt is a strategic error. Building robust software still requires a human who understands the underlying principles of the craft.
The bottom line is that while the tools have changed, the fundamentals of good engineering have not.