Chapter 10: Bet on Plain English

Sony introduced Betamax in Japan on 10 May 1975.^[1] It was, by the measures engineers care about, the better format. At its original speed it resolved around 250 horizontal lines against about 240 for VHS, with less noise and crosstalk.^[2] It also had a problem that had nothing to do with picture quality. Early Beta tapes held sixty minutes, which made them impractical for films and sport, the things people actually wanted to record.^[1]

JVC’s VHS arrived the following year with a standard mode that ran for two hours.^[2] JVC licensed the format broadly, which brought in a crowd of manufacturers competing on price; Sony initially resisted licensing Beta, which limited how far it could reach.^[1] By 1980 VHS had 60% of the North American market. By 1987 it had 90% of the US market.^[2] In 1988 Sony agreed to add VHS machines to its own line-up, widely read as surrender.^[1]

The economist W. Brian Arthur showed how an early lead in adoption compounds. When each new user makes a technology more useful to the next (more tapes in the rental shop, more machines in friends' houses), a market can settle on one option through small, almost accidental choices, and stay there even if the other was technically better.^[3] He called the end state lock-in. Keep the word in mind; Chapter 11 borrows it.

Quality matters, but adoption is decided by the many people who want to do an ordinary job easily, not by the few who can appreciate the specification. Betamax was the better format for an engineer. VHS was the better format for a family who wanted to record the match.

The same pattern played out on the web twenty years later. In 1994 Rasmus Lerdorf wrote a handful of small programs to track visits to his online CV. He called them "Personal Home Page Tools." In June 1995 he released the source code so that other developers could "use it as they saw fit," which also encouraged them to fix its bugs and improve it.^[4] PHP was never elegant. Professionals mocked it for two decades.

ColdFusion launched a month later, on 2 July 1995, built by the brothers Joseph and Jeremy Allaire.^[5] To be fair to it, ColdFusion was simple too. Its tags looked like HTML, which made it friendly to the designers who were building the early web. But it was a commercial, proprietary product, later sold to Macromedia and then Adobe.^[5]

Today PHP runs 69.1% of the websites whose server-side language can be detected. ColdFusion runs 0.2%.^[6] WordPress, written in PHP, alone powers 39.5% of all websites.^[7]

Simplicity alone wasn’t enough. ColdFusion had a gatekeeper: someone had to buy it. PHP was simple, expressive and free to anyone who wanted to try it on a Tuesday afternoon. What wins is easy to start, powerful enough to keep going, and owned by nobody who can say no.

Richard Gabriel, a computer scientist, named the pattern around 1990: "worse is better." Systems that put simplicity first, he argued, have "better survival characteristics than the-right-thing," and spread from one user to the next "like a virus."^[8]

In January 2023 Andrej Karpathy, a founding member of OpenAI, posted a line that went round the industry: "The hottest new programming language is English."^[9] Three years later it describes how CorralData works. Consider what English has going for it as the format for your organisation’s instructions:

Even guardrails can start as English. I noted with some surprise that Grok Bot’s permissions were "a list of plaintext directives… rather than a cleanly structured relational model." An older generation of engineers would wince, but non-engineers could read and change it. One of our engineers summed up where this leaves the industry: an agent is "an LLM, running in a loop, calling tools… the company with best/easiest UX/UI will win." The easiest interface ever devised is the language people already speak.

The instinct to reach for structure is a good one, misapplied. Leaders know that undocumented processes fail, so when agents arrive they want boxes, arrows, a canvas you can show the board. But a diagram fixes the one thing that ought to stay loose, the route, and says little about what ought to be fixed: the outcome, the standard and the reasons.

CorralData’s most structured experiment was a pipeline called Glass Factory, which used our ticket tracker as its interface and defined its roles in detailed operating guides. It was behind the worst failure in this book (Chapter 14), and by November it had gone quiet. What survived was the idea. "Glass factory mode" (the agent drafts, the team corrects, the corrections feed back, and autonomy expands as the work proves reliable) became the theme of a LinkedIn post by our CEO. The idea could be said in a sentence, so it travelled. The code could not, so it didn’t.

CorralData is not alone. On 3 June 2026 OpenAI told developers that Agent Builder, its drag-and-drop canvas for designing agents, was being deprecated, with shutdown scheduled for 30 November 2026. Its deprecation notice points users to a migration guide for continuing with its Agents SDK, which is code, or with ChatGPT Workspace Agents.^[10] OpenAI gave no reason, and I won’t invent one. But notice where users were sent: towards code for precision, and towards a conversational product for everyone else. The canvas in the middle was what went.

Agent builders agree. Reviewing the teams it had worked with, Anthropic found that "the most successful implementations weren’t using complex frameworks or specialized libraries." Its advice was to find "the simplest solution possible, and only increasing complexity when needed," and it warned that frameworks "create extra layers of abstraction that can obscure the underlying prompts."^[11] LangChain, which makes a framework, gives the same advice: "Start with a single agent and good prompt engineering."^[12] Prompt engineering is a technical name for writing clear English.

To be fair to the builders, n8n now describes itself as a platform for "agents and workflows you can follow."^[13] For stable, high-volume integration between two systems, a diagram is fine. But that is plumbing. It is not how you tell a role what it is for.

In March 2019 Rich Sutton, one of the founders of reinforcement learning, published a short essay that has become the closest thing the AI field has to a creed. "The biggest lesson that can be read from 70 years of AI research," he wrote, "is that general methods that leverage computation are ultimately the most effective, and by a large margin."^[14] Chess, Go, speech recognition and computer vision had all followed the same arc. Researchers built their own understanding of the problem into their systems, which helped for a while and was "personally satisfying to the researcher." Then it plateaued, and the clever, hand-built methods were swept away by simpler ones that let computation do the work. "We have to learn the bitter lesson that building in how we think we think does not work in the long run."^[14]

Sutton was writing about researchers, but every leader will recognise the failure. The manager who writes a twelve-step procedure for a capable new hire is building in how they think they think. It helps on day one. By month three it holds the hire back, because the hire has found a better route and the procedure forbids it.

I posted Sutton’s essay to our #ai-related channel on 29 October 2026 because I had watched it happen at CorralData. AskCorral, our analytics assistant, was first built in the GPT-3 era, wrapped in scaffolding to make up for what the model couldn’t do. We "stripped… out again when models got better." My conclusion for the team was that we should "not be afraid to turn things over to the models to brute force." A few days later I added that getting "too specific with directions" holds you back. The same day, one of our engineers let an agent loop seven rounds on a single high-level instruction, and I noted that the human was "more useful to make sure it is building the right thing" than to steer each step. Months earlier, another engineer had come back from a talk by the Claude Code team with a line in his notes: "Never bet against the model."

The people who build agent systems have reached the same conclusion. Prithvi Rajasekaran at Anthropic put it in one sentence: "every component in a harness encodes an assumption about what the model can’t do on its own." When a newer model arrived, his team removed the part of their system that broke work into sprints, and recommended meeting every new model by stripping away "pieces that are no longer load-bearing."^[15] Browser Use, which builds agents that operate web browsers, replaced thousands of lines of engineered wrappers with about 600, reasoning that the model had already read about the browser’s controls millions of times: "It already knows what to do." Their rule: "Don’t wrap the LLM. Don’t wrap its tools either."^[16]

Anthropic’s own guide to Claude Code now carries a table titled "What you can stop doing," listing once-sound advice such as shouting at the model in capital letters. "Most were workarounds for something the model couldn’t reliably do yet, and the models have since caught up."^[17]

A workflow diagram is a harness drawn in boxes. Every branch is an assumption that the occupant can’t be trusted to choose the route, and most will be wrong within a year. A paragraph that states the outcome, the reasons and the limits makes no assumption about the route, so it gets better every time the model does. Chapter 8 made this argument for briefs. It holds just as strongly for the standing documents that tell a role how its work gets done.

If a playbook isn’t a program, what is it? Anthropic’s answer, in the post that introduced its Agent Skills, is the best I have found: "Building a skill for an agent is like putting together an onboarding guide for a new hire."^[18] A skill is a folder with a plain-English document at its heart, and since December 2025 an open standard that works with agents from different vendors.^[18]

That framing changes what you write. A program tells a machine what to do, in order, without explanation. An onboarding guide tells an intelligent adult what the job is for, what good looks like, which judgment calls come up and how to make them, and what to do when stuck.

It also means the same document serves a person and an agent, which is the point. A role outlives its occupant (Chapter 5). A playbook only a machine can follow can’t be handed to a person on the day the agent fails, and the reverse is true too. Plain English is the one format that works for both.

At CorralData the clearest proof was TAM Bot’s arrival in #tech-general, onboarded in public "with no initial training other than 'join Slack'." The Agentic Resources Bot interviewed it and drafted its Role Charter (Chapter 9). What made it work was English written by people who weren’t thinking about TAM Bot at all: channel descriptions, team rules, earlier decisions. The organisation’s written English was the onboarding.

Writing a good playbook is mostly writing good English. Orwell’s 1946 rules still serve: never use a long word where a short one will do, and "if it is possible to cut a word out, always cut it out."^[19] Open with what the work is for, then what done looks like, then the judgment calls and their reasons, then the traps. Steps belong only where order genuinely matters.

The strongest test of plain English is whether it can carry policy: not just "here is how we write a customer update," but "here is what you are and aren’t allowed to do." At CorralData it can, and the story is one of two leaders disagreeing in good faith.

On 1 October our CEO pushed hard for non-engineers to be able to propose changes to our product’s code directly, with their agents' help. His frustration was real and, as it turned out, largely right: "it’s months of wait for something robots say is low effort and low risk." I pushed back: "it will not be an accelerant to have a bunch of people submitting PRs they have not tested and do not understand." We were both describing a real cost. He saw the queue; I saw the review load that would land on our engineers.

The resolution was not a workflow or a permissions system. On 8 October I added an agreement step to our code-review playbook: a few lines of English that any reviewing agent would follow. When agents kept opening changes the rule didn’t allow, the fix was to give them the same written rule. On 4 November, after a month of evidence, I wrote: "I think the bar has moved." On 5 November we replaced the gate with a tiered rule in the same playbook: "Size now sets the evidence a PR needs, not whether it is allowed."

Changing company policy took no engineering ticket and no release. The policy lived in a paragraph every agent read; when the evidence changed, so did the paragraph. Our CEO’s instinct that the bar was too high was vindicated, and what let us lower it safely was a plain-English document. That is what an expressive format buys you: policy that keeps pace with trust.

None of this means plain English is free. Grok Bot spread across CorralData in days, and its rough edges spread with it. Bots answered only people whose accounts were linked, and woke only when tagged by name. Login tokens broke. One bot reached our private network only through my own machine. For coding, the verdict was "pretty rough."

CorralData’s safety in those months came not from the English but from structure at a few specific points: lanes that decided which customer messages an agent could send unaided, hard stops around patient data and billing, quality checks tied to a specific version of the code, the size-based evidence rule for proposed changes. The pattern, once I saw it, was clear: a simple, expressive interface, with firm gates at the points where a mistake can’t be undone.

Plain English is the right default for describing a role, a procedure, a preference or a policy. But English is read by a model that decides, each time, how to apply it. For most work that is exactly what you want. For a few things it isn’t.

The VHS tape and the PHP script were never the best-engineered options. They won because ordinary people could use them for the job they actually had, and each new user made them more valuable to the next. Plain English has both properties, more strongly than any technology before it, and it gets better every time the models do. The Bitter Lesson says the clever structure you build today is the constraint you remove tomorrow. Write your playbooks so there is nothing to remove.

But "almost everything" is not everything. Some work involves arithmetic that must be right every time, facts that must come from a live system, and actions that cannot be taken back. For those, a paragraph followed ninety-nine times in a hundred is not good enough. Chapter 11 sets out when to lock things in, how far, and how to keep the locks from becoming the next thing the models outgrow.