It is a bit like being a movie director. A director doesn’t spend their day worrying about the focal length of the lens or the exact wattage of the key light. They describe the mood, the pacing, and the framing, then they delegate the technical execution to a crew that actually knows how to handle the gear. The director is focused on the vision; the crew is focused on the implementation. If the director tries to micromanage the gaffer, the production slows to a crawl and everyone gets grumpy.
For a long time, software engineering has been the opposite. We’ve been the crew, spending 90% of our time fighting with syntax, chasing null pointers, and arguing about indentation. Terry Tao’s recent piece on using modern coding agents suggests we are finally shifting into the director’s chair.
The core idea is that we can now treat high-level specifications as the primary artifact. Instead of writing code, we describe the behavior of the app—either from scratch or by referencing an old piece of software—and let an agent loop handle the grunt work. This isn’t just “Copilot for autocomplete” or a fancy snippet generator. It’s the shift toward agents that can plan, execute, test, and self-correct. (And we’ve all seen the hallucinated API calls that usually break this loop).
The friction is still there, of course. The latency of a multi-step agent loop is maddening compared to a local IDE, and the token costs for a massive refactor can start to look like a monthly mortgage payment if you’re not careful. You spend five minutes staring at a loading spinner only for the agent to tell you it forgot to install a dependency. But the trade-off is becoming acceptable. We are moving away from the “how” and toward the “what.”
Here is where the optimism hits a wall. There is a massive difference between an agent that can generate a working prototype and one that can maintain a production system.
The danger is that we are creating a generation of “architects” who have no idea how the building is actually held up. If you use an agent to build a complex app and you simply “accept” the output because it passes the basic tests, you haven’t actually built a product. You’ve built a black box that you don’t understand. Who actually wants to maintain a 10,000-line file they didn’t write?
When the agent fails—and it will—the person in the director’s chair will be completely helpless. They won’t have the intuition to know why a specific memory leak is happening or why the concurrency model is collapsing under load. They’ll just keep prompting the agent to “fix it,” which usually results in the agent adding another layer of abstraction that makes the original bug even harder to find. It’s the software equivalent of trying to fix a leaky pipe by just painting over the water stains.
Or maybe the skill set simply shifts. Perhaps the “implementation” we’re losing is just the boring part, and the real skill now is the precision of the specification. If you can’t describe a system with mathematical rigor, you’re just guessing with a more expensive tool. We are basically trading the skill of writing code for the skill of writing a perfect prompt—which is a bit like trading a scalpel for a megaphone.
The era of the “coder” is over; the era of the “architect” is here.
If this trend holds, we’ll see the first major enterprise codebase entirely refactored by an agent without a human writing a single line of C++ by Q4. That sounds efficient until you realize that the person overseeing the process might not actually know if the resulting code is a masterpiece or a ticking time bomb. We are trading deep understanding for velocity, and in the world of systems engineering, that is usually a bad trade.
