So the Agent Physically Cannot Make a Mess

illustration

In 1961 the Japanese engineer Shigeo Shingo came to a factory of the Yamada Electric company, where small switches were assembled. Each switch was supposed to have two tiny springs under its two buttons, and every now and then the workers forgot to put one of them in. A switch without a spring went out to the customer, the customer sent it back, and the factory lost money and reputation. Management tackled the problem the way it is tackled almost everywhere: it explained to the workers that they had to be more careful, and punished those who made mistakes.

Shingo proposed something else. Before assembling each switch, the worker now took exactly two springs out of the common box and put them in a small dish, and only then fitted them in place. If a spring was left in the dish after assembly, one had been forgotten, and this was visible at once, with no need for carefulness at all. Mistakes almost disappeared. Shingo first called such devices baka-yoke, which literally means “fool-proofing,” and later renamed them to the more polite poka-yoke, “mistake-proofing.” Under that name they entered every textbook of production management.

Such devices are all around us; we just do not notice them. A SIM card has one corner cut off, so it is impossible to insert it into a phone the wrong way. A car with an automatic gearbox will not let you move the lever out of park until you have pressed the brake. A USB stick of the newer kind can be plugged in either way up and will work. In all these cases nobody urges a person to be more careful: the device is made so that it is physically impossible to get it wrong.

Agents need the same kind of dish: coaxing them with “please write clean code” is useless; you have to build an environment that simply will not accept a dirty result.

---

Such an environment is assembled from layers, and each layer catches its own sort of error. Most of these tools are decades older than language models; they were invented for people, and people used them reluctantly, because they are annoying. With agents everything changed, but more on that shortly; first let us go through the layers, starting with the simplest.

The first layer takes care of appearance and suspicious spots. A program called a formatter brings all the code to a single style: the same indentation, the same quotation marks, the same ordering. It seems a trifle until you try to read a project in which fifteen agents have each written in their own manner over a month. A program called a linter works like a very fussy proofreader: it does not know whether the program solves its task correctly, but it notices places that usually turn out to be mistakes, such as a variable that was declared and never used, or a comparison that always gives the same result. Both tools run in seconds and cost almost nothing.

Above appearance come types. In programming languages with types, every value carries a label saying what it is: a client’s phone number is text, a price is a number in roubles, a visit date is a date. A program that checks types will refuse to build code that tries to add a price to a phone number or pass a date where a number is expected. It sounds like protection against truly stupid mistakes, yet real programs are full of such mistakes. In 2017 researchers from University College London and Microsoft took several hundred fixed bugs from open-source projects written in JavaScript, one of the most widespread languages, which has no types by default, and checked how many of them a type system would have caught had one been used. The answer was about fifteen percent, one bug in seven, and the authors stressed that this was an underestimate. Types are especially valuable for an agent, because a type error message arrives instantly and points at the spot.