Coding for Algernon

Flowers for Algernon is a 1966 novel by Daniel Keyes in which Charlie Gordon, a man with an intellectual disability, undergoes experimental surgery that dramatically raises his intelligence, only to watch that intelligence fade as the experiment fails and he returns to who he was before. The cruelty of the story is not the regression itself. It is that Charlie, unlike Algernon the mouse, is aware of what he is losing as it leaves him.

The Flowers for Algernon Problem

Charlie Gordon, before the surgery, did not know what he was missing. After the surgery, he knew exactly. And then the regression came, and knowing what you had lost was the cruelest part of the experiment. That is where I am standing right now.

I spent the last few weeks learning a genuinely new way to build and operate software. I mean new in the structural sense, not the marketing sense. Tools like Gas City, Beads, and Claude Code CLI compose into something that does not look like any prior engineering workflow. It looks like coordination. Multi-agent teams with explicit roles, versioned memory via Dolt, formulas that encode repeatable workflows as first-class objects. You are not writing code faster. You are managing a crew that writes and operates the system while you shepherd intent and catch mistakes.

For SRE work specifically, the implications are significant. Incident triage, runbook execution, log analysis, infra state validation, cross-service correlation, these are workflows that are deeply repetitive, cognitively expensive, and highly suited to multi-agent execution. A Gas City pack for on-call SRE work does not replace the engineer. It gives the engineer a team of agents watching the instruments so that the engineer can focus on decisions, not discovery. That is a different relationship with operational work than anything I have seen in ten years of building infrastructure.

The local model story is particularly compelling for regulated environments. Open-weight models served locally through Ollama give you bounded, low-stakes inference with no data leaving the network. Smaller context windows, faster response, cost profiles that make team-level experimentation tractable. For SRE workflows where the inputs are log lines and infrastructure state rather than sensitive customer data, the risk surface is genuinely manageable. The architecture is sound.

What is not always sound is the organization’s ability to evaluate it. I was engaged with a client team that had built a promising proof of concept along exactly those lines, local Ollama serving a small Gas Town instance doing first-pass incident triage. The work was contained, well-documented, and running on isolated infrastructure. Then their endpoint management platform flagged Ollama as unauthorized software and silently removed it across the fleet. No ticket, no conversation, no policy document explaining what threat was being mitigated. The engineers found out when their workflows stopped responding.

What Organizational Immune Systems Actually Protect

I have seen this pattern enough times to recognize it for what it is.

The decision to remove local development tooling in that situation was not made by someone who evaluated the threat model of Ollama and concluded it was too risky. That kind of analysis produces a written rationale, a policy, an alternative path, and usually a conversation. What happened instead was an endpoint management rule treating any uncatalogued software as hostile, which is the signature of an organizational immune system doing what immune systems do: neutralizing foreign material before anyone has to think carefully about it.

The accompanying position the team received, that local development was not viable at all, deserves scrutiny. Local development of what, for whom, at what risk level? The blanket claim is not a security posture. It is a sentence that ends the conversation without starting it, and that is its actual function.

Organizations that have made real security decisions can explain them. They can point to the threat they are mitigating, the data they are protecting, and the boundary conditions of the policy. They can reference a risk register entry. What they cannot do is produce the silent automated uninstall followed by a vague assertion that local development is categorically unworkable. That is institutional defensiveness, not risk management.

The Luddites, as a historical matter, were skilled textile workers who understood their trade and made a rational economic argument that automation was destroying their livelihoods. They were wrong about the solution, but they had a coherent position. What I am dealing with is something less coherent: reflexive resistance dressed up in the language of governance, applied by people who have not looked at what the tooling actually does.

The Asymmetry of Understanding

Here is what makes the Flowers for Algernon analogy precise rather than melodramatic.

Before I worked through the Gas City stack, before I got deep enough into the Beads framework to see what a versioned, git-backed, multi-agent workflow actually looks like in practice, I could not have articulated what was missing from the way I was working. I did not know the ceiling existed. I just worked inside it.

Now I know the ceiling exists. I can describe specifically what is above it. I can point to the concrete SRE workflows that would benefit, the specific reduction in toil, the auditability that a Dolt-backed operation history provides, which is frankly better forensics than most organizations have today. I can make the case with specificity. And I am making it to people who, through no particular fault of their own, have not been through that same learning.

The regression Charlie experienced was chemical and involuntary. What my client experienced was organizational and deliberate. But the epistemic gap is structurally identical. The person who has seen the other side of the capability curve cannot unknow it. The people making the tooling decisions have not seen it. That asymmetry of understanding is the actual problem, and the automated uninstall is just its most visible symptom.

What I Am Going to Do About It

I am not writing this post to complain. I am writing it because I think a significant number of engineers are either about to have this experience or are currently living through it, and the path forward is not obvious when you are in the middle of it.

The first thing I intend to do is make the learning accessible. The multi-agent engineering model is genuinely unfamiliar to most organizations because it requires building up through several levels of AI adoption before it becomes coherent. Yegge’s adoption curve is useful here: you do not understand what a deployed agent pack is until you have built and run single-agent workflows, failed in the right ways, and developed intuitions about where human oversight is essential. Most organizations are at levels three or four on that curve and are being asked to develop governance for levels nine through eleven. The mismatch produces exactly the kind of reflexive endpoint policy that killed my client’s proof of concept.

I want to help SRE practitioners specifically work through that adoption path at levels that do not require fighting organizational policy. You can do meaningful multi-agent SRE work with models you have API access to. You can build formulas for incident workflows, deploy small crews for log analysis, and use Claude Code CLI for bounded infrastructure tasks without running anything locally. The local model story is compelling, especially for perimeter-sensitive environments, and it is worth continuing to make that case to clients who have the constraint. But the absence of Ollama does not close the door entirely. It narrows it.

The second thing I intend to do is build the organizational case with actual evidence rather than enthusiasm. I have enthusiasm. Enthusiasm without evidence is exactly the kind of signal that triggers institutional immune responses. What I need is a documented pilot with measurable outcomes: time to resolution, context switches per incident, toil hours per sprint. Those numbers, run against a real workflow, are a more persuasive argument than anything I can write here.

The Broader Diagnosis

The organizations that will build durable capability in this era are not the ones with the loosest governance. They are the ones with governance structures that can distinguish between a real risk and a familiar-sounding risk that has not been analyzed. Silent uninstalls and blanket local-development bans are not security postures. They are latency in the system, time between when the world changes and when the organization adjusts.

Charlie Gordon’s tragedy was that he could not control the biology. The engineers in that situation can control the strategy. The regression is real, but it is not permanent. The ceiling exists, and knowing where it is, and being able to describe what is above it with specificity, is most of the work.

The rest is time, evidence, and the right conversation with the right person.