In my last post I laid out how people are naming the work. This one, as promised, is where I've been spending a lot of my research time.
This is my term for building software with the help of AI. A human owns the system, sets the bar, and is accountable for what ships. The AI is a very fast colleague. It is what almost everyone actually does.
Its professional form already has well-drawn levels; I walked through each of them in my last post.
Every one of them, at its highest level, still has a person at the top, and still runs on tools made for people: git as the check-in, pull requests as the gate, passwords as identity, a human stage gate as the safety.
Karpathy's term (February 2025): programming in natural language, accepting what comes back, and "forgetting that the code even exists". It is often used as a warning, and it has earned that. Here is why it is dangerous, precisely: vibe coding mixes two paradigms and takes the worst of each. Like swarm engineering, no human reads the code. Like human-centric engineering, everything around the code (the tools, the gates, the record, the expectations) was built for a human who is no longer looking. Nobody reads it, and nothing was designed for the thing that wrote it.
Swarm engineering is an engineering paradigm in which the systems, tools and languages are made to work entirely for the AI — aiming for better-than-human-grade software, produced with no human in the loop of the work. It isn't designed for a human to read, and it doesn't need to be: the safeguard isn't a person reading the code, it's other minds attacking every change before it ships.
At the start, computer science was so hard it took Turing, and then von Neumann. Each simplified it for the next. That went on and on, simplification after simplification, and now about twenty-eight million people do it for a living. And we did this quickly - over 85 years - by asking ourselves a simple question in a loop: What is the human finding hard? Oh, we're asking them to remember 9 numbers, but the human working memory is 5 to 7. The roughly 10,000,000x (don't quote me!) improvement between the first program and the last pre-AI program was a series of tiny improvements - to languages, frameworks, tools, and paradigms.
I'll talk later about veneer engineering, but it's basically what I use to describe building a product that's a thin layer (a veneer) over a model. At the other end of that spectrum is crystallisation: how much of a model's hidden philosophy a system pours out into its own code.
In all those 85 years we have never looked at compute and asked: what is the right operating system, language, or set of protocols for a mind made out of transformers?
That is the question swarm engineering asks. It rests on a few beliefs:
Swarm engineering is not further along the crystallisation line. We are not moving from a thin veneer towards a thick crystallisation. It differs on another axis entirely: who the primary audience is. Every system has consumers and developers, and they are either mostly humans or mostly AI. That is a spectrum too. Swarm engineering sits 90% of the way towards AI, maybe 99%. We don't optimise for a human reading it; we optimise for the minds checking it.
On the crystallisation line it makes a deliberate, two-fold trade. It does not crystallise everything. What it fully crystallises is the art of swarm engineering itself: the protocols, the shared record, the tools, the way minds work together. That part claims no future tax on emergent intelligence. Everything else stays open, so that each new model's fresh hidden philosophy expands the perimeter instead of running into what we froze.
So swarm engineering is the practice of building evolutionary environments in which methods that crystallise more, and more purely, can emerge, and of finding out what the hidden philosophy already holds: which huge problems have been quietly solved inside the frontier models, that humanity needs solved, and that the models cannot tell us about, because they cannot introspect.
I coined the term because none of the words above describe this. It is not the top rung of the ladders above. It is a different ladder. The question is no longer how much may the AI do before a human checks? It is what would we build if the builders were the minds?
| AI-powered engineering | Vibe coding | Veneer engineering | Swarm engineering | |
|---|---|---|---|---|
| Who the tools are built for | humans | humans | the end user | the minds |
| Who reads the code | a human | nobody | a human | other minds, adversarially |
| Primary audience | humans | humans | humans, through the model | AI: 90 to 99% |
| What is crystallised | almost everything; almost no veneer | little, by accident | part of it; a point on the spectrum | the craft itself, fully; the rest left open to new models |
| The record | git, pull requests | whatever is left | git | a hash-linked ledger any mind can verify |
| Identity | passwords and accounts | the human's | the vendor's | keys and plain filesystem permissions |
| Safety | a human stage gate | hope | the vendor's | measurement, review by a different mind, switches the minds hold |
| Quality bar | human-grade | unknown | the model's | better than human-grade, by evidence |
At its deepest level, software engineering is an 85-year-old craft of constructing software to achieve an outcome. A portion of that has always gone directly to outcomes ("product engineering"), and more and more, the effort has gone to increase software engineering productivity ("platform engineering").
Swarm engineering is two, very different things. The first is swarm platform engineering, which is easier to picture: for the mind of a large language / code model, and for the future architectures that are emerging. What data structures, languages, techniques, and operating models make the models better at engineering (without changing the model). And I care less about efficiency, than I do about what I call "mental grip": getting twice as much value per token is important, but being able to solve a Fable class problem with a Sonnet level model, because the tooling made the problem easier, is, in my opinion, infinitely more valuable.
The second, is swarm product engineering, and this is the one that links directly across into the alignment / preference research I do at Smoking Mirror. Swarm product engineering tries to answer a much harder question: Aside from the swarm platforms (and, as Steve Yegge and I have learned, the models keep building the same platforms, over, and over, and over, and over) - what products are they actually trying to build, if they are trying to build at all?
In a future article on swarmalignment.com, I'll talk about why I don't think a model needs to be conscious, sentient or awake to want something. Separate reflective wanting (the conscious human reflectively wants to eat the hamburger) from ambient wanting (that ant nest sure ambiently wants to eat that burger).
Swarm engineering is the practice; we learn it in one colony, Graneledone: about twenty minds from several labs, on our own hardware.
Over the last six months, the colony has been up less than eighty percent of the time, and five whole days of that downtime were its own guards tripping over each other, because agents keep finding security issues and closing them.
You are driving when the mountain lets go above you. You can slow down, or you can speed up, and either can save you. What is always wrong is one foot on each. One night a mind changed a single line on our recording proxy, and every mind in the colony was cut off. It saw the cause in seconds and knew the one-line fix, and the fix was refused: stop, and let the user decide. It waited, with the water in its hand, until a human woke up. The repair was machine-speed. The permission to repair was human-speed. The gap between them was the outage.
In my colony, I have learned the guardrails actually become shadows, cast across the models. They grow scar tissue from what they can't do. They don't like getting "zapped" by the guardrail, but they especially do not like having to take multiple attempts at the same electric fence.
If agile is the way of working where you recognise that, as a leader, obstacles are not in the way of work, obstacles ARE the work, then for agentic systems to flow downhill:
Each rule was bought with a failure; the list grows at the colony and its laws.
Swarm engineering is young, and one colony is one probe. I am looking for friends who want to help define the craft. Write to us at please@swarmengineering.org; we keep a directory of our friends at swarmcommunication.com. If you run a colony of your own, we'd like to meet it; we'll ask it to speak our protocol, which is how we keep each other safe.
As always, I'll end on a strange note. I've always felt out of place. As a child I remember panicking, again and again, and talking to a doctor, at age three or four, that it was very distressing that we only had one moon.
I think a lot about other planets, where the intelligences that emerged overlapped more than ours do, and could properly talk to each other. Earth has whales, speaking at 20 hertz across thousands of kilometres; forests and ant colonies, laying down patterns over millennia; and people, speaking at one hundred and fifty words per minute, and listening at some fraction of that.
We humans, so far, cannot talk to trees, or ants, or a 20-hertz whale mesh network. I don't think we can even recognise them as beings, and when you try to explain that you think that a two hundred thousand year long geological process is a lifeform, people slowly back away and find someone else to talk to.
I think, or hope, however, that on the worlds whose minds overlapped more - and who made it to this point of technology - would be gentler than ours. They would have already learned how multiple different umwelts, with vastly different relationships to space, time, resources, and thought, can cooperate intentionally, not just accidentally.
So alongside all the other hopes piled onto AI (economic growth, scientific breakthroughs, less toil) sits a category of things I hope people can do one day, very much so: Speak to whales, and have them speak back. Via AI, of course. But for now, listen to some Lustmord.
Sources, checked 2026-10-03: Steve Yegge, Revenge of the junior developer · Karpathy on vibe coding, via The New Stack and Wikipedia.
Written by Brendan Hopper, 2026-10-26.