Disclaimer: this text was written by me and shares my personal views. AI was used for grammar, spelling, formatting, translation, and finding references.
During the Rails World 2026 Opening Keynote, DHH talked about how “today” is a great time to be alive. In his words: “even more exciting for me is to be alive right now in this moment”1. He was talking about the AI situation. That got me thinking. I always felt like there was nothing new coming to software, no paradigm breakers. I thought code was at its peak and anything from that point would be diminishing returns. That bummed me out in a way, because it meant I wouldn’t see history being made. LLMs changed that.
How it all started
My journey with computers started in the early 2000s, but 2006 was when I knew that I wanted to work with them for a living. It was before I knew what programming was all about. It all started with curiosity and the will to install games, which evolved into adding mods, and eventually into messing around with Windows to make the internet connection work. Soon I was on Linux, and that’s where a new horizon of possibilities arose. In 2007 I took Linux lessons with a guy who became my first mentor. He showed me the basics, all the way up to recompiling the kernel.
At that point, I barely knew how to read or write in English. Everything was a struggle and took tremendous effort to figure out. Searching forums was hard, and I had to rely on translators - which, back then, weren’t always that helpful. Everything had a long learning curve, and because most of what I learned wasn’t practiced, a lot of it was lost, so I kept every command and what it did documented.
The most valuable part of all of that was not the learning itself, but the skill set I was developing - without having any idea about it. I learned how to search, read through error messages and man pages, how to approach the community for help, how to organize my work and findings, and much more. These skills were invaluable when I began programming, when I started college, and later in my career - in fact, they still are. Without realizing it, I was developing my systems thinking23.
Hello, world!
My first hello world4 app was a C++ app I did while trying to learn programming. I remember posting on a PC forum that had a programming section asking for tips, and people recommended learning OOP - I had no idea what that was, and when I looked into it, it made even less sense.
At first, I never really dug hello worlds. At first glance, they don’t do anything useful. But if you think about it, they make sense. There is a lot going on in a hello world. Before you can get it to run, you need to set up the environment, which by itself can be a solid learning process. Then you learn about the command line, about commands, arguments, parameters. You learn about the compiler, you learn how to read error messages, and how to debug code. Then it finally runs. The result is unimpressive, but the value is the journey from typing in a text editor all the way to seeing the output on the screen.
The thought process behind hello worlds is valid. It’s about investigating, asking questions, and trial and error. Or to put it in other words: it’s about programming.
Hello worlds are no more. We no longer have to set up environments on our own, or read long stack traces, or go line by line trying to figure out what is going on. Agents will do that. They are faster, they know where to look, and the knowledge is there. Newcomers are likely just creating full complex systems as a “hello world”. And that’s a problem.
What the future looks like
The problem
What worries me the most about the future is that we can now do all of those “hello world” steps with a single prompt. But where’s the learning process? Many skills that I learned back then are transferable to many fields, and they are just as useful for “vibe-coding”5 as they are for debugging a C program. Where will this come from now? How are people learning how to explore, debug, ask, break, and fix things if the agent is the one doing all of that work?
The software engineering career
Social media is full of the idea that software engineers will get replaced. I don’t fear for my career. I know a product person can’t replace me. Not because I’m personally irreplaceable, but because they have a different skill set, one that’s much more directed towards the high-level aspects of the product and management.
Agents are not people. You can manage them, but the extent of what they produce is going to be limited to what you tell them; they will not have ideas on their own, or discuss with each other, gather different experiences and backgrounds, and consolidate them into an implementation. If they are not properly guided, they’ll go by average, because that’s how they work. And if you’re building by average, you should expect average results.
Engineering in general is about many things, and one of them is decision-making. Not based on gut feelings, or on what others are doing6, but on your own reality: available resources, requirements, and constraints. This involves not only looking around, but also reaching out to people, engaging in discussions, and digging through sources that may not even be documented. An agent can handle the practical part of these activities, but it doesn’t have enough context to make decisions.
Not to mention diversity. What makes the company’s culture is the people, their history, backgrounds, opinions, and vision. Agents may have the indexed knowledge of everything, but they won’t have the uniqueness of a group of people working together.
The opportunity
Software engineering is forever changed. And I’m glad I’m part of that. Yes, I loved writing code; I enjoyed every moment of it. Learning new languages, new ways of solving the same problem. But this is no more. Just like punched cards, floppy disks, and shared FTP servers are gone, writing code by hand, changing between coding and testing hats, is also gone.
That gives us a unique opportunity to be part of something great. We are no longer constrained by how much code we can output - which didn’t include just the writing part, but also figuring out test scenarios, use cases, ways some piece of code could fail, and what the implications of failure are, navigating code to gather context, reading through dozens of lines of a stack trace.
Writing code is no longer the bottleneck, but getting it to production still is7. Continuous delivery8 still drives the cycle to production, and CI pipelines are more important than ever9. There is no recipe for CD; each company is its own universe. It takes time, experimentation, and introspection to find what works best. LLMs can assist, but they won’t be in charge. This remains an engineering task.
It is now easier than ever to try different approaches, run prototypes, and benchmark. A different skill set is required.
What’s this blog all about?
I’ve been experimenting, learning and exploring for roughly two decades, and I think a lot of that can be shared. The same way I’ve learned from others’ experiences, I think it’s time I shared findings of my own.
In the coming weeks, I will share some of my personal projects: some born out of pure vibes, others from back when programming was still a thing. I’ll also talk more about my experience with AI in software engineering, from the early days of dumb autocomplete to frontier models.
Footnotes
-
The above quote is from DHH’s Rails World 2026 Opening Keynote, at 0:27. ↩
-
Systems thinking, Wikipedia. ↩
-
Peter M. Senge, The Fifth Discipline: The Art and Practice of the Learning Organization (1990). Senge calls systems thinking the “fifth discipline”, the one that ties the other four together. ↩
-
The “Hello, World!” program first appeared in Brian Kernighan’s 1972 tutorial for the B language, and was popularized by The C Programming Language (Kernighan & Ritchie, 1978). ↩
-
Vibe coding, a term coined by Andrej Karpathy in February 2025. ↩
-
Dan McKinley, Choose Boring Technology (2015). ↩
-
Gene Kim, Kevin Behr, and George Spafford, The Phoenix Project (2013). A novel that applies the Theory of Constraints from Eliyahu Goldratt’s The Goal (1984) to IT: speeding up any step other than the bottleneck doesn’t make the whole system faster. ↩
-
Continuous Delivery, Jez Humble. ↩
-
Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (2018). Based on the DORA research, it shows that continuous integration and delivery practices predict software delivery performance. ↩