The Late-Night Feeling of Wonder

In 1980 my ten years older sister started university and brought home a TI-58 programmable calculator. I was ten years old. I found out you could give it instructions and it would follow them. That was enough. I was done for.

Within a year I had convinced my parents to buy a VIC-20. I learned BASIC, then 6502 assembler, because BASIC was too slow for what I wanted to do. On an 8-bit machine the assembler is close enough to touch. You see exactly what the CPU does, every register, every cycle. Then came the Commodore 64.

The C64 years

The C64 was the real playground. I would sit down at ten in the evening thinking "I will just get this one thing working." In Haparanda, in northern Sweden, winter darkness arrives at three in the afternoon and stays until nine the next morning. The screen was the only light in the room. The world shrank to the keyboard and the monitor, and hours disappeared. At three in the morning I would look up and realize school started in five hours. It was not work or homework. I was still there because I wanted to see what more the machine could do.

I got pixels on the screen and learned to move them. I got sounds out of the SID chip. I built text adventures, entire worlds made of words and conditional logic. I started writing my own version of M.U.L.E., then my own version of Elite. Neither was ever finished. Neither needed to be. At some point I built a turtle robot, two wheels and a pen that could move up and down, controlled from the C64. It drew circles on paper. Code that reached into the physical world and left marks on it.

Each project raised the stakes: calculator to screen to sound to worlds to physical robots. I would discover a new capability and immediately try to build five things with it. Most of them never got finished. The joy was in the discovery that the machine would do what you told it to do.

From C64 to compilers

University extended the same feeling into deeper territory. At Uppsala I studied computer science and later wrote a PhD on native code compilation for Erlang. After that came a postdoc at EPFL, working on compiler design and the early days of Scala. The loop was the same. Here is a machine. How far can you push it?

The academic years kept the discovery loop alive. You could spend months on a single optimization pass, trying approaches that might not work, measuring the results, trying again. The feedback was slower than the C64 sessions, measured in benchmark runs rather than pixels on a screen. The underlying drive was the same: find out what the machine can do, then make it do more.

Some nights ended in a working optimization. Some nights ended in Unreal Tournament.

The long middle

Then programming became my profession in a different sense. Over twenty years I built systems for banks, telecom companies, and startups. Erlang, distributed systems, the kind of software where reliability is not optional. I learned the craft of building things that serve real users under real constraints: architecture reviews, test coverage, deployment pipelines, incident response. The discipline of engineering.

The all-night sessions stopped. You do not stay up until three when you have production systems to keep running and people depending on your judgment the next morning. The joy got channeled into something more measured and more useful.

The late nights that remained were incidents. A live bug in a runtime system, logs streaming, dashboards lighting up, people asking for updates. Solving those problems can be satisfying. It is a different kind of adrenaline. But it is not the same as staying up because a sprite finally moved across the screen.

The old blogs knew

There is an interesting pattern if you read the old blogs from Steve Yegge, Jeff Atwood, and Joel Spolsky today. They were writing about why programming used to feel joyful, and many of the things they described are suddenly becoming true again.

In the early days the barrier between idea and code was small. A programmer had a REPL, a compiler, a text editor, and curiosity. Yegge wrote huge systems in scripting languages because it was fun. Joel built startups with tiny teams. Atwood wrote Stack Overflow partly as a side project experiment. You wrote code because you wanted to see what would happen.

Then enterprise software happened. Frameworks on top of frameworks, dependency graphs with thousands of packages, build pipelines that take longer than a coffee break. You stopped writing programs and started operating infrastructure. Yegge ranted about it. Atwood joked about it. Joel turned it into business advice.

If you step back, there is a strange cycle. The 1980s and 1990s: fast feedback, experimentation, joy. The enterprise era, roughly 2000 to 2020: heavy frameworks, process, infrastructure. The AI-assisted era, 2023 onward: fast feedback again. Joel wrote during phase two, often pointing at the friction. In essays like "The Law of Leaky Abstractions," "Things You Should Never Do," and "The Joel Test," he kept returning to the same principles: fast feedback loops, simple tools, programmers working in flow, minimal friction between idea and running code. He never wrote about vibe coding. He described the conditions that make it work.

