The Articulation Problem
Coding is a solved problem now. Not perfectly solved โ edge cases remain, context windows have limits, agents still hallucinate โ but solved enough that the bottleneck has moved. The limiting factor in building software is no longer writing code. It's knowing what you want.
This is the articulation problem. You can spin up a swarm of agents that will produce a million lines of code in a weekend, but those million lines will be an approximation of your vision, not a realization of it. The agents made thousands of micro-decisions along the way. Some matched what you would have chosen. Many didn't. You'll know the moment you see it โ and then wonder how many downstream decisions cascaded from that wrong turn, and how hard they'll be to unwind.
I ran Gastown for a day or two before a recent vacation. It burned through usage hard and got a lot done โ well-implemented subsystems, reasonable architecture, code that mostly worked. But the subsystems didn't cohere. Loose ends everywhere. Features that made sense in isolation but didn't wire together into the product I had in my head. Even after multiple passes of spec refinement, multi-agent team dialog, and careful planning, spec writing, and review until Claude(s) and I converged, the result was still a nice approximation of what I wanted.
The problem isn't the swarm. The problem is that I couldn't articulate every detail upfront, because I didn't know every detail upfront. Nobody does for non-trivial projects. Requirements emerge through building and testing. You discover what you actually want when you see the wrong thing take shape.
Agile teams solve this through continuous feedback loops. Standups surface blockers. Sprint reviews demo progress. The product owner sits with the team, available for the hundred small decisions that don't merit a meeting but shape the product anyway. The human with the vision stays close to the work.
Swarms don't have this. They're more like an external consultancy โ you hand over a spec, they disappear into a room, and they return with a deliverable. A good consultancy asks clarifying questions, schedules milestone demos, surfaces decision points before committing. Current swarms mostly just... steamroll forward, making educated guesses where the spec was ambiguous. Granted, the cost of an agent building the wrong thing is a fraction of what it would be with a human consultancy โ you can throw it away and try again without the expense and timeline impact. But should that inefficiency be acceptable? Surely we can do better than "cheap enough to redo."
This is the gap. Not in capability โ swarms can build. The gap is in collaboration. We need swarms that pause on ambiguity instead of guessing. That surface discovery items to stakeholders asynchronously rather than blocking on synchronous approval. That treat unclear requirements as escalation triggers, not creative opportunities.
The consultancy metaphor is useful because it clarifies what we're missing. When you hire a good agency, you don't expect to hand them a napkin sketch and receive a finished product. You expect a relationship โ regular check-ins, shared artifacts, collaborative refinement. The agency brings execution capability; you bring vision and judgment. Neither can do the other's job.
That's what working with swarms should feel like. Not fire-and-forget autonomous coding, but a collaboration where the swarm moves fast on what's clear and pauses to ask about what isn't. The technology for this exists. The patterns don't โ yet.
For now, the articulation problem is our problem. We can't outsource knowing what we want.