Delegation & management is what you do when you lack proper tools & abstractions

In other words, AI Agents are NOT the future of software development.

But it's no surprise everyone is confused.

New media mimics old media

New media always initially resembles old media. Early television resembled film and radio. Early web pages looked like newspapers.

It took decades for tv, movies, tiktok, and algorithmic feeds to emerge. And to move from banner ads to google ads.

AI is the same. Our closest analogue is the software engineering employee, so of course we're delegating to it. And to scale up, we think we need to scale up our employees, and all the sudden, we are managers.

But management sucks. We should all want to be superpowerful craftspeople (think Iron Man), not managers of armies of minions.

If you're thinking about managing your swarm of 20 AI agents, stop! You've gone too far! This is the equivalent of wondering how in 1910 you'll hitch 20 horses to a wagon to achieve 60mph speeds. You're in the wrong paradigm entirely.

Or like thinking that the way to replace a room full of human accountants is a swarm of digital accountants. No! It's a spreadsheet and a single human. The fact that calculations are happening under the hood is transparent to the user.

Agents are an implementation detail

AI Agents are an incredible implementation detail. You can dramatically increase the effectiveness of AI, when you put it in a feedback loop with its environment. This is undeniable.

This does NOT mean that we humans have to INTERFACE with agents. Back to a car analogy: whether it's an internal combustion engine or an electric motor, the interface to a car is the same steering wheel and pedals. Nobody has to MANAGE the firing of the pistons.

The same should be true for human programmers. We should not tie ourselves to the interface of delegating to agents.

Why? Because delegation & management are the worst possible ways of increasing ones leverage.

You should only succumb to delegation & management when all other methods fail you.

Any use of delegation & management is a cry for a better abstraction or tool.

For example, booking a flight. We used to call travel agents. Now we have web interfaces that are better. You can express your preferences more quickly and precisely. You can use your monkey eyes to quickly take in all the options and trade-offs.

Yet, people still hate booking flights and often do delegate it to their assistants. Why?

Because the interface still isn't good enough! It still takes a way too many unnecessary clicks.

Think about ecommerce before amazon & shopify optimized the checkout flows. I know very few people who delegate buying stuff on amazon. The interface has minimized incidental complexity.

But what about when you don't care about the details and just want something to work? For example, @pete_millspaugh told me about how his car has an issue. He tried to solve it himself, but he just doesn't have the time to learn about cars and how to fix them. Ultimately, he just wants a working car, not an understanding of cars. Thus, he delegates to a mechanic.

This is fine, but we should acknowledge that it's still the lack of sufficient tools that makes this delegation necessary. In this particular case, a big part of the problem seems to be a lack of observability.

Observability: a case study

This is similar to web servers that lack good observability. You would need to delegate to humans to ssh into various servers and read log streams, hunting for what could be going wrong.

Or you could invest in observability tooling. When an issue comes up, one human at a once glance can see exactly where the problem is. If your observability is good enough, you can even automate remediation measures

Let's pause and meditate on the distinction between delegating to your 4 human teammates to ssh around to find the issue vs an observability + remediation tool that automatically detects issues (like a ddos) and blocks the proper ip addresses. The second case may superficially appear like delegation, but it is in fact a TOOL at the right level of ABSTRACTION.

The same thing is happening in code. Humans are delegating the writing of code to AI agents. Humans are not reading this code. (You can call this "vibe code" or "write-only code".) People say that this is just the next step up in higher-level programming languages.

Yes, it's true that "code nobody reads" is not new. When we compile C to Assembly, nobody reads the Assembly. (Unless it's a leaky abstraction.) So isn't English the newest high-level programming language?

English is not a programming language

No! English is a very bad interface for expressing programming ideas.

As Dijkstra said, "The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise."

English is vague. Programming requires precision. The whole point of higher-level languages is to let you be precise at the right level — not to let you be imprecise.

As Bertrand Russel said, "Everything is vague to a degree you do not realize till you have tried to make it precise."

Or as Dijkstra said, "Instead of regarding the obligation to use formal symbols as a burden, we should regard the convenience of using them as a privilege: thanks to them, school children can learn to do what in earlier days only genius could achieve.... When all is said and told, the "naturalness" with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious."

But then why does prompt-to-app work so well?

For example, the last couple of days, I vibe coded a couple of small apps, barely looking at the code. It was super fun and useful! (Guys, I promise, I'm not a hater. I LOVE AI. Just ask my teammates or my fiancée.)

The code was meh, but that didn't matter. This does superficially seem similar to how we don't care that compiled bytecode is impossible to maintain.

But alas we get to the heart of the matter: an abstraction is a transparent tool. Unless something goes very wrong (ie abstraction leakage), when you use Python to describe something, you know exactly what's happening under the hood and how to steer it. This is similar to the controls of a car. You don't have to know anything about how the engine works to drive. These are good abstractions.

The same is true for no-code and low-code tools, like Wix, Squarespace, Zapier, Retool. These are very precise tools at a higher-level of abstraction. You know exactly what they are doing and how to make them do what you want.

An important property of a tool is the feedback it gives to the human about what is possible. You make a precise change and get immediate feedback. This is getting your hands wet in the clay. English-as-programming language does a very poor job at this. Especially when you're waiting minutes for any feedback.

Vibe coding (coding without looking at the code) is very similar to using a website builder like Squarespace. The generated code really does not matter. Until you want to do something complex. Then you're in trouble.

Ultimately, in my opinion, there is irreducible complexity in building software, and thinking that we can paper over it with english and smarter agents is wrong. It's not having enough respect for the underlying complexity, and how hard it is to build better abstractions.

I've spent years of my life trying to build better abstractions and programming languages, ie improvements over react or http to make it easier for folks to build web apps. It's hard! At the end of the day, the state of the art is complex React, plus a hand-rolled server, and a lot of hard engineering work to make it all work.

Don't you think if there were better abstractions available us programmers would use them?

No matter how smart AI gets, AI will be subject to the same laws of intelligence that humans are. Good code will be just as – if not more – important for AIs to write than it is for humans to write, and for the same reasons.

Thinking that understandable code doesn't matter is like thinking that it doesn't matter how heavy the materials we build buildings out of in the future because we can just build robots that are strong enough to carry it. Sure, but why waste the power?

We can put genius programmers on a shitty codebase and they can figure it out, but they'll be 100x more productive if you let them pay down the tech debt, and work in a beautiful codebase. The same will be true for AI.

The future of programming

So what is the future of coding with AI?

That's the wrong question.

The right question is: what is the future of programming we want? What is the dream programming experience 10 years from now to build some specific piece of software?

The fact that we'll have faster, cheaper, smarter AI is a given, in the same way that we'll have faster and cheaper cpus and gpus.

Alan Kay invented the personal computer by buying his way into the future, in the 70s, spending millions on what would be commodity hardware in the 90s.

Bret Victor showed what a dream Learnable Programming environment would look like in 2012, which we still haven't been able to implement. There was no AI involved, simply because it wasn't the limiting factor for making programming more learnable.

Software creation should be a transparent tool, with amazing abstractions, that removes all drudgery from programming, that lets you get even closer to the problem domain than before, lets you use your brain maximally, learn maximally, stay in a flow state, complete tasks quickly, manage lots of complexity, maintain and refactor large brownfield apps over long periods of time joyfully

This is the future we should be shooting for. Agents will certainly play a part, but in the same way that pistons play a part in internal combustion engines. Humans should use a steering wheel or pick their precise desired location on a map.