As a follow up to AI will NOT replace Software Engineers where I argued that AI handles the mundane so engineers can focus on the meaningful, I want to take that idea further. If AI isn't replacing engineers, what exactly is it replacing? The answer is code itself.

Code used to be the bottleneck, and it isn't anymore. LLMs can now produce syntactically correct and functionally adequate code faster than any human. Code was always just the notation for something far more complex, and LLMs just made that impossible to ignore.

Writing code was never the job as engineers. The job is deciding what to build, how it fits together, and whether it should exist at all. Code is the cheapest part of software, and anyone can add to it (especially with the aid of LLMs).

Architecture, Execution, and Taste are what remain scarce.

On Architecture

Ask an LLM to build you a REST API with auth, rate limiting, and a Postgres backend. You'll get something that works.

Ship it to ten users and nobody notices the difference between that and something a senior+ engineer wrote.

Ship it to >10K+ users and everything falls apart. The generated code doesn't account for connection pool exhaustion under burst traffic; it doesn't anticipate what happens when your auth provider goes down; it doesn't know that your team deploys 50 times a day and the database migration strategy needs to reflect that; etc.

These are architecture problems requiring someone who understands the system as a whole, not just the function in front of them. While LLMs are exceptional at producing parts, they aren't great at understanding how parts relate to each other over time, under pressure, and especially at scale.

Architecture is judgment shaped by experience. You can't prompt your way to it because the inputs aren't technical. They're organizational, operational, and deeply contextual. It's the accumulation of decisions about what not to build, where to accept tradeoffs, and which constraints actually matter.

On Execution

Ideas are abundant. Working systems in production are not.

Execution is the boring, unglamorous work that separates prototypes from products. It's the migration plan that doesn't DROP TABLE;s in production, or the rollout strategy that lets you revert in under a minute, or monitoring that tells you something broke before your users do.

Execution is pattern recognition built from consequences. Every engineer who has debugged a production outage at 3am develops an instinct that no model can (yet) replicate. The knowledge isn't occult, but the weight of that knowledge only comes from having lived it. LLMs don't carry the scar tissue of past incidents. You do.

On Taste

Taste is the hardest to articulate and the most valuable of the three. It's the difference between software that technically works and software that feels inevitable.

It shows up in API design where the consumer never reads the docs because the interface is that intuitive; it shows up in error messages that tell you what went wrong and what to do next; it shows up in knowing when a feature request should be declined because it compromises the coherence of the product; etc.

Taste is an editorial instinct applied to systems. It means looking at generated code that passes every test and still saying "this isn't right" because the abstraction is wrong, the naming obscures intent, or the structure will confuse the next person who touches it (or consume additional tokens for the next LLM session that parses it, or sends it in a wild goose chase leading to longer "Thinking..." time). Taste optimizes for clarity, coherence, and longevity while LLMs optimize for correctness.

I believe that the engineers who thrive in this age are the ones who spend less time writing code, and more time on the decisions surrounding it. My advice:

  • Read more code than you write or generate. Develop opinions about system boundaries, failure modes, and interface design.
  • If you don't know something, don't use an LLM to solve it for you. Use an LLM to learn how to solve it. Remember, it's a multiplier - and if you're multiplying by zero, the net result is still zero.
  • Build taste by studying software that aged well and asking why it survived. Lean into Open Source Software (e.g. SQLite is my personal favorite), and read The Architecture of Open Source Applications.
  • Understand your business domain deeply enough that your technical decisions reflect real constraints, not hypothetical ones. Remember that code is just a means to an end, and your "output" in reality isn't building software or even product - it's solving a problem for your users.

And most importantly, ship something and fail. Develop your scar tissues :-)