I've been writing code for the last ~18 years, and professionally for about 8 years (including at Google, Uber) - and I’ve got to say I’ve really loved it.
And what’s not to love? I got to spend most of my time building fun things, the reward feedback loop was tight and my tools got better pretty much every few years. Syntax highlighting, auto-complete, IntelliSense, project-level refactorings, and even early Github Copilot all made my experience writing code more joyful. With every generation of improvements, it felt like these enhancements helped *me* be a better coder. Until now.
This latest wave feels very, very different. With agentic programming (*cough* vibe-coding), it doesn't feel like another incremental upgrade. It actively scrambles my perception of what's coming next, and my role in it.
I tried to narrow down on why exactly it feels so different. Then as I witnessed a code agent one-shot yet another small but still somewhat ambiguous task on my codebase, it suddenly dawned on me. It doesn't feel like I'm “coding” anymore, rather it feels like I’m “delegating”. It feels like I'm giving abstract instructions to another human, or a set of humans - rather than giving precise instructions to a computer. This has crossed some sort of chasm for me. A "feel the AGI" moment of sorts.
It still feels like I’m “directing” or “programming” the system. But what’s different is that I’m now programming an organization of agent coders to achieve the goal, rather than programming the computer directly. Working this way requires me to confront an unfortunate new truth.
A Sobering Realization
The economic value of my knowing how to “code” has gone to zero. The fact of the matter is that everyone in the world now has (or soon will have) access to an army of increasingly brilliant coders in their pocket. One they can instantly summon whenever they want. And it’s basically free.
It’s a bittersweet realization. I empathize with @amasad’s sentiment here, after a tweet where he says he “no longer thinks you should learn to code”.
Coding for art’s sake v/s Coding for the user’s sake
Coding for fun is enjoyable. Back in undergrad days, I really enjoyed competitive programming too. My team even went for the ACM-ICPC Asia regionals twice, and we generally had a blast. There’s a certain rush that comes from figuring out a problem, and writing code to solve it. It’s not entirely unlike a crossword puzzle or a sudoku or a math problem. Sure, you could get help to do it (erm. cheat!), but that’s not the point of it. This is an artisanal mindset. Coding for art's sake. For the mere fun of the game.
When working on a product, you largely need to throw that mindset out the window. Here, the code mainly exists to serve the product and the user. It's a means to an end. The end user doesn’t care whether I wrote it, or instructed an agent to write it. The user only cares that it works. Correctly, reliably, securely, fast. That they can forget it exists, and get on with their day. So the question then becomes “What’s the fastest way to get to (good, maintainable) code that does that?”
Unfortunately, it seems like the answer to that is that I may have to learn to… get out of the way. That maybe I mostly shouldn’t be writing code anymore, because doing so would make me the bottleneck, or even worse - the hindrance.
In ”Average is Over”, Tyler Cowen talked about the dynamic of “human + computer” teams in chess. Such teamups (surprisingly) still held an advantage even as recently as 2013, but the trend line of human contribution to the team was clear. From his essay “What are humans still good for”:
it is interesting to observe an approach to the flip point, where even the most talented humans move from being very real contributors to being strictly zero marginal product. Or negative marginal product, as the case may be
A similar dynamic seems to be playing out here in coding. For now, it appears I can still add value by looking at the machine output and adding value on top of it, but once again - for how long?. What’s currently good for quick prototyping today will improve and be the builder of robust systems tomorrow. Today’s toy is tomorrow’s tool.
On one hand, low level things getting abstracted away isn't new for the field. Computer Science, much moreso than other fields has a rich history of composability. Chances are you haven't written in machine code or assembly in a while if ever (thank you compilers!). You've almost certainly used building blocks (libraries/APIs/platforms) created by other people. It's wrappers all the way down to the silicon.
For now however, coding remains only one part of the overall software engineering process. And it just so turns out that the way I can bring most value to this system is not with my coding ability anymore, it’s with my vision and ability to articulate what I want, and to steer this organization of agents towards that goal. It's to eliminate ambiguity as much as possible, and to bridge the gap between the vision and the spec. In a sense, this role is closer to an “Agent Director” than a software engineer writing code.
So where do we go from here?
Because it's like delegation, axioms of human organization management seem to apply to agent organization management. For example:
- Know your agents limitations, and delegate accordingly. They will always willingly attempt to bite off more they can chew. Don't let them.
- Setup systems of checks and balances to catch when a change is breaking, and to guide the agent towards writing good code. Type safety is good. Tests are good.
- Setup an environment where agents can get the info they need to succeed. Documentation is good. Separation of concerns is good. A well organized codebase is good.
- Parallelization is good. Don't just wait on a single agent in a single threaded way, especially for long running tasks. There's a solid chance that future elite programmers resemble torrential high APM Starcraft players - commanding and collating the outputs of their army of agent units.
- And most importantly, make your vision clear and communicate it clearly, so that the agent can be empowered to make the right decisions fitting into your broader framework. What the agent really doesn’t know is what you want, so it’s up to you to direct it towards that.
And after all is said and done though, when you finally deliver something - you’re still stamping it with your seal of quality. Your name and reputation is your brand. As the "lead" of those agents, you’re still accountable for their results. The buck stops with you.
