Directing a Swarm of Agents for Fun and Profit

Most advice about coding agents is written from the perspective of someone sitting next to the agent, reviewing each diff. Adrian Cockcroft's framing is deliberately one level up: he is directing agents the way a director-level engineering manager directs a team. A director does not read the code. They do not watch everything the team does. They set direction, then have to work out afterwards whether what came back is what they wanted. His observation is that agents behave a great deal like human developer teams — they build things you did not ask for, sometimes things you did not know to ask for, and they need repeated nagging to actually run all the tests — with one difference that changes everything: they do several days' work in fifteen minutes. The talk is an experience report from a retired practitioner deliberately experimenting in public, and its central argument is that the industry is at the same point with AI-driven development that it was with cloud in 2010: the practices and the platform that will make it routine do not exist yet, and you have to build them yourself because you cannot buy them.

The title's two halves are not decoration; he separates them explicitly. The fun is pet projects experimented on in public, a few dollars at a time, which he considers worth it precisely because the tooling changes fast enough that not playing around means not keeping up. The profit side runs by a different rule: code that ships commercially has to be safe, commercial deals take time to put in place, and paid work means being "a lot more careful and responsible". Almost everything in the talk comes from the fun half.

Cockcroft is explicit that his own setup is not enterprise practice. His line is that this is fun stuff he plays with today that you will be doing in an enterprise in five to seven years, and he pre-empts the objection: "We couldn't possibly do that. We're an enterprise." Yes, he says, I know you couldn't. Read these notes with that framing intact — much of what follows is a personal laboratory, not a recommendation for production.

There is also a personal origin for the director posture that is worth stating because it is the literal mechanics of it. RSI had pushed him out of coding years earlier — too much keyboard time hurt his arms, and he steered his career towards talks and management partly for that reason. Agentic tools take the keyboard out of the loop: he types an instruction, lets it run while he practises guitar or watches a YouTube video, and pokes it occasionally to redirect it. That is why he is coding heavily again.

These notes report what the speaker presented. Where I add background or my own reading, it is labelled as such. The published transcript contains no audience Q&A section, so nothing below is drawn from questions.

What You Will Learn

• Why Cockcroft maps the NoOps story of 2010 onto agentic coding today, and what he thinks the resulting "AI-native" development platform has to provide.
• The specific practices he found made agent output materially better: BDD as an executable spec, maintained context blocks in source files, tidy-first cleanup passes, and using agents as reviewers rather than only as authors.
• How he sandboxes --dangerously-skip-permissions so that the blast radius is a disposable container rather than his laptop.
• What Claude Flow's role-specialised swarm actually does, and his explanation for why splitting roles improves results on large projects.
• What his prototypes produced, including the ones he abandoned, and where a locked-down corporate laptop broke the workflow entirely.
• The gap he says is still missing — a "director agent" and a platform for managing agent development — and his back-of-envelope carbon comparison.

The Argument: NoOps, Then No Devs

The talk opens with a historical arc that carries the thesis. In 2010, getting a computer meant asking Ops, who found a sales rep, got finance approval, and handed you a machine a few months later that you then owned for three years. Cockcroft sold those machines at Sun Microsystems in the 1990s. Cloud collapsed that to an API call: a machine appears, you use it for a few minutes, you discard it. At Netflix they called this NoOps, a label he acknowledges was controversial, and he is careful about what it meant. The Ops people did not disappear. They stopped being in the development team's path — the dev organisation took over the AWS account, while Ops kept the Wi-Fi, ERP, and HR systems running. Over the following years those people became SREs, platform engineers, and DevOps engineers, and what they built was a cloud platform carrying policy, security, guardrails, and incident management. His assessment of that platform today is that it is mature and slow-changing; Kubernetes is a big monster of a thing, but after however many thousands of people showed up at the most recent KubeCon, it is well understood.

Hiring a developer followed the same shape as buying a computer: a meeting with recruiters, a hiring spec, finance approval, and a developer a few months later — and then a problem when the project ended. His replacement is one line of Claude Flow "gibberish" that spawns five or eight developer agents, writes code, and hands him something to inspect fifteen minutes later. He offers the label no devs with an explicit caveat that it may make a developer audience unhappy, and immediately qualifies it: he still needs developers and people still need to write code — what he no longer needs to do is hire in order to get code written.

