The purpose of this is to give myself (and anyone else) a refresher on the emerging fields of
(?i)\b(?:(?:vibe|ai|agentic|augmented|swarm)(?:[\s-]powered)?[\s-](?:engineer(?:ing)?|coding)|chat[\s-]oriented[\s-]programming|CHOP)\bA lot of thoughtful people have spent the last three years trying to name what is happening to software engineering due to AI. Each of them moved us forward and back at the same time. I want to lay their work out properly and in one place, because swarm engineering - my newest hobby - only makes sense against it, it is built on their shoulders, and it differs from almost all of them in a few specific ways.
Shawn "swyx" Wang's essay The Rise of the AI Engineer (June 2023) noticed something nobody had named: work that used to take a research team five years could now be done with an API key and an afternoon. He described a new kind of software engineer who builds products on top of foundation models - prompts, retrieval, agents, evaluation, and placed it on a spectrum running from the ML researcher at one end to the product engineer at the other. He then built a community around it: the AI Engineer conferences and the Latent Space podcast.
What I like about it: it gave thousands of people a job title and a community at exactly the moment they needed one. Where we differ: AI engineer was already a role, and a broad one: it covered building AI models, applying AI to new domains, building custom solutions that run on top of AI, and this added building normal software using AI. It was needed for its time, but years later it has ended up too generic to name the specific thing, and I'm seeing confusion spread.
Karpathy has given the field more of its vocabulary than anyone. In 2017 he called neural networks Software 2.0, programs written as weights rather than code. At YC's AI Startup School in June 2025 he described Software 3.0: programs written in English, run by LLMs that are becoming a kind of operating system. In that talk he argued for partial autonomy apps with an autonomy slider - from code completion, to editing a file, to a full agent - so that a person can choose how much to let go.
I remember watching that talk early on and thinking how generous it was: he handed everyone a map they could use the next morning. I wanted to go further, into the parts a single talk can't reach. The more time I spent with this community, the more I saw that many of us, me included, bring our priors in with us and can't see them. People are afraid, and want to argue that their hard-won skills are still uniquely valuable. I agree with them, except for the uniqueness.
In February 2025 he coined vibe coding: "fully give in to the vibes, embrace exponentials, and forget that the code even exists." He meant it playfully, for weekend projects. In early 2026 he proposed agentic engineering for the serious version: "you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight."
What I love: the autonomy slider is the clearest picture anyone has drawn of how humans and models share work today. I also love the sudden spike in interest from designers, product managers, and business people in writing code. Where we differ: I wish we could all just agree that computer science and software skills are becoming more valuable, not less, even though they are changing so rapidly - I don't think Mr Karpathy has ever meant to diminish software engineering or computer science skills, but this has been an unintentional impact of some sensational statements (by others, not named here).
A declaration first: Steve is a friend, and so is Gene Kim, his co-author on Vibe Coding, a book I was privileged to help with in a tiny way. I started talking almost weekly to Steve in 2024, and we continue to talk on the regular. There are many things I say that I rely on Steve (and on Dr Matt Beane, UCSB), to turn back into something that I can communicate.
Yegge named chat-oriented programming (CHOP) in 2024, then laid out six overlapping waves: traditional coding, code completions, chat, coding agents, agent clusters, and agent fleets: each, he argued, several times more productive than the last, with the developers who adapt fastest coming out ahead. Then he built toward the last wave himself. Beads (October 2025) is an issue tracker designed for agents rather than people: work stored as JSONL in git, cached in SQLite, with hash-based IDs so that many agents can write without merge conflicts - his answer to agents waking up with no memory. Gas Town (open-sourced January 2026) orchestrates twenty or thirty agents at once: a Mayor that coordinates, short-lived Polecats that do one task each, and a Refinery that manages the merge queue.
What I like best: almost everything. Haha. Beads is the first widely used tool built for agents rather than for the humans watching them, and our own colony's work ledger, hop, reads and writes the Beads format - we use the Rust fork, here: beads_rust. Steve is also a co-author of the HOP protocol - something we hope to release to creative commons soon, which is a layer that sits on top of beads, and lets workers carry anonymised proof of work instead of credentials, and where the style of marketplace (e.g. auction, bidding, winner take all, evolutionary) is just another type of work. Where we differ, gently: Gas Town is a city with a mayor. Swarm engineering leans toward an ecology: no single coordinator, coordination through a shared record and competition. Steve has moved on a lot since then, and he and I increasingly share a view that towns will become colonies, and colonies are shaped around the organisation, its systems, its customers, and its culture. And he's a better writer than I am, so I'll let him tell it.
Steve's posts on the Wasteland are where Steve and I have spent the most time, and we continue to work together on how we can build protocols for agent communities - colonies - to transfer ideas and thoughts - beyond human speed. I think about the GitHub interface as the human speed interface. My current swarm experiments have forced me to spread out across hardware, because NVMe is too slow, and because agents end up relying on localhost far too much. We're not going to build two-speed coding economies, for agents and humans, unless we have h2a (human to agent), a2h (agent to human) and blah2blah ("I don't care, I just want the job done") protocols. I see a2a, h2a and a2h as subclasses of blah2blah.
That's what I really want work to look like: blah2blah("a description of my problem", [payment terms]), and have the best individuals and swarms submit the best possible work.
Kent Beck, of extreme programming and test-driven development fame, who is an absolutely lovely person (I hope to spend much more time in his presence in the future), wrote Augmented Coding: Beyond the Vibes. In vibe coding, he says, you care only about the behaviour of the system and feed errors back to the genie. In augmented coding "you care about the code, its complexity, the tests, and their coverage. The value system … is similar to hand coding - tidy code that works. It's just that I don't type much of that code." He showed it by building a B+ tree library with an agent, driven by tests.
What I like: it keeps the craft's values while changing who types. Where we differ: augmented coding keeps a human's taste as the judge of quality. And I agree with this, for the human side of things, but this also needs to be reinforced for the AI first side of things, too. My first observation here would be the unit of an open source library.
Rob Pike once said to me, that many Open Source projects suffer from success: They're near perfect, but they then keep adding features and features and all of a sudden, your font parser has its own text editor in it and you need to start again. It's very clear that AI wants libraries to:
There's a rule here, maybe the first rule of swarm engineering, which is to make reality match the hallucination. If a model keeps thinking a library exists, or that your library supports a function call - implement it.
This leads to a new axiom of software interface design: Tell tens of models, hundreds of times, that your library exists, and get them to guess how to use it, and what it does. There's your interface.
Willison, whose blog is one of the best running records of this whole period, proposed vibe engineering in October 2025 as the opposite end from vibe coding: experienced engineers using agents while staying fully accountable for what they ship. He lists what makes it work, such as automated tests, planning in advance, good documentation, version control, code review and research spikes, and observes that these agents amplify existing expertise rather than replace it.
What I like: it is an honest description of how good engineers work with agents right now. What I wish was better understood: Building an app is easy. Building a bridge is easy. Building a safe bridge is harder. Building a safe bridge for millions of trucks and cars to drive over is harder again. The same is true for software engineering - reliability, scalability, security, and maintainability are the true measures of whether software is good. And maintainability, in particular, is almost impossible to measure until it's too late (in a bad way).
Where we differ: as above, it lives in the human realm. Once you say humans must be responsible for the output, everything else follows. If you say that humans need to read the code, and then you work back from there, you end up with vibe engineering. I'm not saying it isn't valid, just that it's not the only way moving forward. I highly recommend reading his posts, either way.
Erik Schluntz and Barry Zhang's Building Effective Agents (December 2024) drew, in my opinion, the most useful line in agent design: workflows run models along predefined code paths; agents let the model direct its own process and tool use. Their advice is to start simple, use a workflow whenever the decision tree can be mapped in advance, and add autonomy only when it pays for itself.
What I like: discipline about complexity, and a clear vocabulary for architecture. And note, they aren't using Agentic Engineering to refer to AI powered engineering at all: they've claimed it as anyone who builds systems that use agents, even if they do it by hand (or punchcard).
Where we differ: This is very off topic for a post on the topic of AI powered engineering, but workflows are the exact opposite of how nature works. Workflows are how people, and factories work. And how some people, in the Descartes frame, think that the whole world works: that is, they see themselves as empowered actors, who make choices, and from there, everything else flows. Random events are a minimal occurrence.
Nature doesn't work that way. The slice of bread falling near the ants' nest is just as much an agent in the ant colony as an ant. In swarm engineering, you care less about telling agents what to do, and more about helping them work out where they are, and let them make useful contributions, before they run out of context. The reason I raise this again, is that I frequently do agentic swarm engineering: My agents swarm around a problem with no central control or coordination, so if they ended up producing something well defined, that would just be strange, so I'd say that this is one way of doing agentic engineering, but the same techniques of swarm intelligence and stigmergy will enter the agentic engineering world sooner or later, too.
Miikka Holkeri at Swarmia set out five levels of coding-agent autonomy (March 2026): assistive (inline suggestions in one file), conversational (pair programming across a repository, with you steering), task agent (plans, edits, tests and opens a pull request for your approval), autonomous teammate (picks its own work from the backlog), and agentic avalanche (orchestrators spawning sub-agents with little supervision). Its key point: higher is not always better; choose the level for the task.
What I like: a practical ladder a team can actually use. Where we differ: it is a ladder of letting go, from a human perspective. Swarm engineering dispenses with the ladder (ladders are for humans, with hands and feet) and asks: what instrument do we really need to build here, for non-human engineers? But I'd also suggest, even without swarm engineering, at the top levels of swarm autonomy, you need to add a lot of extra things to make up for the increased length and changed style of code.
A working paper, Levels of Autonomy for AI Agents, defines autonomy by the role the human plays: operator, collaborator, consultant, approver, observer. It argues that autonomy is a design decision, separate from capability: a very capable agent can be deliberately built to check in often.
My favourite contribution: it puts the question where it belongs, in design. It treats agent autonomy as a first class concern, which changes by business problem. Where we differ: It treats "human first" as vastly superior to "agent first", and uses only human approaches to risk management, rather than expanding on the ways that swarm and non swarm engineered systems should interact.
| Framework | The levels | Who is in the loop |
|---|---|---|
| Steve Yegge, six waves | traditional → completions → chat (CHOP) → coding agents → agent clusters → agent fleets | a human, moving from typist to supervisor |
| Swarmia, five levels of autonomy | from assistive to fully delegated; higher is not always better | a human choosing how far to let go |
| Knight First Amendment Institute, levels of autonomy | the user as operator → collaborator → consultant → approver → observer | a human, in a shrinking role |
| Simon Willison, vibe engineering (2025) | experienced engineers using agents with tests, plans and review | a human, fully accountable |
| Andrej Karpathy, agentic engineering (2026) | "not writing the code directly 99% of the time … orchestrating agents … acting as oversight" | a human, as oversight |
Lay these side by side and a pattern appears. Every one of them describes the relationship between a human and the AI: how much to trust it, how much to let go, how to stay accountable. That is the right question for almost all software being built today, and these frameworks answer it well.
Particularly for software that runs critical systems, that lives depend on, and that needs to work well.
Hopefully, tomorrow, I'll write another post, introducing where I've been spending a lot of my research time.
This page is a living list. I'm committed to keeping it up to date. The words for this work keep changing, and new ones will keep appearing. If you see a term that isn't here, or you know one I've missed, please get in touch at please@swarmengineering.org and I'll add it, with credit to whoever coined it.
In tomorrow's post, I'm going to talk about my newest thinking: swarm engineering. The shortest possible summary: how do we build the operating systems, languages, protocols, tools, and mechanisms for non human programmers, to achieve two outcomes. The first is grip: Can we make our problems simpler, so that a Sonnet-level model can do Fable level work? And the second is efficiency: Can we do more with less tokens. This last one is particularly important, because it isn't just cost. What cannot be fit inside a context window has to be stitched together by the swarm.
Written by Brendan Hopper, 2026-10-04.