What a walled city in Hong Kong can teach us about the future of AI development. And why vibe coding might be a regression to the 1990s, with better tools.
There is a photograph taken in 1989 of Kowloon Walled City from above. It looks less like a neighborhood and more like a geological formation — a dense, irregular mass of concrete and rusted metal that grew not upward but inward, filling every possible gap until nothing remained but structure. No courtyards. No light wells. No logic.
It is an image of what happens when human ambition operates without constraint, coordination, or shared vision.
We are building its digital equivalent right now. And we are calling it innovation.
The city that planned itself
Kowloon Walled City began as a Qing dynasty military outpost on the Kowloon Peninsula – a garrison fort built in 1847. When Britain extended its lease over the New Territories in 1898, it left the Walled City in a jurisdictional gray zone — technically Chinese, practically ungoverned, and persistently overlooked by both sides. A patch of land that belonged to no one.
As civil war consumed mainland China, refugees flooded into Hong Kong and found their way to the enclave. Later waves came fleeing the Cultural Revolution, joined by fugitives and those with reasons of their own not to be found. What drew them all was the same thing: a place that turned no one away.
With no jurisdiction came no infrastructure. Electricity was stolen outright. Residents tapped illegal connections into the municipal grid outside the walls and ran cables across the buildings above. When officials discovered them and cut the lines, new cables went up over the dead ones. Then those were cut, and new ones followed. Layer upon layer, season after season, until the alleyways were canopied by a dense, chaotic web of wiring that no one fully understood. It was a record of every failed repair, every workaround, every solution built on top of a problem that was never actually solved. It was always easier to add a new cable than to make sense of the old ones.
Residents built upward, floor by floor, without permits and without architects. New structures were bolted to existing ones. Pipes ran wherever they could. By the late 1980s, the city housed between 33,000 and 50,000 people on roughly 2.6 hectares — approximately 210 by 120 meters. Its population density reached approximately 3.2 million people per square mile: around forty-five times denser than Manhattan today.
And yet it functioned. There were restaurants, dentists, factories, schools. The city had a pulse. But it had no design. No one had ever asked: what should this place be? Every decision was made locally, immediately, in response to the pressure of the moment. The result was a place of genuine human energy encased in a structure that could not be understood, maintained, or safely expanded.
When Britain and China signed the 1984 declaration that would return Hong Kong to Chinese sovereignty in 1997, both governments looked at Kowloon and reached the same conclusion: neither side wanted to inherit it. When the wrecking ball finally arrived in March 1993, engineers found layers upon layers of undocumented additions, each one built in ignorance of what came before.
Before we discovered the user
There was a time when the people who built software were also, by default, the people who decided what it should do and how anyone should use it. Not because they were the best qualified, simply because they were the only ones in the room.
Software was planned and written by engineers, and the assumptions baked into those products reflected it. If you wanted to use a word processor in 1987, you first needed to understand how the word processor thought. The word processor didn’t have a WYSIWYG interface; menus were structured around system logic, and file managers reflected the computer’s directory trees rather than how a human might think of them. Error messages were written for the programmer debugging the code, not the office worker staring at the screen in confusion.
They knew how the machine worked, and in the absence of anyone else, that knowledge became the only qualification that mattered for the design, for the direction, for the definition of what “useful” even meant. When the role we now call product manager began to emerge in the late 1980s, it was engineers who created it and filled it, because no one else was in the room.
The problem was never competence. It was perspective. A programmer is trained to think in terms of function – every state the system can enter, every input it might receive, every branch the code can take. That training instills a specific instinct: when you encounter an edge case, some rare or esoteric condition, you solve it, because in software, an unhandled case is a bug waiting to happen. Completeness is the virtue. But this is almost exactly the opposite of how a designer thinks. A designer asks what most people are actually trying to do, and guards that path above all else. Every rare case you surface, or obscure option you place in front of the user, makes the common ones a little harder to reach. The programmer optimizes for everything the system can do. The designer optimizes for the one thing the person came to do. Left alone, the programmer’s lens wins by default, and it quietly shapes everything.
You can read that lens in the era’s error messages. When something went wrong in DOS, the system asked: “Abort, Retry, Fail?” From the machine’s point of view, this was admirably thorough – three real branches the code could take, presented honestly and completely. From the outside, to the person sitting at the desk, it was very nearly meaningless. The prompt wasn’t written for the human who had to answer it.
In 1998, a programmer named Alan Cooper, often called the father of Visual Basic, gave this whole problem its name in a book called The Inmates Are Running the Asylum. His argument was blunt: When engineers are left in charge of products they were never trained to design, they build things that serve the machine’s logic over the person’s needs. The only real fix, he argued, was to hand control of what gets built to interaction designers rather than developers. The book is full of examples, but one has stuck with me. Cooper described his own digital alarm clock, a device with a sophisticated alphanumeric display capable of showing all of its many functions. Whether the alarm was actually set was communicated by a tiny clock symbol in the corner of the screen. The indicator existed; the requirement was technically met. But in a dimly lit bedroom that little symbol was impossible to see, so the alarm would occasionally fail to wake him on a Monday and haul him out of bed at dawn on a Saturday. Every function worked exactly as specified. The product still failed at the single thing it existed to do. That is the programmer’s lens in miniature: the feature is present, the box is checked, and the human is left worse off.
Gradually, companies began hiring people whose job was not to build software but to understand the people using it – usability testing, user research, the beginnings of what we now call UX. Don Norman’s The Design of Everyday Things (1988) made the core argument: when people fail to use something, the fault lies in the design, not the user. Norman would go on to join Apple and coin the very term “user experience.”
The turning point came in 1995. Windows 95’s development combined serious investment in research and iterative design. It had one of the most successful product launches in computing history – seven million copies in its first five weeks. It is still remembered as a UX milestone of its era.
By the late 1990s, a once-radical consensus had formed: the user’s experience was the product. The what mattered more than the how, and the people who understood the what became the new authority in development.
Engineers didn’t disappear. Their skills became more valuable than ever. But the question of what to build, and for whom, had migrated to different hands.
Reinventing the old process
Walk into any tech company today, and you will hear the word AI on every floor, asked for with a certain urgency. Often, the people asking aren’t quite sure what they’re asking for. The expectation travels down the org chart, and everyone waits for someone else to discover what it was supposed to mean.
You can measure how strange this has become by how literally companies have tried to measure it. As 404 Media recently reported, Amazon ran an internal leaderboard ranking employees by how much they used AI tools at work. Employees promptly gamed it. One admitted to cheating their way up the ranks, after a performance review said they weren’t using AI enough. They simply set the tools running on an endless series of tasks that had nothing to do with their job. “Maximizing the throughput was the most fun I’ve had at work,” they said. The point of the work had quietly become the appearance of the tool being used. Usage was the metric, so usage is what people produced — whether or not anything useful came out the other end.
“Vibe coding” is programming by describing what you want to an AI model and generating working software from the output. It is real, impressive, and genuinely useful. Junior developers are shipping things that would once have taken them months. Non-technical founders are prototyping overnight. The barrier to building has never been lower.
The speed of construction was a real constraint in the nineties, but it stopped being the binding one a long time ago. Once jQuery, and later the npm ecosystem and frameworks like React, became standard, almost any competent developer had the tools to build quickly. Production speed quietly became less of a bottleneck. What still took time was everything around the building: the research, the design, the review – and that was deliberate. The processes that slowed a junior developer down were not there to stop them from building. They were there to make sure they were building the right thing.
This is what makes the current moment a misdiagnosis. We are treating speed as the prize when speed was not really missing.
And here is the part we have managed not to notice. In the rush to be seen using AI, the old discipline isn’t being upgraded – it’s being bypassed, and not just by developers. When a manager watches a non-technical colleague vibe-code a working prototype over a weekend, the reaction is delight: look how empowered everyone is now. But what has actually happened is that one more person has become an isolated unit of production, building alone, with no shared map and no one checking the direction. The developer working this way at least knows the terrain. The marketer or the analyst, prompting their way to a feature, does not. They are even less fluent in the environment they are now quietly reshaping, and even less likely to notice what they are breaking. Everyone gets their own little construction site. No one is reading anyone else’s blueprints.
Look at the math of it. A developer with these tools can move ten times faster than before. Strip away the design reviews, the user research, the architectural sign-off, all the things that used to slow a feature down, and that same developer can move fifty times faster, alone. One person, a fraction of the time, a working product. Who would argue with that?
But this is not the frontier. It is a regression – back to the exact arrangement the industry spent thirty years dismantling. The person who knew how to build was, by default, the only authority over what got built. We did not invent a new way of working. We took the old one, the one we had good reasons to abandon, and removed its brakes. The speed is what makes the regression invisible.
I am not the first to notice this. Writing in InfoWorld, one engineer explains that the exhilarating speed of AI-assisted development has to be paired with a human mind that bridges inspiration and engineering. He warns that without it, vibe coding becomes a fast track to crushing technical debt. And in Smashing Magazine, a designer describes watching the “Should designers code?” debate get settled overnight . Not by the craft, but by the brute force of job requirements demanding “vibe” and “code” at once. The unease is everywhere. What it points to is not less AI, but a discipline rebuilt around it.
Now imagine not one person building fast and without a plan, but ten. Each prompting their own vision of the product, each shipping a feature that made sense to them in the moment, none of them talking to a designer, none of them working from a shared architectural map. One builds the onboarding flow. Another rewires the navigation. A third adds a dashboard nobody asked for. Each piece works. Nothing fits together. There is no coherence, no through-line, no sense that a single mind, or any mind, ever held the whole thing at once. New features are bolted on top of existing ones. Every workaround becomes infrastructure. It is always easier to add something new than to understand what is already there.
That is Kowloon. Not a metaphor – a process. The same process, running again, at software speed.
The digital Kowloon is already under construction
You open the app – you enter the alley. The navigation shifts underfoot, a corridor that led somewhere last week now ends in a wall. Above you, cables in every direction: notifications, modals, feature flags, tooltips – each one strung by a different hand, none of them aware of the others. There are three ways to do the same thing and none of them are obvious. You do not understand the space; you have memorized a path through it. And you follow that path, because deviating means confronting how little of this was ever actually planned. The city functions. The product ships. Both are real. Neither was designed.
Two years from now, many of the products being vibe-coded today will be the Kowloon Walled Cities of the software world. Dense, layered, functional in a narrow sense, but impossible to understand, maintain, or safely extend. Built floor by floor, decision by decision, each one made in ignorance of the layer beneath it. The pipes will run everywhere. The wiring will be a mystery.
And clearing them out will cost far more than building them did.
The companies that will thrive are not the ones moving fastest right now. They are the ones who have understood something more difficult. The entrepreneur’s spirit – the urgency, the bias for action, the willingness to ship – is not in conflict with years of hard-won product discipline. It only feels that way when you haven’t figured out how to hold both at once.
It is clear that the newfound superpower of AI-assisted coding is changing entire professions and disciplines. No one today knows what the role of a designer or developer will look like in a few years. We only know that most roles will have to change profoundly. And just as the roles will change, the methods of work will have to adapt and change even more.
The real competitive advantage of the next two years will belong to the organizations that build AI-native processes without dismantling what came before. That treat vibe coding as a powerful tool within a thoughtful system – not as a replacement for the system itself. That keeps the functions of researchers, designers, architects, and security engineers in the room. Not as gatekeepers slowing things down, but as navigators making sure the speed is pointed somewhere worth going.
Knowing what to build, and why, always was the hard part. AI did not change that. It just made it easier to avoid thinking about it.
Disclosure: AI tools were used to assist with research and editing; the argument, structure, and final words are my own.
Image credits –
An aerial photo of the Kowloon Walled City taken in 1989.
By Ian Lambot, Also found in the book City of Darkness: Life in Kowloon Walled City by Ian Lambot (ISBN 1–873200–13–7)., CC BY-SA 4.0,
A postman in Kowloon, A temple inside Kowloon, A Kowloon rooftop
By ©Greg Girard, from City of Darkness (Watermark Publications, 1993)
All illustrations
Created by the author using Magnific AI.
The digital Kowloon was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