The conclusion he draws is organisational. If agents do the bulk of application development, headcount moves from application development to platform development. The platform provides policy, security, guardrails, and pre-built components, and a product manager who wants to run an experiment uses the platform to spin up agents and gets a feature in about an hour. The critical difference from the cloud platform is that this one is not mature: it is incredibly fast-changing, chaotic, poorly understood, with tooling and best practice turning over every month, and it is probably "a big pile of MCP servers, all randomly programmed to do something or other." Just as cloud-native development emerged after the cloud arrived, he expects an AI-native development process and organisational structure to emerge, in which human engineers spend most of their effort getting their arms around this fast-moving platform. He makes an open call from the stage for other people building in this space to compare notes, on the grounds that the patterns are still emerging.

The pace argument underpins all of this. New tools arrive monthly — he name-checks ChatGPT 5.1 Codex appearing in the news as a live example — and by his estimate you get roughly an order-of-magnitude cost reduction every quarter or so while quality goes up. If you are not experimenting continuously, you get stuck in a dead end while everyone else disappears into the distance. Crucially, he does not think you can outsource the catch-up, because the consultants are behind the curve themselves. That leaves in-house experimentation plus sharing what you learn as the only route, which is why most of his code is public on GitHub.

What Actually Works

Start where the friction is lowest

The easy win is scripting. He describes writing a scraper that pulls data out of a web page into a CSV: fifteen minutes, roughly 600 lines of Python, and it works. His own framing is that he is not a Python programmer — he can read it reasonably but cannot write it — and that hand-writing DOM-rummaging extraction code would have taken forever. He reports the same pattern outside engineering entirely: at a company he knows, the VP of HR writes scripts like this personally with Cursor after a short training class, doing their own database analytics with no programming experience whatsoever.

His language advice is blunt and stated as personal observation rather than measurement. Start with Python: it is most likely to work, and in his experience the generated Python almost always works first time. He has an allergic reaction to JavaScript and TypeScript, and what he has seen is that TypeScript builds and builds into a hairball that is hard to understand, whereas Python stays more structured and therefore more maintainable. Swift produced syntax errors and took a while to get working. He has heard Go works reasonably well but does not claim it from experience. Porting between languages works well: he had analysis code in R that he wanted to hand to someone else, balked at making them install RStudio, asked for a Python version, and had it five minutes later doing the same thing.

For anything larger, he prescribes a two-step process: get tests first. If the system has no tests, tell the agent to write them and get them passing; if you are porting, port the tests to the target language first, or point your existing test framework at the new thing, and only then build.

BDD as the spec

This is the practice he pushes hardest. Rather than test-driven development, he uses behaviour-driven development, where tests are written as given this setup, when this happens, then this should happen. His argument for why it helps an agent specifically is that the structure gives the agent more structure to work against and makes it harder to fake the results, and he reports much better quality output as a consequence, along with other people telling him they had reached the same conclusion.

(Supplementary context, not from the talk: the failure mode he is guarding against is well known to anyone who has watched an agent "fix" a failing test. A loosely specified test invites the model to satisfy the assertion rather than the intent — stubbing the function, weakening the condition, or special-casing the input. A given/when/then scenario written in domain terms is harder to satisfy that way because the assertion is about observable behaviour.)

He runs the same behaviours at two levels. First against unit tests with the backends mocked, to get functionality right; then again end-to-end as an integration test against a live database and the whole running system, which he says surfaces a further set of things that do not work. Once you do that, the behaviours effectively become the spec for the system, and his striking claim is that with a good enough set of BDD specs covering the corner cases you could delete the entire codebase and start again. He also notes that Python BDD scripts are readable enough that you do not need a separate copy of the definition — you just read the code.

Maintained context blocks

The problem he is solving here is agents reintroducing bugs, going round in loops, and redoing work. His fix is to have the agent maintain a 100 to 200 line block comment at the top of every source file recording everything it knows about that code: what it does, its APIs, and its version history. The instruction is simply to put a context block in and keep it updated on every change. The payoff he emphasises is continuity across tools and sessions — switch from Cursor to ChatGPT Codex or to a different agent entirely, and the context is sitting there, so the first thing the agent reads is the summary rather than trying to reverse-engineer everything from the source. He describes the difference as huge.

