A rule about playgrounds came up in a conversation this weekend (three kids; I spend a fair share of my weekends at playgrounds), and I haven’t been able to put it down since.
The standard for playground equipment in Norway and the rest of Europe is EN 1176, which our own forskrift om sikkerhet ved lekeplassutstyr from 1996 accepts as proof of compliance, and which DSB will point you to if you ask. It sizes the fall protection on a raised platform by height, which you’d expect, and by how easy the platform is to reach, which you might not expect. A deck that a toddler can walk straight up a ramp onto needs a full barrier from 60 centimeters up. The same deck, at the same height, reached only by a climbing net, can get away with a guardrail until it’s two meters off the ground. The drop is identical. What changed is who can get up there.
The standard even explains why: a hard ascent “slows down the movement and provides time for intervention.” The climb counts as protection, because it buys an adult time to notice.
The climb was the safety feature.
What the climb was for Link to heading
Until about three years ago, software had the same rule built in, and nobody had to write it down. Anyone who shipped a fast, decent-looking, working web app had climbed to get there. They had lost at least one argument with webpack (I’ve lost several, and I enabled ephemeral storage on Azure VMs while I was at it 😅), and they had run something destructive in production because a forum told them to, or stood next to the poor trainee who did. Most people can’t program at all, let alone deploy something to the internet and make it look good and respond fast. So when you saw such a thing, you could assume that the person behind it knew roughly what they were doing, not because the thing was impressive, but because of what it took to get it up there.
We leaned on that assumption more than we noticed. It’s why a portfolio meant something in a job interview, and why “they have a product in production” used to be a sentence with actual information in it.
Now, a fair share of that climb was what Brooks called accident, and I said so myself last month: the webpack fights, the build config, the twentieth factory. The essence, the part where you decide what the system should mean and feel the design push back, was in there too, but you couldn’t see it from the outside. What you could see was the accident, and nobody got through the accident without doing the essence along the way. So the accident worked as a proxy. Impressive implied climbed, and climbed implied understood (or at the very least a certain degree of hands on experience). Loosely, and definitely with exceptions, but it did. (Brooks and Polanyi each have their own name for the part you can’t see; earlier posts, if you’re new here.)
Now everyone has a ladder(!) Link to heading
A single prompt can give you a deployed app with auth, a database, a landing page and a dark mode toggle, responding in under a hundred milliseconds. It looks great. It is at the top of the tower, no argument from me.
Nothing about it tells you whether the builder climbed, and as such: you can have no assumptions as to how experienced or otherwise trustworthy the author of the software is. The accident is free now, so the proxy is dead, and impressive implies nothing at all anymore. The signal went away subtly enough that most of the industry is still acting as if it’s there. Hiring managers still weigh portfolios, and reviewers still go easy on a PR that looks clean. Ladder code looks exactly like climbed code from the outside.
To be fair, the signal had been eroding for fifteen years; Rails scaffolding and Firebase both let people ship things they hadn’t entirely climbed to. What’s new is the height. Squarespace never handed anyone a payment integration or a shell with production tokens in its environment. The ladder now reaches the tall elements.
(The people on the ladder aren’t stupid, btw. Some of them are the best engineers I know, using it to skip a climb they’ve already done thirty times, in a codebase they know inside out. That’s the whole problem from where the reviewer stands: the output from those engineers and the output from someone who has never climbed anything look the same in the PR, so the protection has to be sized for the second case. Or we need new metrics?)
The playground people were smarter than us about this. Instead of banning ladders they wrote a rule with two variables in it: how easy the ascent, and how far the fall. The easier you make the climb, the more protection you owe at the top. Our industry has spent three years making the ascent easier for everybody and has not, as far as I can tell, recalculated a single fall.
How far is the fall? Link to heading
Fall height, in software, is roughly equal to blast radius. A to-do app for yourself is thirty centimeters off the ground; fall all you like (a marketing page is maybe knee height?). A thing that moves other people’s money, or holds their health data or their credentials, or runs shell commands with a production token in its environment, is the top of the tower, and the ground underneath is exactly as hard as it sounds.
And again, we handed out ladders to all of it at once. The same tool that scaffolds a hobby project will scaffold a payment integration without a flicker of hesitation, and the two outputs look the same. I’ve written about what the landing looks like: an agent that wiped a production database during a code freeze, and another that found a token and deleted the wrong thing with it. The yearly count of secrets leaked on GitHub is up by a third too, with .env-slurping agents named as one of the drivers. Those are the incident reports. Nobody has ever fallen off a to-do app.
So what do we actually do? Link to heading
I’m not proposing a ban; the playground people didn’t need one either. They just made you count both variables, and I think ours look like this.
Match the ladder to the height. Ladders on the low elements, gladly: tidying Tailwind classes, turning DOM sludge into JSON, that sort of thing. On the tall elements, the ones with other people’s money or credentials underneath, climb. Or at least make SURE somebody on the team has, recently, and that they’re the one reviewing.
If you hand out ladders anyway, build the barrier, and build it in proportion. A sandbox with no production credentials in it. A compiler that catches the fall before it happens (parse, don’t validate). Review by someone who has climbed this tower. The standard’s logic is the useful part here: the easier the ascent, the more of this you owe, and almost nobody raised the barrier when they handed out the ladders. (Tests written by the same agent that wrote the code are a barrier installed by the toddler, mind you. They count for something, I guess. Not for much.)
And stop reading impressive as competent. In hiring, in review, and, hardest of all, when your own ladder output looks better than it should. Ask instead how far the fall is and who is standing underneath.
(The standard also has a hard cap, btw: no free fall over three meters, ladder or no ladder, barrier or no barrier. I have opinions about which of our towers that applies to, but that’s a different post.)
The ladder isn’t only AI, either, btw; but I propose it’s the most readily available variant. Every reorg and every layoff letter hands whoever is left a ladder onto a tower nobody on the team climbed. But at least then there’s hopefully someone (not a machine) to talk to about it!
Which brings me to the confession: I’m a consultant. By this post’s own logic I am a ladder onto other people’s towers – my whole job consists of walking up to systems I didn’t climb, and a good chunk of this post is aimed at myself. The difference, I hope, is that I know I’m at the bottom when I arrive, and I’ve stopped pretending otherwise to the people who hired me.
And, I actually like climbing, and have no plans to quit!