.png)
The Magic
With the rise of large language models, it has never been easier to take an idea out of your head and turn it into something that runs. In theory, that should be a good thing. But after spending the last few months using these tools and building many of the things I had always wanted to build, I am not so sure anymore.
There is something genuinely magical about it. Refactoring an entire application in a single day feels magical. Debugging a codebase that would have taken weeks to understand feels magical. Turning an old idea into a working prototype in a weekend feels magical. But when it comes to side projects, I keep asking myself: is this always good?
The Cost of Shipping Too Fast
Over the past few months, I built project after project. Things that once would have taken months, maybe even years, were suddenly done in days. The strange part is that I often finished them without learning much, without sharing much, and sometimes without even wanting to keep going. In one sense, that can be useful. I did not spend years discovering that an idea was not viable. I found out in a few days instead.
Still, it made me uncomfortable. If a side project has no real weight, no meaningful complexity, and no demand that I stay with the process, what am I actually getting from it? Having a finished project while learning almost nothing from it does not feel especially valuable to me.
Our current culture tends to treat productivity as the only attribute that matters at work. Knowledge and craft still matter, of course, but mostly when they are attached to output. And when I say productivity, the uncomfortable implication is usually capital accumulation. That feels a little depressing. Our ancestors dreamed of wisdom, immortality, and greatness. Today, we often dream of turning productivity into money.
Slowing Down on Purpose
That thought made me want to slow down. I do not want to stop building, but I want to stop treating speed as the point. I want to spend more time on projects that help me deepen my understanding of design systems, architecture, and data-intensive applications. I am reading Designing Data-Intensive Applications slowly, and I am planning a flexible project where I can gradually apply these ideas with care.
I am not rejecting vibe-coding tools. I would never be against modernity for its own sake, and it would be a waste of time to write every piece of boilerplate by hand just to feel virtuous. But I do want to use these tools in a more spec-driven way. The architecture and design of software prepared for data-intensive work is still something I want to grow in my own repertoire.
So I am trying to learn instead of only producing quickly. I hope that is not the wrong bet. We will see.