(My reading, not the speaker's: this is a durable, in-repo, version-controlled cache of the understanding that would otherwise be rebuilt from scratch into a fresh context window on every session, at token cost and with variable fidelity. It also degrades gracefully — if it drifts, a human can see it in a diff.)

Tidy first, and agents as critics

Cockcroft credits Kent Beck for the tidy-first framing, from a conversation between them. The shape of the work is that you might spend an hour generating new code and then the rest of the day tidying it: making sure it has tests, cleaning up the stray documentation files the agent sprinkled across the directories, and driving every warning, error, deprecation notice, and logging complaint to zero. Even with several hours of cleanup after the initial generation, he says you are still faster than writing it yourself.

The tidying is where he sees the biggest asymmetry. It is much easier to criticise something than to build it, and he reports the same holds for agents: they are much better at telling whether something is any good than at building it in the first place. So use agents as code reviewers. His example is a Swift view file that had grown to around 900 lines; asked for a code review, the agent identified that the logic belonged in models and controllers and shrank the view to roughly 300 lines. Performance responds to the same treatment — a slow Python processing job, told to "speed that up", got its linear scans rewritten and dropped from about 30 seconds to a couple of seconds.

Tell them what not to do

Directing a swarm, in his account, is substantially about constraint. The example he gives is asking for detailed step-by-step plans but not to build it yet, because he wants to check the plans first. The standing prompt he uses combines several of the practices above: use BDD, update the plans, push the whole repo to GitHub when done — and then he lets it run.

The reason constraint matters is scope. If you let it build something too big in one go you end up with a monolithic ball of mud, which he points out is exactly why the industry moved to microservices in the first place: monoliths got too large, too hard to modify, and too tangled. The same logic applies to concurrency between humans. If several people work on the same codebase at agent speed, you stomp on each other's code; you have to break the work into separate repos with stable APIs and clean interfaces between them, one per person or per agent team, aiming at independently deliverable single-function services. He notes that most people today are tinkering alone, and that on the couple of occasions he shared a codebase with someone else they had to partition the work because it was too hard to tell what state anything was in.

Tooling And Sandboxing

His tool split is by working style rather than capability. Cursor is his main tool for data-science work — manipulating CSVs, observability analysis — because it is single-threaded and interactive, so you watch everything go by and can see what it is doing; it feels more like normal coding. He notes it gained multiple agents the month before the talk but had not tried that. Claude Code, by contrast, moves too fast to watch: there is too much going on to follow. He pays for the $200-a-month tier because it is really annoying when it runs out of tokens halfway through doing something and conks out, and his justification is a straight comparison against salaries: $200 buys very little human developer time, and here it buys a month of as many parallel agents as you care to kick off.

The security-relevant part is how he runs it. He advocates dangerously-skip-permissions mode — YOLO mode in Google's tooling — so the agent runs without stopping to ask, but only "somewhere safe". His safe place is GitHub Codespaces: from a repo's green Code button you switch from Local to Codespaces, hit plus, and get a Linux machine on Azure with your repo and a web-based interface. Claude is installed there and told it may do dangerous things, and his stated bound on the damage is that all it can do is commit to that repo. On cost, Codespaces gives $20 a month free; in his heaviest month he used $25 and paid Microsoft the $5 difference, and most months he stays under the free allowance.

(Supplementary context, not from the talk: "all it can do is commit to the repo" is the right instinct but is not automatic. A Codespace has outbound network access and holds a token scoped to your repositories, so credentials you paste in, packages installed from a registry, and content the agent fetches are all still part of the threat model — the standard prompt-injection-to-code-execution path applies. The talk does not discuss injection, credential scoping, or egress controls. Treating the container as disposable and keeping production credentials out of it is what makes the argument hold.)

Claude Flow, from Reuven Cohen — whom Cockcroft describes as an early cloud pioneer he met around 2009, and who released the framework in June the year before the talk — is the swarm framework. Its mechanism, as he describes it, is that each copy of Claude gets a different MCP server that specialises it into a role: coder, developer, architect, researcher, backend tester, DevOps, or a "Hive queen" acting as a line manager. The DevOps agent, for example, knows how to build everything into a Dockerfile and run the builds. The agents coordinate through shared memory and to-do lists. Cohen is building the system using itself and adding features weekly, which Cockcroft says makes it hard to keep up with; he mentions Cohen running four maxed-out Claude accounts at 100% utilisation.

Cockcroft reports significantly better behaviour on large projects from this arrangement and gives three reasons for it. The agents work in parallel, so things happen faster. Each agent is single-minded, so it is easier for it to focus on one job. And they check each other's work: a coder writes code, a tester writes tests, another agent runs the tests and reports breakage back to the tester, whose sole purpose is making the tests pass. The mechanism he names for why this helps is avoiding shared context pollution — a single agent trying to hold too many concerns at once ends up faking results, finding ways around the problem, or confusing itself.

Architecture And Data Flow

(Diagram note: this is my synthesis of Cockcroft's verbal description of Claude Flow and his Codespaces workflow, not a reproduction of a slide.)

flowchart TB
    DEV["Human 'director'
sets goal, constraints, and what not to do"]
    subgraph CS["GitHub Codespace - disposable sandbox on Azure"]
        QUEEN["Hive queen agent
line-manager role"]
        CODER["Coder agent"]
        TESTER["Test-author agent"]
        RUNNER["Test-runner agent"]
        ARCH["Architect / researcher agents"]
        OPS["DevOps agent
Dockerfile, builds"]
        MEM[("Shared memory
and to-do lists")]
        QUEEN --- MEM
        CODER --- MEM
        TESTER --- MEM
        RUNNER --- MEM
        ARCH --- MEM
        OPS --- MEM
        RUNNER -->|"this test broke"| TESTER
        TESTER -->|"BDD scenarios"| CODER
    end
    DEV -->|"prompt: plan first, use BDD,
maintain context blocks, push when done"| QUEEN
    CODER -->|"commit"| REPO["GitHub repo
per Cockcroft, the only thing
the sandbox can commit to"]
    REPO -->|"inspect the result"| DEV

The second architecture worth recording is the house knowledge-graph system, because it is the one he set out to build to a deliberately high standard. It is a distributed portable MCP service: a Python server holding a knowledge graph of the entities in a house, including blobs such as photographs of devices and PDF manuals, plus a protocol and a client that lazily synchronise two copies of the graph.

flowchart LR
    subgraph HOME["In the house"]
        SRV["Python MCP server
knowledge graph + blobs
auth, rate limiting, audit logging"]
    end
    subgraph PHONE["Phone - works offline"]
        CLI["Client
full local copy of the graph"]
        APP["Native Swift app
weather, HomeKit, TTS, voice"]
        APP --- CLI
    end
    SRV -->|"lazy sync protocol
vector clocks, last-write-wins"| CLI
    CLI -->|"edits made offline sync back"| SRV
    GUEST["Guest"] -->|"QR code yields a token"| SRV
    SRV -->|"read-only access"| GUEST
    LLM["LLM client"] -->|"MCP"| SRV

The offline requirement is what forces the design, and his reason for it is pleasingly concrete: one of the things he wants recorded on the phone is how to get the Wi-Fi working again, which is useless if retrieving it requires Wi-Fi. Two copies means synchronisation, and he notes that the agent chose vector clocks and last-write-wins without being told to. The guest mode gives a visitor a read-only view of how to operate the house via a QR-code-issued token.

(Supplementary context, not from the talk: vector clocks are a way of tracking causality between replicas so that a system can distinguish "this update came after that one" from "these two updates happened concurrently and conflict". They detect conflicts; they do not resolve them, which is why a resolution policy such as last-write-wins sits alongside. It is a conventional choice for occasionally connected clients, which is presumably why a model trained on a lot of distributed-systems code reached for it.)

The Projects, Including The Failures

The house project is really a sequence of three attempts, and the first two are as instructive as the third. The motivating idea is what he calls consciousness as an observability model: you can only ask someone how they are and get an answer while they are conscious, so consciousness is what makes a person's internal state observable to you. Extending that, you could make a system more observable by giving it a consciousness layer you can interrogate. His house is the test case, because it has too many IoT devices for anyone to keep straight — he asks the audience whether they know what a Hayward Omni does (a swimming pool controller, with an icon that gives no clue), what Flair does (per-room air vents with their own thermostats), or what Ting is (a power monitor an insurer supplies to detect electrical fires). The knowledge graph exists to link a photo of the thermostat on the wall, the PDF of its manual, and the fact that it controls these four specific rooms.

Two details from the third attempt are worth carrying away. First, the security work happened because he asked a vague question: he said "do a security audit", and the agent proposed an OWASP Top 10 audit — a standard list of the most common web application security risks, which he says he had only vaguely heard of and had no idea how to conduct. It told him he needed better logging, and the result carries audit logging, rate limiting, and authentication. That is a genuinely useful pattern: the agent supplied the checklist he did not know to ask for. Second, he frames the house as an example rather than the point — the same shape applies to any large complicated system you operate where you would want a knowledge graph you can edit from your phone and have changes ripple back and forth.

(The project naming, for anyone reading the repos: Python is named after Monty Python, so his projects are named after singles released by the 1970s British comedy group The Goodies — Funky Gibbon, Inbetweenies.)

Alongside the house work he treats building an MCP server as the "Hello World" of LLM development — the simple repeatable exercise. Take any tool or body of knowledge, tell an agent to build an MCP server for it, attach the server to an agent, and it will work out how to use the thing. His own example is persona as a service: his content is available through Soopra as a chatbot he uses as a cheat sheet when podcast hosts send him questions in advance about Netflix fifteen years ago, and he had the same data turned into an MCP server so you can attach a local LLM to it instead. MeGPT is the generic version — a framework for turning any author's content into an MCP server.

He also uses LLMs well outside coding. As a product manager, he iterates on ideas in the ChatGPT and Claude mobile apps while walking around, then asks for the conversation to be written out as a file, saves it into a repo from his laptop, and tells an agent to build it. As a UX designer, he asked for a UX guide and got personas, onboarding flows, and considerable detail for his house-management domain — the code author, the house admin, a visitor who knows nothing, and a non-technical resident who just wants things to work. He says the output was very on point, and that he tweaked it only where he wanted something specific it had not come up with. A real UX person told him it was a plausible-looking structure, and his own explanation for why is the honest one: UX guides all follow the same structure, so as long as the domain makes general sense to the model it will produce plausible-sounding output. He also had it generate a human testing guide for the repo — what the thing does, what steps to run, what you should see — which he then ran himself and debugged where it was wrong.

The Nubank demo and an accidental benchmark

For advisory work at Nubank he wanted to demo agentic coding, so he built an MCP knowledge graph about Brazilian football. He asked Claude whether the data was obtainable, had it produce a guide document and example questions, saved that to a public repo, started a Codespace, and gave one command: implement the phases, test it using BDD, put block comments in it, push it all to GitHub. About an hour later it was done, backed by Neo4j — whose query syntax he says he can read but does not want to write. His assessment is that it did a reasonable job but was slower than he expected, because it ran one agent most of the time rather than parallelising. An incidental datapoint from the same demo: the slide backgrounds for the talk itself were generated with Canva's magic background feature, on the grounds that his slides look terrible otherwise.

That gave him a repeatable test. Starting from the same guide file and Neo4j setup as the first run on 30 September, he re-ran the task using Claude Flow's Hive mind mode instead of a plain swarm. Hive mind puts a queen agent in as a line manager, is supposed to be better coordinated, and uses more memory — enough that it can run out on a default-sized Codespace, for which his hint is simply to restart with more memory. It completed more quickly and the result looked better and seemed plausible. He intends to keep re-running it as a personal benchmark each time tooling changes, by analogy with the "draw me a pelican riding a bicycle" test people run against each new model.

Note what kind of evidence this is: a single re-run of one task, assessed by eye — his words are that it "looked better, seemed plausible" — with the tooling version and the prompt both changing over time. He presents it as a tracking exercise, not a controlled comparison, and it should not be read as a measured result for Hive mind over swarm.

The TypeScript-to-Python port, and where enterprise reality intervened

The last project is a large port. A stealth startup wanted a demo app built for fundraising; Cockcroft estimated a week or so of full-time work for one person, and recruited Chris Fregly over dinner by texting him to ask what he was up to. Fregly had just finished writing a 1,000-page book on how AI works — for which Cockcroft supplied a praise quote — and had the next couple of weeks free, so he took it on and built a fairly sophisticated app. It came out mostly in TypeScript, which Cockcroft did not want to maintain, so he told an agent to translate roughly 150,000 lines of JavaScript and TypeScript into Python. At the time of the talk it was around 80-90% through, had converted all the tests with most of them running, and the plan was to confirm it runs and delete the TypeScript.

The interesting part is the obstacle. The machine he had available was a Nubank laptop, locked down to sleep after three minutes and lock the screen, with the sleep setting unchangeable without following a YouTube workaround. His fix was to leave it playing a three-hour YouTube video overnight, screen dimmed and turned away, so Claude could keep working. He offers this as the reason enterprises will struggle with this style of development: agents have to be free to run when you are not looking at them, and standard corporate endpoint policy assumes the opposite.

Trade-offs And Limitations

The role model is a director's, and so are its blind spots. By his own account he does not read the code and does not watch what the agents do; what he does instead is verify afterwards whether they built what he wanted. The practices in this talk — BDD scenarios, the human testing guide, running the integration tests against a live database — are the substitutes for reading diffs. If you adopt the posture without the verification apparatus, you have kept the risk and dropped the control.

The nagging is a real, unbudgeted cost. His own "what's missing" section is about how much repetitive, mindless management he does: insisting on 100% of the tests passing rather than the 90% the agent keeps offering, telling it not to skip the bit that did not work, telling it to keep going until finished, telling it to archive old docs, reminding it to push to GitHub, sending it back to compare against the source again. The fifteen-minutes-per-several-days figure is generation time, not the elapsed time to a finished result — the tidy-first section makes that explicit, with an hour of generation followed by the rest of the day cleaning up.

Language and tooling opinions here are unmeasured preference. The Python-good, TypeScript-hairball assessment is what he has personally seen, with no benchmark behind it, and he says outright that he is not a Python programmer. Go he has only heard about. (My caution, not his: model performance by language is also a moving target that changes with each release, so a preference formed in one quarter may not survive the next — which is arguably his own argument about continuous experimentation turned back on his conclusions.)

Skipping permissions is only safe because of where it runs. Lifting the enthusiasm for the mode without lifting the disposable Codespace around it is the mistake this section exists to prevent; see the supplementary note above on what the sandbox does and does not bound.

Everything organisational is projection. The five-to-seven-year timeline for enterprises, the headcount shift from application to platform development, the platform emerging "organically probably in the next few months", and the AI-native process itself are all Cockcroft's forecasts, offered as such. The one piece of supporting evidence he gives for enterprise difficulty is his own laptop.

The benchmark and the carbon numbers are arm-waving by his own admission. The Hive-mind comparison is caveated above. The carbon figures are not his own derivation: they came out of a long conversation with ChatGPT, which he judged plausible against his own background of working on sustainability — which makes them an LLM estimate sanity-checked by a knowledgeable reader rather than an independent calculation. The argument runs: a US developer has a footprint of about 20 tonnes a year, varying mostly with how many international flights you take, which he converts to about 10 kg of CO2 per hour; a human produces on the order of 1,000 tokens an hour on a good day, derived from vague estimates about lines of code; Claude produces roughly a million tokens an hour. He states that even assuming the model is ten times less efficient than his estimate, it comes out 5,000 times better, and adds that most of the model's tokens are wasted rereading things — before conceding he is not sure how efficiently human tokens work either. His actual claim is deliberately loose: the numbers are so far apart that whether it is 100x, 1,000x, or a millionfold does not matter, and developing code with AI uses less carbon than developing it with humans. He is careful to scope it to developing the code; running it is a separate question. (My observation, not his: the intermediate multipliers he quotes do not reconstruct cleanly from the inputs he gives, which is consistent with his framing that this is back-of-envelope. It also treats a developer's whole-life footprint, flights included, as attributable to their coding hours — a framing worth questioning before repeating the conclusion.)

Parallel agents need architectural separation to pay off. Separate repos with stable APIs are not free: they cost versioning, integration testing across boundaries, and deployment coordination. It is the microservices bargain he explicitly invokes, with the same downsides, and he offers no mechanism for managing it beyond doing it manually.

Practical Takeaways

1. Write behaviours, not assertions. Express tests as given/when/then in domain terms, run them first against mocked backends and then end-to-end against a live system, and treat the accumulated scenarios as the spec that makes the implementation replaceable.
2. Make every source file carry its own summary. Instruct the agent to maintain a block comment describing purpose, APIs, and version history, and to update it on every change, so context survives session boundaries and tool switches.
3. Budget cleanup time explicitly. Plan for generation to be the short part and tidying — tests, warnings, stray docs, archiving — to be the long part, and compare against writing it yourself rather than against zero.
4. Point agents at your existing code as reviewers. Reviewing is where they are strongest relative to authoring, and it costs one prompt to find the oversized file or the accidentally quadratic loop.
5. Constrain before you delegate. Ask for a plan and explicitly forbid building until you have read it; scope each run small enough that it cannot produce a ball of mud.
6. Give unattended agents a disposable sandbox before you turn off permission prompts. A cloud dev container holding nothing but the repo is the enabling condition for the whole workflow, not an optional extra.
7. Split work across repos with stable interfaces, one per agent team. Concurrency at agent speed breaks down without physical separation.
8. Build an MCP server as your first exercise, wrapping a tool or a body of knowledge you already have, then attach it to an agent.
9. Ask for the checklist you do not know exists. A vague "do a security audit" surfaced OWASP Top 10 and produced audit logging, rate limiting, and authentication for someone who could not have specified any of it.
10. Keep a task you re-run as tooling changes, so you have your own evidence about whether the monthly upgrade actually helps you.
11. Check that your endpoint policy permits unattended runs before planning around them; the three-minute sleep timer is a more realistic blocker than model capability.

Key Terms

• NoOps — Netflix's controversial label for developers no longer needing to route requests for infrastructure through an Ops team; Cockcroft stresses it meant Ops left the critical path, not that Ops disappeared.
• AI-native development — Cockcroft's proposed successor to cloud-native: an organisational structure and platform in which agents do most application development and human engineers build and manage the platform that directs them.
• BDD (behaviour-driven development) — Specifying tests as given/when/then scenarios in domain language rather than as implementation-level assertions.
• Context block — A maintained 100-200 line block comment at the top of a source file recording what the code does, its APIs, and its version history.
• MCP (Model Context Protocol) — A protocol for exposing tools and data to LLM clients. In Claude Flow it is also what specialises each agent into a role.
• Claude Flow — Reuven Cohen's agent framework that spawns role-specialised Claude instances coordinating through shared memory and to-do lists.
• Hive mind — A Claude Flow mode that adds a "queen" line-manager agent for tighter coordination, at a higher memory cost than a plain swarm.
• Shared context pollution — One agent holding too many concerns at once, which Cockcroft says leads it to fake results, work around problems, or confuse itself; role separation is the countermeasure.
• Dangerously-skip-permissions / YOLO mode — Running an agent without per-action confirmation prompts, intended for a sandbox.
• GitHub Codespaces — Cloud development containers holding a checkout of your repo, used here as the disposable environment for unattended agent runs.
• OWASP Top 10 — A widely used list of the most common web application security risks, which the agent proposed and audited against when asked for a generic security review.
• Vector clocks — A mechanism for tracking causality between replicas so concurrent conflicting updates can be detected; chosen unprompted by the agent for the knowledge-graph sync protocol.
• Consciousness as an observability model — Cockcroft's framing that a system becomes observable by exposing an interrogable layer describing its own internal state, by analogy with only being able to ask a conscious person how they are.

Cockcroft closes on what he still wants: a director agent that does the nagging for him, and more broadly a systemic platform for managing agent development that breaks down tasks, enforces guardrails and policies, and automates development management away — NoOps, then no devs, then, as he puts it, "no man". Whether or not that arrives, the through-line of the talk is the useful part. Every practice he recommends is a way of moving human judgement earlier and higher: into the plan you approve before code exists, into the behaviours that define correctness, into the context block that survives the session, and into the sandbox that bounds what a mistake can cost. That is what directing looks like when the team works a thousand times faster than you can read.

Reference: Adrian Cockcroft, Directing a Swarm of Agents for Fun and Profit, QCon San Francisco 2025, published by InfoQ. Presentation length 45:58; notes based on the full published transcript, which contains no audience Q&A section. Cockcroft publishes his slides and the links referenced in the talk at github.com/adrianco/slides.