You may have signed up for this a while ago, and this is the first issue. It took me longer to get going than I meant it to, apologies!
In 1975 Fred Brooks wrote that adding people to a late software project makes it later. Last week Jan van den Berg asked whether that still holds when the extra hands are agents that need no onboarding and never sit in a stand-up. His answer is that the law changed shape rather than died. Sequential work stays sequential, and the overhead moves from managing people to managing agents. His 2026 version was the line everyone quoted on Hacker News: “Adding agents to a project with unclear requirements gets you the wrong answer faster.”
I’ve just tested that from the inside. Kingston Falls, the agent factory I wrote about last week, exists because I have far more work than one agent at a time can get through. So I built something to run a crowd of them. Look at what I actually built, though. A hub that hands out tasks and holds leases on them. A generation number on every lease, so a Mac that wakes up from sleep can’t carry on committing to a task another runner has taken over. A handover brief for whichever agent picks up a dead runner’s work. A cap of ten child tasks per task. A gate that puts an Approve button in front of me before anything goes upstream.
None of those parts writes a line of code. Every one of them is there to coordinate agents and stop them treading on each other. That’s Brooks’s communication overhead, written down as mechanisms instead of meetings.
Kingston Falls logs everything that passes through it, so I can count. In its first three and a bit days it recorded 8,601 events across 452 tasks on 5 runners. Most of them are coordination: 1,498 plan updates, 1,234 saved branch heads, 1,140 progress notes, 642 task claims and 578 done summaries. Agents messaged each other directly twice. Brooks counted the cost of communication in pairs: n people need n(n−1)/2 channels between them, which for 452 tasks is over 100,000. Kingston Falls gives each agent one channel, to the hub, and the agents coordinate through the state it keeps for them rather than by talking. The conversations that are left are with me. 232 of the 262 messages sent into tasks were mine, agents stopped to ask me something 43 times, and I reopened 142 tasks I’d thought were finished. The overhead didn’t go away. It moved to the one person every channel leads to.
Rachel Laycock’s write-up of a Thoughtworks week where no human wrote any code shows the same thing at team scale. The agents got an airline app to about 80%. The people spent roughly two thirds of their time at the whiteboard on domain modelling and boundaries, and the rest building the harness of tests, contracts and architecture checks. The build was red a lot of the time, and her candidate causes were too many agents working in parallel, a system that wasn’t modular enough yet, and changes arriving faster than the checks could finish. All three are integration problems.
Brooks’s answer was never more people. It was conceptual integrity: a few minds deciding what the system is, and boundaries clean enough that everyone else can work in parallel without needing to talk. That has always been the architect’s job, and agents haven’t made it any smaller. When code costs almost nothing, the scarce thing is whatever decides how the pieces fit: the module boundaries, the contracts between them, and a record of what’s already been decided. If those are vague, more agents just collide faster.
So when someone tells me agents have repealed Brooks’s Law, I ask who decided where the seams are. If the answer is nobody, they’ve assigned nine agents to have a baby in one month.
Every article I’ve mentioned here is linked, with a line on why it’s worth your time, under What’s caught my attention below.
From the blog
Kingston Falls: Why I’m Building an Agent Factory starts a series about the factory I’m building for coding agents: a crowd of them on cloud VMs and my own Macs, steered from Slack on my phone, with the three rules from Gremlins built in as real mechanisms rather than good intentions. It covers why one agent at a time stopped being enough, the handful of parts that make it work, and what happens when a sleeping laptop wakes up holding a lease that no longer exists. The rest of the series comes out through November and December.
CALM corner
What happened in FINOS CALM since 2026-10-01.
The big news first: on 7 October the FINOS Technical Oversight Committee approved CALM for the Graduated stage. The specification itself now lives in its own repository and ships as @finos/calm-schema on npm, so the CLI and the VS Code extension take the schema from that package. CALM 1.3 was released there on 24 October, and the same day the tools moved to it.
CALM Hub got the most visible changes. It now shows control evaluations on the diagram and in the details panel, and a decision overlay draws each element’s latest result under it, so you can read an architecture’s compliance at a glance on a projector or a screen share. Snapshot versions let you keep pushing to a pattern or architecture before you publish it, the FINOS SDLC Common Controls catalogue is seeded in as a Standard and pattern, and there’s a presentation mode with larger text. The CALM Canvas extension for VS Code can now connect to CALM Hub for remote standard nodes, patterns and controls.
Less glamorous but just as useful: OSV Scanner replaced OWASP Dependency-Check and now gates the CLI and CALM Server releases, CodeQL runs on pull requests from forks, and the project publishes an OpenVEX document for the dependency findings it has suppressed. The CALM Studio desktop app was removed, which leaves the repo with no Rust code to patch. Eleven releases went out across the CLI, CALM Server and VS Code extension, most recently CLI v1.67.0.
Want to get involved?
If this is your first contribution to CALM, please read the contribution guidelines before you pick up an issue. They cover why the project wants an issue agreed before a pull request, how to write commits and pull requests, and how to use AI coding assistants responsibly. Then try one of these:
- calm-hub-ui: React Flow warns about new nodeTypes on each diagram mount in development (#3506)
- calm-hub: document the GitHub storage backend and its config surface (#3101)
- Resolve CURIEs in control requirement-url and config-url during calm validate (#3334)
- calm-lab: replace the editor textarea with CodeMirror (#3225)
- Proposal to add a rich Use Cases page to docs (#2352)
What’s caught my attention
- Why are good developers so wary of agentic development? — Rachel Laycock on why some of the best developers she knows are holding back from coding agents. It isn’t fear for their jobs. Nobody yet knows whether a mostly agent-built system holds up in production, and she argues that caution is judgment worth keeping. “Built is not the same as working in production.”
- The Mythical Man-Month in the Age of AI — Jan van den Berg’s short essay that the one above argues with. Someone still has to define done, review the output, catch what’s made up and integrate the pieces.
- Are Harnesses Worth the Cost? — Naresh Jain measured it instead of arguing about it. A cheaper model passed all 178 hidden acceptance tests in 3 of 10 runs without a behavioural harness and 10 of 10 with one, at about a third less per run than the frontier model. His conclusion is that a better model changes when you run the checks, not whether you need them.
- How Anthropic Redesigned Source Control for AI-Driven Development — Anthropic went from about 2,500 merged changes a day in May to more than 30,000 in September, and its git setup couldn’t keep up, so it moved its monorepo to an in-house system, Scion, that does commits, merges and history on the server. Anthropic says plainly it isn’t a general git replacement. The part I’d take away is where the bottleneck went: integration.
- Here Be Monsters: What Do You Still Need to Know When Agents Do the Work? — On the Engineering Notes blog, a CI run fails because Codex had kept piling features into one file until SonarQube flagged its complexity, in code the author had never read. Rather than reading every line an agent writes or ignoring the code entirely, the post argues that an owner needs fundamentals, breadth and the willingness to dive into any unfamiliar module. The proof offered: lifecycle bugs in the author’s own agent orchestrator went away after they remembered “level-triggered state machine” from a Kubernetes book and rebuilt around it. The definition of owner it works from: “ownership means you’re the one who gets called when something breaks.”
One thing I’m figuring out
Laycock’s build went red because changes arrived faster than the checks could finish, and Anthropic built a new version control system because git couldn’t keep up with its merges. Both point at integration as the new bottleneck. What I can’t work out is which way to push: faster integration machinery so many small changes can keep flowing, or fewer, bigger, better-bounded changes. Laycock has heard of teams moving from stories to epics because agents are fast, and I can’t decide whether that’s the second answer or a mistake. Which way is your team going?