The REPL is back

The cycle time between idea and running code is collapsing again. LLM coding assistants, interactive notebooks, fast local tooling. The friction Joel spent years complaining about is shrinking, and that is the real reason people talk about vibe coding. It is not about laziness. It is about latency, and latency kills creativity.

Yegge made an observation years ago that still holds: great programmers build systems that amplify curiosity, not systems that enforce process. Languages like Lisp, Python, Erlang, and Smalltalk always had this property. You can poke a running Erlang system, change it while it lives, explore it. AI tools unintentionally recreate the same kind of environment. Not perfectly. Enough to bring back the feeling of discovery.

Joel once wrote that great programmers are dramatically more productive than average ones. AI tools may end up amplifying exactly that effect. The people who already loved exploring systems late at night will simply explore much faster.

The return

It came back in stages. In late 2022 I started a Java project by asking ChatGPT questions and copying the answers into my editor. Clumsy, slow, and still faster than writing boilerplate from scratch. By mid-2023 I was doing the same with Erlang world generation code and ML model tuning. The loop was: ask, copy, paste, fix, repeat.

In 2024, Copilot moved into my editor and the loop tightened. I started a life organizer in January, a productivity server in February with a commit message that read "Add a ChatGPT connection," an agent framework in March. Four projects in eight weeks. I recognized the pattern immediately: discover a new capability, start five things at once. The C64 again.

Then in June 2025, the third shift. I added a CLAUDE.md file to Solar Frontiers, an Erlang game project that had been sitting at fourteen commits over ten months.

Solar Frontiers. An Erlang-powered strategy game. Fourteen commits in ten months, then six hundred and fifteen after adding AI to the workflow.

Since then Solar Frontiers alone has accumulated more than six hundred commits. It was not an exception. In nine months of vibe coding across my projects, the numbers add up to nearly three thousand commits and more than a million lines of code written, roughly eleven commits a day.

On the C64 I might have written fifty lines in an evening and felt like I had conquered the world. The scale changed. The rhythm is back.

By early 2026, the project list looked like this: a life organizer, a home dashboard running on a Raspberry Pi with Nerves, a weekly menu generator that automatically orders groceries from Mathem, a kids chore controller, a door controller for the house, Modbus integrations to the Nibe heat pump and the FTX ventilation system, a voice pipeline prototype, a book library app, LAN party tools for Unreal Tournament, a gaming monitor, a Discord bot. Compare that to the C64 list: text adventures, M.U.L.E. clone, Elite clone, turtle robot. Same pattern. Ambitious, broad, driven by curiosity.

The difference is speed. On the C64 it took weeks to get sprites moving. With AI tools you can have a working dashboard in an evening. The feeling is the same.

A note on production

I would not push vibe-coded software to a fintech production system today. The quality is not there for high-stakes systems. I believe the improvements have been exponential since the 1940s. The early part of an exponential curve looks flat, and the flat part lasted long enough that several generations of researchers concluded AI was permanently limited. The late part looks vertical, and we are entering it now. That is a topic for another post.

There are also harder questions around AI-assisted development: training data, copyright, security risks, and the occasional spectacular failure when a model confidently deletes the wrong database. Those questions deserve serious discussion. This essay is about something simpler: why the machine suddenly feels interesting again.

The same feeling

The turtle robot drew circles on paper. The door controller opens the front door. Code reaching into the physical world, same feeling, forty years apart. The unfinished M.U.L.E. clone and the ever-growing Aurora life organizer. Same "I will just..." at ten in the evening. Same "school in five hours" at three in the morning, except now it is "meeting in five hours."

The thing that got me into programming is still here. It just needed a new form. Even in Stockholm, in the winter, the darkness outside makes the screen feel like the whole universe.

Many years ago, in my PhD thesis, I quoted a line from a Dan Fogelberg song:

"The days are empty and the nights are unreal."