A single LLM answer has a neat, confident shape. Public opinion does not.

When a policy changes, a product launches, or a company announces something unpopular, the interesting part is rarely the first reaction. It is what happens after people see each other reacting. Arguments harden. Coalitions form. A practical objection becomes the sentence everyone repeats. A weak point disappears because nobody picks it up.

That is hard to study with one prompt.

After a long string of 0.0.x releases, Phero finally reaches v1.0.0.

We made it to 1.0.0

There’s a particular feeling that comes with cutting a 1.0.0 tag. The 0.0.x versions are a workshop: you tear walls down, you move the staircase, you sleep on it and rebuild it the next morning. 1.0.0 is the moment you finally open the door and say: this is ready, and I stand behind it.

Now that anyone can build the prototype, the rarest skill is knowing which prototypes deserve to live.

In two previous articles I argued that AI does the easy 20% of software, writing code, and leaves the hard 80% untouched. The first traced the pattern back forty years, the second catalogued the 80% in nine parts a demo never shows. Both pieces did the same thing: they pointed a finger. At the PM who builds something in an afternoon and declares engineering obsolete. At the leap from “it works in the demo” to “we don’t need them anymore.”

A working demo is a promise the system hasn’t agreed to keep yet.

In a previous article I argued that writing code is, by Pareto, about 20% of the job, and that the other 80% is the part AI doesn’t replace. I listed that 80% as a string of bullet points and moved on. That was a cheat. Those bullet points are the whole argument, and they deserve more than a list.

Every builder reaches a moment when they start to suspect their own work.

Mine came while I was adding yet another example to phero, my Go framework for multi-agent AI systems. The example looked clean. The code was elegant. The abstractions composed nicely. But there was a question I kept circling: was any of this actually modular, or had I just written boilerplate that I was too close to see?

Every decade, like clockwork, someone announces that developers are finished. The script never changes. A new technology promises to make the programmer redundant. Someone writes a triumphalist article. Decision-makers start dreaming about better margins.

Four times before

The 1980s: fourth-generation languages

4GLs promised the end of traditional programming. The finance manager would write his own reports. The sales analyst would build her own dashboard. For a while it worked, as long as the systems stayed small. Then the data grew, requirements got messier, performance began to degrade. In the end, developers were called in to rewrite everything in general-purpose languages.

Synadia published the NATS Agent Protocol last week and the core idea is blunt: AI agents are already deployed everywhere (IDE, CI, support queue, factory floor) and none of them were built to talk to each other. The model isn’t the bottleneck anymore. Coordinating the fleet you’ve already deployed is.

Their answer is a wire spec, not a framework. Two pages of contract on top of NATS micro services. An agent is a NATS service named agents with three endpoints: prompt, status, and hb. Discovery is one round-trip: nats req '$SRV.INFO.agents'. Multi-tenancy, cloud-to-edge, audit trail: all inherited from NATS, none of it written twice.

Most multi-agent examples run agents sequentially. One agent produces output, the next consumes it, and so on down the chain. This is easy to reason about but leaves performance on the table. If you need multiple independent perspectives on the same topic, there is no reason to wait for the first agent before starting the second.

The fan-out / fan-in pattern fixes this. Multiple worker agents run concurrently, each exploring the same topic from a different angle. When all workers finish, a synthesizer merges the findings into a single coherent report. The concurrency is handled by Go’s native primitives—goroutines and sync.WaitGroup—with no new framework machinery required.

Most multi-agent examples keep agents isolated. Each one gets a prompt, produces output, and hands it to the next step. That works when the data flows in one direction. But some workflows need agents to build on each other’s work incrementally, reading and writing to a shared context. This is the blackboard pattern.

The idea comes from AI research in the 1970s. Multiple knowledge sources (agents) read from and write to a shared data structure (the blackboard). A control component (the supervisor) decides which agent to activate next. Each agent contributes partial results that other agents can use. The blackboard accumulates context over time.

Ask an LLM to write something once and you get a first draft. Ask it to revise based on specific feedback and the second draft is measurably better. This isn’t surprising. It’s how human writing works too. What’s interesting is that you can automate both sides: one agent writes, another evaluates, and a Go loop connects them.

This is the evaluator-optimizer pattern, described in Anthropic’s Building effective agents guide. A generator produces output. An evaluator scores it and gives feedback. If the score is below a threshold, the generator revises. The loop continues until the output is good enough or you run out of attempts.