After a long string of 0.0.x releases, Phero finally reaches v1.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.
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.