What is the difference between working code and scaling code?

Working code answers whether something does the right thing when you run it — one user, one session, the happy path. Scaling code answers whether it still does the right thing when thousands of people run it at once, on different connections, in an order nobody planned, while other parts of the system are also under load. Nobody passes the second test by accident.

What should engineers ask after code works but before it ships?

The senior-engineering questions: what happens if this service fails; how does this behave under ten times the traffic; what breaks when users behave in ways you did not predict. Those questions rarely produce more code — they produce systems that survive their own success. That instinct is earned through outages, not prompts.

Edition 8·Jun 30, 2026·Production reality·6 min read

Working is not scaling

Q: Why does AI make the working-vs-scaling gap worse?

AI has made the working part almost free — you can reach a running product in an afternoon that genuinely works in a demo. But it gives you working code far faster than it gives you the judgment to know whether that code will hold under real load. The distance to "it works" shrinks to almost nothing while the distance to "it survives real users" stays exactly as long as it always was.

Working code proves the idea is right. Scaling code proves the architecture can carry the weight of being right. They are different problems wearing the same clothes, and AI is quietly widening the gap between them.

Years ago, in the early days of Interns School, I thought I had built something solid. The code worked. The features did what they were supposed to. I had tested everything I could think of. Then a few hundred students found it in the same week, hit the platform at the same time, and the whole thing went down. Completely down. The product I had spent months building could not handle the one thing I had built it for.

I sat there staring at the error logs thinking, I tested this. Then the obvious truth landed. I had tested it alone. One user. One session. One device. One everything. I had never once thought about what happens when real humans arrive all at once, on different connections, doing things in an order I never imagined.

That outage taught me something I have watched hold true on every product since. Working and scaling are two completely different engineering problems wearing the same clothes.

Working code answers one question. Does this do the right thing when I run it. Scaling code answers a much harder one. Does this still do the right thing when a thousand people run it at the same time, on different connections, in an order nobody planned, while another part of the system is also under load.

Nobody passes the second test by accident. And the gap between the two is not small or academic. It is where products die in public.

You have watched this happen at a scale that made the news. When Taylor Swift tickets went on sale in November 2022, Ticketmaster's system had been built to handle the roughly 1.5 million verified fans it expected. By its own account, over 14 million showed up. The site took 3.5 billion requests that day, four times its previous peak, and buckled within the hour. That system was not broken. It worked exactly as designed, for the load it was designed around. Then reality arrived with a different number, and working stopped being enough.

And the bill for that gap is not theoretical. ITIC's 2024 survey of more than a thousand firms found that for over 90 percent of mid-size and large companies, a single hour of downtime now costs more than $300,000, and for 41 percent of them it runs from $1 million to over $5 million an hour. That is the price of discovering, in production, that working was never the same as scaling.

Here is the part that matters if you make hiring and architecture calls, not just write the code. The instinct to design for load before it shows up is the clearest line I know between a junior engineering decision and a senior one. Not speed. Not cleverness. Just having been burned enough times to feel where the weight will land before it lands there. A senior engineer pauses after the thing works and asks the uncomfortable questions. What happens if this service fails. How does this behave under ten times the traffic. What breaks when users behave in ways I did not predict. Those questions rarely produce more code. They produce systems that survive their own success.

You cannot buy that instinct and you cannot prompt it into existence. It is earned through outages, the late night kind that rewire how you design forever.

Which is exactly why this is more urgent now, not less. AI has made the working part almost free. You can go from idea to a running product in an afternoon, and it will genuinely work, for one user, in the demo, on the happy path. But AI gives you working code far faster than it gives you the judgment to know whether that code will hold. I have written before that AI hands you the feeling of competence before the thing itself. Scaling is the sharpest version of that. The tool shrinks the distance to "it works" to almost nothing, while the distance to "it survives real users" is exactly as long as it has always been. So the gap between what you can ship and what can carry weight is not closing. It is widening, quietly, underneath everything we are now building faster than ever.

Every product I have shipped that survived its first real spike did so because someone went back after the first crash and rebuilt the part that was never designed to carry weight in the first place. Working code proves the idea is right. Scaling code proves the architecture can carry the weight of being right. In an era where almost anyone can reach the first, the people who can still reach the second are the ones worth hiring, and the instinct that gets them there is worth protecting on your team like the scarce thing it is.

So a question, and I would like the war stories. What is the first thing that broke the moment something you built actually started working?

Reply and tell me. I read every one.

Sources: Ticketmaster presale figures from Ticketmaster's November 2022 public statement, as reported by CNN and CBS News: 3.5 billion total system requests, four times the prior peak, against a Verified Fan system built for roughly 1.5 million invited buyers. Downtime cost figures from ITIC, 2024 Hourly Cost of Downtime Survey (over 1,000 firms polled): a single hour of downtime exceeds $300,000 for more than 90% of mid-size and large enterprises, and runs $1 million to over $5 million for 41% of them.

Questions this edition raises