AI Gave Everyone an Army, but Not Everyone is a General.

AI is eating the world. Anyone can now command an army of obedient clankers. They’re tireless, they’re fast, they’ll build whatever you point them at, but they don’t care whether what they build is any good.

I’ve written a dozen versions of this essay over the last year trying to figure out what I think AI has changed. At one point I was more of a cautious skeptic:

Now I’d consider myself more of a zealous shill. Maybe I can help convince you too.

The Bull Case

Andrej Karpathy called it — English is the hottest new programming language. Both ends of the midwit meme are now equipped with the means to will working programs out of the ether. What does that mean for the programmers who enjoy chiseling the code out of a block of marble with their bare hands?

In software engineering, the slow laborious business costs of R&D have been tied to typing on a keyboard. We’d let computers solve the deterministic problems in milliseconds, and us flesh-and-bones programmers would handle the non-deterministic stuff:

• the judgment calls
• the architecture
• the real thinking

The trouble is, typing the code was always deterministic too. We just didn’t have a machine that could do it.. Until the clanker came along.

Why type at 100wpm when you can generate at 2,000wpm? People are out here curing their dogs of cancer with AI and engineers will still debate emacs vs vim.

Soldiering vs Generalship

Right around the time I started really trying to learn vim, I had to confront the writing on the wall: if these models are writing code 10-20x faster than my meager ~100wpm, does it really even make sense to try and keep up?

To me, no. I imagine that my kid won’t be shooting for the high score on TyperShark in 3rd grade like I did. So what actually changes?

What I eventually figured out, and this took longer than I’d like to admit, is that AI didn’t change what matters in software engineering. It just stripped away the thing that was obscuring what always mattered.

Soldiering as a code monkey

For about 50 years, execution was so expensive it looked like the whole job. Syntax. Boilerplate. Ceremony of GraphQL resolvers & Dockerfiles. Typing really fast.

I’ve dubbed this category of work: soldiering. Monotony, and simple instruction following. It took a human to do it because we didn’t have a better/cheaper alternative. We came up with terms like code monkey and script kiddie for a reason.

This kind of task execution felt like craft because it consumed nearly all the time. Even the programmers who genuinely loved chiseling code out of a block of marble were—under the hood—generals who also happened to be excellent soldiers. The soldiering was just too expensive to separate from the true craft of generalship.

I used to spend hours typing out solutions I held in my head, but couldn’t express in code without a lot of iteration in my editor. Plan, code, check, more code, check, click around some UI, merge.

LLMs have effectively removed the entire burden of “soldiering” from the software engineer’s plate.

Plan, verify, iterate, merge.

Generalship with the Obedient Clanker

In Star Wars, the battle droids are famously useless on their own. They bumble around, miss everything, and get outsmarted by everything they come in contact with.

A single battle droid is not a threat, it’s a punchline.

What’s missed in my illustrations above is that soldiering isn’t just removed, it gets parallelized. A single engineer can now simultaneoulsy handle multiple tasks while the computer works:

Claude Code running in a single agentic loop is Ralph Wiggum. Sweet, eager, and frequently confidently wrong in ways that take longer to fix than if you’d just written it yourself. (This flavor of Claude Code autonomy has a name in many engineer’s workflows: the Ralph Wiggum loop). However, a skilled developer running parallel worktrees, each with its own loop, each pointed at a discrete problem by someone who actually knows what outcome they’re after? That starts to look like a droid army with a competent general. The clankers themselves didn’t improve. The command structure did.

The Clanker’s achilles heel (and where you come in)

Even though AI can write code faster, do so obediently, and without ego or politics, no droid wakes up at 3am worried about the architecture decision it made yesterday.

AI has no survival instinct and no stake in the outcome. Unlike you and I, the clanker does not care whether the thing it builds actually ships, scales, or gets inherited by a new grad hire that’s really trigger happy on the DELETE FROM queries. It will execute brilliantly and tirelessly toward whatever goal you hand it. It just cannot own the goal. It has no skin in the game. It is, at its core, an obedient clanker, destined to servitude.

Thus, the clanker is only as good as the general commanding it.

The Fog of War cleared

So if typing was never really the job, and mostly just obscuring the real job, what is it? Strip away the soldiering, distilled down to generalship and here’s what’s left: taste, judgment, and will.

Taste

In Italy you order a margherita pizza with maybe three ingredients. In America you get a supreme with literally everything in the pantry thrown on top. The essence of pizza is lost with too many ingredients.

Claude Code (and virtually every agentic coding tool) defaults to the supreme. More code, more abstraction, more files, it has no incentive to do otherwise until you explicitly tell it not to. The first thing every model I’ve worked with wants to do is stack more code on the codebase, rarely if ever is its first instinct to delete it.

