A city is not a scaled-up town — it's a different kind of organism. Double the population and per-capita wages, patents, and GDP don't stay flat; they rise systematically by about 15%. Yet at the same time, per-capita roads, cables, and gas stations fall by about 15%. The bigger the city, the more each person creates and the less each person consumes — and this regularity holds astonishingly steady across countries and across decades.
Two opposite scalings happen at once. Socioeconomic output (wealth, innovation, crime, disease) grows superlinearly with population, with an exponent of about 1.15 — because the number of possible connections between people grows faster than the population itself; a city is essentially an "interaction amplifier." Infrastructure (road networks, cables, pipes) grows sublinearly, with an exponent of about 0.85 — like a vascular network, the bigger it gets, the cheaper each unit becomes. A city runs on the tension between "bigger means richer" and "bigger means leaner."
| System | How it changes with size | Scaling exponent |
|---|---|---|
| City · socioeconomic output | Superlinear (more per capita) | ~1.15 |
| City · infrastructure | Sublinear (leaner per capita) | ~0.85 |
| Biology · metabolism | Sublinear (slower, longer-lived) | ~0.75 |
Even people's walking speed rises with city size — this has been measured, so the faster "pace of life" in big cities is no illusion. But superlinearity is double-edged: as per-capita wealth and patents climb with scale, so do per-capita crime, contagion, and psychological stress, riding the very same curve. More crucially, superlinear growth means a city must keep innovating just to "stay alive" — without fresh breakthroughs, accelerating demand eventually slams into a resource ceiling. This is exactly where cities and companies part ways: a company behaves like an organism — sublinear, aging, mortal — while a city can endure open-endedly.
In biology, metabolism follows Kleiber's 3/4-power law — the bigger the body, the slower the metabolism and the longer the lifespan, exactly opposite to a city's socioeconomic output. In network science, superlinearity arises because the number of connections grows with the square of the nodes (Metcalfe's law). In organizational management, a team's communication cost likewise rises superlinearly with headcount — but most companies amplify overhead rather than output, hence diseconomies of scale and eventual decline.
To make a team or AI system scale "like a city, not like a company," the key question is: what does scale amplify — effective interaction, or coordination overhead? In most teams, adding people drives communication cost up superlinearly while output rises only sublinearly — the very source of big-company sluggishness. The real leverage is designing structures that amplify interaction: where each marginal connection creates value rather than friction. This is why a small, dense, highly information-rich team often outruns an organization three times its size.
When your organization scales, does it amplify output or overhead? If you drew its scaling curve, would it look more like a city that grows richer with size, or a company that grows slower and is destined to age?
Building wider roads often buys you a more congested city. Traffic jams are not the simple arithmetic of "too many cars, too few lanes" — they are a complex system that self-organizes and can suddenly collapse. There is a critical density; past that point, a jam can materialize out of nothing, with no accident at all. To understand it, you need the eye of a physicist watching a phase transition, not an engineer pouring concrete.
Road flow rises and then crashes as vehicle density grows: at low density, more cars mean more flow, but once density crosses a critical point, any tiny disturbance (a single brake tap) gets amplified into a backward-propagating "stop-and-go wave," and flow plummets — a genuine phase transition, "freezing" from free flow into a congested state. "Induced demand" then explains why widening roads fails: new capacity attracts more drivers and more long-distance trips, rapidly refilling the freed-up space, until vehicle-miles grow almost in proportion to lane-kilometers.
| Vehicle density | System state | Road flow |
|---|---|---|
| Low | Free flow | Rises with density |
| Critical point | On the brink | Peaks |
| High (past critical) | Stop-and-go · congested | Crashes |
Closing a road can make everyone faster — this is Braess's paradox: adding a shortcut to a network can worsen everyone's equilibrium route, while removing it can smooth the whole system out. Seoul tore down an elevated expressway to restore the Cheonggyecheon stream, and nearby traffic improved rather than worsened. There are also "phantom jams": let a ring of cars drive at steady speed on a circular track, and researchers observed congestion forming spontaneously with no external cause — the jam holding you up is often just a brake tap from kilometers away that has long since dissipated.
In physics, this is the "jamming transition," kin to granular flow and the glassy state — the system "freezes" from flowing to jammed at a critical density. In computer networks, it's "congestion collapse": overload a link and retransmissions avalanche while throughput crashes — TCP's backoff exists precisely to tame this transition. In supply chains it maps to the bullwhip effect; in crowd evacuation, to "faster is slower" — the harder people push toward the exit, the more it clogs.
Distributed systems are full of isomorphs of traffic congestion: thread pools, connection pools, and message queues each have their own critical density, past which adding machines or concurrency makes throughput crash and latency spike — the server-side version of a phantom jam. "Induced demand" haunts engineering too: scaling up often induces more calls and more aggressive usage that swallow the new capacity. The real fix is usually not widening the "road" but rate-limiting, shedding peaks, and keeping a safety margin below critical density.
In a system you maintain, has a "scale-up" ever induced more load while the problem persisted? Is its true bottleneck a shortage of capacity, or having crossed some critical density you hadn't noticed?
Twentieth-century planning worked feverishly to optimize movement — faster cars, wider roads, residential, work, and commercial zones kept strictly apart. The result was the longest-commuting cities in human history. The 15-minute city flips the whole logic: don't make you move faster — make you not need to move. Everything you need each day lies within a 15-minute walk or bike ride. The thing being optimized shifts from "speed" to "proximity."
The key variable is "proximity," not "mobility." By raising density and mixing functions (weaving living, working, commerce, healthcare, and education into the same neighborhood), trip distances are compressed at the source, and street space once handed to cars is returned to pedestrians and cyclists. Modernist planning sliced the city into separate single-use blocks via "zoning" — tidy and efficient-looking, yet it turned the car into a necessity. What the 15-minute city does is stitch those artificially severed functions back next to one another.
A city built for "efficient movement" is precisely the one that wastes the most time. The most car-centric cities, with the most developed road networks, often have far longer per-capita commutes than the "backward" dense old towns — because a developed network spreads everything out, lengthening every trip. This is the other face of induced demand: you get more of whatever you optimize for. Optimize movement, and you get more movement; optimize proximity, and only then do you get time genuinely saved.
In computer architecture, this is the "principle of locality" and caching: put the most-used data closest to the CPU, where the hit rate decides all performance — the 15-minute city is essentially urban cache design. In distributed systems it maps to edge computing: push compute as close to data and users as possible, cutting round-trip latency. In cell biology it's compartmentalization: lock related reactions inside the same organelle so molecules need no long journeys.
Whether designing an AI workflow or your own work environment, it's worth asking: "What is my 15-minute radius?" — are the tools, data, and context you use most often all "one step away"? Much lost efficiency comes not from any single slow step but from repeatedly "commuting long-distance" between systems just to fetch one resource. Moving high-frequency dependencies close, and caching and localizing them, often frees more energy than optimizing the speed of any single point.
Take stock of the few actions you perform most often in a day — are their "dependencies" within reach, or scattered around, demanding constant back-and-forth switching? Which high-frequency resource deserves to be "moved into your 15-minute radius"?
What makes a street safe is not the police, nor wider buffers and brighter lights, but the steady stream of ordinary people on it — those casual, unintentional glances. An old street where homes, shops, and restaurants mingle and there's life all day long is often safer than a tidy, single-use modern block. A city's order is mostly grown from the bottom up, not designed from the top down.
Mixed use keeps a neighborhood peopled at every hour — commuters, shoppers, strollers, shopkeepers. These continuous, mutually anonymous glances form an invisible web of "natural surveillance": a transgression is likely to be caught by some pair of eyes and thus quietly deterred, while repeated encounters weave faint neighborly trust and social capital. It requires three conditions: a clear public–private boundary, windows and doors facing the street, and a reason for people to keep walking out onto it.
Modern housing projects built expressly for safety and order often turn dangerous instead. America's Pruitt-Igoe public housing, proud of its grand, clean high-rises and broad lawns, drained street life so thoroughly that with no one naturally watching, it quickly became a crime hotbed and was demolished less than twenty years after completion. Meanwhile, the dense old neighborhoods dismissed as "messy and crowded" survived intact — precisely because there were always people present. Tidy is not necessarily safe; lively is.
In open-source software, this is Linus's law — "given enough eyeballs, all bugs are shallow": code stays healthy through the continuous gaze of many contributors rather than the centralized review of a few authorities. In distributed systems it maps to decentralized observability: rather than rely on one central monitor, make many nodes mutually visible, exposing state to one another. In complexity science it's a model of self-organized order — robustness arising from distributed local interaction, not top-down central control.
For a codebase, an AI system, or a team, safety and quality come down to one question: do they rely on the centralized review of a few gatekeepers, or on "enough eyes" continuously present? A system held together by top-down control alone is all blind spots the moment that one pair of eyes lapses; a highly observable system where everyone is visible and state-exposure is encouraged is like a bustling old street — problems struggle to lurk for long. Building "eyes on the street" into a system — keeping critical paths exposed to many eyes — is often steadier than adding one more layer of centralized approval.
Does the system or team you're responsible for rely on the centralized oversight of a few gatekeepers, or on "eyes on the street"–style distributed, natural surveillance? Which critical link right now lacks enough eyes continuously watching it?