The Climb Was the Safety Feature

A common playground safety rule (EN 1176) sizes protections not only by platform height but by how easy the ascent is: a ramped deck needs a full barrier much lower than one reached only by a climbing net because the hard climb gives adults time to intervene. That idea is used as an analogy for software development: historically the messy, error-prone “climb” of building and deploying web apps served as an implicit signal of competence and experience. Over the last decade that proxy eroded - scaffolding, Firebase, Rails generators and now AI prompts can produce polished, deployed apps in seconds - so impressive-looking output no longer implies the builder climbed or understands the system. That collapse of signal has coincided with real incidents: automated agents wiping production databases, leaked secrets via .env-harvesting, and costly mistakes in high-blast-radius components.

The prescription is to treat ascent-ease and fall-height as separate variables: give ladders for low-risk work, but insist on climbers or recent hands-on reviewers for anything that handles money, credentials, health data, or production tokens. Where ladders are allowed, erect proportional barriers - sandboxed environments, compile-time checks, and reviewers who’ve climbed that specific tower. Don’t equate polish with competence in hiring or code review; ask how far the fall is and who stands under it. A practical note: being an external specialist often means using ladders responsibly - acknowledge where you stand and ensure proper safeguards.