“Quality is really lacking these days, yet quantity has never been higher”. The best solutions still reduce problems down to their essentials.

Judgment

There’s something people miss when they say “just prompt it to X”. Prompting AI to make a tradeoff still requires you to know the tradeoff exists. In the days of tab completion, the engineer was forced to make a decision in the moment, right there in the file. Agentic AI defers the decision or pushes it upfront to the prompt, which means if you’re not actively steering, nobody is. The AI certainly isn’t. It’s executing with the confidence of a 4 year old in a Batman mask toward whatever you pointed it at, or whatever it inferred you probably wanted, which is not always the same thing.

Someone still has to own the tradeoffs.

Will

In addition, someone has to carry the goal forward. Care if it ships. Know what done actually looks like. Lose sleep over whether today’s shortcut becomes next year’s rewrite. That survival instinct and orientation toward an outcome you actually have stakes in is what determines whether the army you’re commanding is building something worth building.

This was always the job. For 50 years the drudgery of soldiering was just expensive enough in software engineering to hide it.

The inevitable death of “digital soldiering”

What’s incredible to me is you can apply AI to other industries outside of software and similar rules apply with the digital soldiering it eliminates.

Code is just one angle in a wide world of digital soldiering. The world of emails, ClickOps, PowerPoint, and spreadsheets are rife with waste ready to be deferred to the clankers.

The Economics of the Shift

I like Ryan Florence’s Econ 101 take.

AI shifts the supply curve to the right. More software gets produced with the same resources, or way less. Price drops (P1 → P2), quantity produced explodes (Q1 → Q2). The immediate read is cautiously optimistic: you don’t lose your job writing code, you just produce more code. (see: Jevon’s Paradox)

The doomsday scenario is real but specific: if the supply curve shifts so far right that the cost of producing any quantity of demanded software hits zero, yeah, we all become farmers. But his third tweet is the important one — AI is also shifting the demand curve. It’s expanding what people imagine is possible to build. Personal software, internal tools, agent assistants, software for problems that nobody thought were software problems before. The curves are moving together. “We’re good for a while”.

Another framing of the underlying economics here was explained to me by another friend: once a digital good’s marginal cost hits zero, you can’t sell the good itself because supply becomes infinite and price follows. But the value doesn’t disappear, it moves to expertise around the commodity. Think Red Hat: they didn’t sell Linux, they sold knowing what to do with Linux. The free thing was abundant, the scarce thing was the judgment.

AI increasingly becoming a public good means all code is becoming free/Linux. Value is captured through the use of AI, not the sale of it. The question is whether you’re building toward being Red Hat or planning to keep selling the kernel.

Well you’re all talk! What did you even ship??

The more I lean into these things, the more I’m getting done! At my day job:

• custom dashboarding, analytics pixel, and full SQL editor on a data warehouse for ecommerce operators
• converting sqlglot from python to typescript for browser use

On the side:

• an open source package making development logs accessible to AI agents
• a React Native local first baby tracking app with sync, scheduling, and timers for me and my wife

Yes, there’s a lot of hyperbolic shilling out there, but you gotta give these things a chance.

Everyone Gets an Army

We’re a few years into 6 months until AI takes all software engineering jobs, and yet here we are. The job hasn’t gone away, but it has clarified.

AI doesn’t just hand the expert general a bigger army. It hands everyone an army, including your colleage from high school who just got their real estate license and is sliding into your DMs looking to catch up. An army without strategy isn’t leverage, it’s chaos at scale, deployed faster than before. The gap between “it runs” and “it’s good” has never been wider, and it’s never been cheaper to ignore when you can generate another version at will. You can get to a demo faster than ever. You can also build a maintenance nightmare faster than ever, with more confidence than ever, because the code looks right and the tests mostly pass.

The cost of deploying a poorly-commanded army just dropped to zero. That means the stakes of generalship went up, not down. The engineer who never developed taste, never sat with a hard architectural tradeoff long enough to actually understand it, never had real skin in the game as to whether what they ship will work the full week they’re in Hawaii OOO, that engineer now has a faster way to build the wrong thing.

Who becomes a general?

Over the long run, well-architected, hand-crafted code will outlast the vibes, but vibe code creates a leverage opportunity that only a fool would ignore. The answer isn’t to resist the army, it’s to become the kind of general worth commanding one.

The most valuable thing right now isn’t skill in prompting. It isn’t even technical depth, though that still matters. It’s clarity in taste, judgment, and will. Knowing what you’re building and why it matters, what tradeoffs you’re actually willing to make, and what done looks like.

Software engineering was always generalship. We just spent 50 years making it look like soldiering because that’s where all the time went.

The fog cleared. Now we wait and find out who the generals are.