Code is the easy part

For a long time, we treated software engineering as a translation exercise.

You had a requirement in your head, and the job was to fight the compiler or the framework until that idea was expressed in a language the machine understood. We spent hours on the "how": the exact syntax for a nested loop, the quirks of a CSS grid, or the boilerplate for a new API endpoint.

Because that translation was slow, we built a mental map of the code as we wrote it. Every line represented a decision. By the time a function was finished, you knew exactly why it was there and where it was likely to break. The friction of writing was, in a way, a form of deep verification.

Now, that friction is gone. If you need a function to transform a data structure or a script to migrate a database, an LLM can generate it in seconds. The syntax is perfect, the indentation is flawless, and the "happy path" usually works on the first try.

But this speed creates an illusion of progress. When you didn't write the code, you didn't make the decisions. You are no longer the author; you are the reviewer. And as every engineer knows, reviewing code is significantly harder than writing it.

The bottleneck hasn't disappeared; it has just shifted. We've traded a "syntax bottleneck" for a "verification bottleneck". The challenge today isn't getting the code to exist; it’s proving that it handles the messy reality of the system—the partial failures, the race conditions, and the edge cases that a token-predicter doesn't inherently understand.

The hard part of engineering was never the typing. It was the capacity to hold a complex system in your head and spot the subtle ways it can fail. AI can give us the lines, but it can't give us the "why" behind them.