With Claude Code I feel like I can achieve more in less time. But other questions are surging. Before LLMs, building a complex feature meant a tradeoff: use an existing GitHub package or code it myself? How polished is the library, how much does security matter, many parameters. Now there is no friction. Claude Code writes in a few minutes exactly what I want. That old question is slowly disappearing, and in its place I'm facing decisions I used to hit only occasionally, now on a regular basis. Self host or Vercel? A VPS or is a Raspberry Pi enough? Shipping more things automatically forces these questions. The speed of the change in the last year has been overwhelming, fun, and with a real feeling of accomplishment. Along the way I've noticed some patterns. Unix is a fundamental and unquestionable building block, and Claude is amazing at it. I barely know enough Linux to stop an LLM from doing dumb things, but iterating on complex shell scripts with it until they're perfect is a fun process, and the reusability I get is insane. The limit is distribution: my scripts are tailor made for me, and they break on colleagues' machines with incompatible dependencies. Web technologies solve that. Everyone with a computer has a browser. But web tech is also where I have the most expertise, so it's where I scrutinize the LLM's code the most and sometimes cringe, the same way a Linux expert would cringe at my "perfect" shell scripts. When I know less, I only judge the outcome. When I know more, I judge in more dimensions. There are more of these decisions now. Performance: I recently built a server in Rust with little Rust experience, prototyped it in parallel with Zig, liked the Zig code more, but bet that Rust's constraints would pay off as the server grows. Nothing has broken so far. Compute: Vercel free tier for shipping in five minutes, Kubernetes with GitOps on Hetzner for professional work, a Raspberry Pi at home for the simplest possible self hosting. But all of that is context for the actual point. What people actually pay for I like to create things and solve problems, and I like getting paid for it. Usually the problems worth paying someone to solve are complex. Otherwise there would be no need to pay anyone. Complexity is the key, but complexity is also the enemy. When things are too complex, they blow out of understanding. If you solve a problem with a solution of enormous complexity, maybe you solved a problem, but you created another one. The nature of the problems I work on is that they are not clear at the start. The reasons someone decides "ok, I'm gonna pay someone to solve this" are infinite, but if they had a perfect step by step instruction manual, it's hard to imagine they wouldn't just do it themselves, or hire someone temporarily to follow the list. Given, of course, that the list is guaranteed to work. I am paid not only to solve a problem, but to define it, and to create the instruction list to solve it. Only after that can I solve it. I call that systematic problem solving. It's something AI cannot do by itself. We can set up AI agents and workflows to tackle it, but it doesn't happen on its own. That's what people get paid for, that's what creates value, and that's what moves humanity forward. Complexity is the crumbs of solved problems Systematic problem solving generates complexity. I like the phrase "fire bullets before cannonballs". First you try simple solutions. As they fail individually, you start combining them and twisting them. A lucky shot is an elegant solution: everyone understands it, everyone can apply it, it covers all cases, and it's permanent. A less lucky shot solves the problem, but things get left behind along the way. The combination of twisted approaches that solved something novel sticks around, obviously, because it solves a problem. But that spaghetti of solutions also becomes something to manage. That is how complexity is born. The crumbs of a problem that was solved. Building blocks leave no crumbs I like to think of building blocks as pieces that leave no crumbs behind. Pieces that disappear and fade into the background. No one needs to think about them, even when they are everywhere. Creating a building block is very difficult, and there are not many of them. A building block is a tool or technology that I have to force myself to think about, for a reason. Without that reason, it stays hidden from my consciousness. Building blocks are also scoped. There is a clear boundary around them. I consider Linux a building block, but I cannot use it in my acoustic guitar. I cannot use it in my microwave. It's obvious. There is zero or very little overhead in thinking about when I can use it or not. It's almost instinct. So two questions to recap: Does it disappear when I use it, unless I force myself to think about it? Is it instinctive to know when I can use it and when I can't? In the era of using Claude Code to solve a lot of problems, I want to force myself to think about building blocks, and to aim to build those. Emergence, not complexity I think when you manage to create multiple building blocks with clearly defined boundaries that fit together, you get emergent behaviors. Things that are impossible to imagine until you see them emerge out of the blocks and the space where they live. I want to distinguish emergence from complexity. Complexity is hard to manage and it's in the way. It makes it difficult for people to wrap their heads around things. Complexity is very common, it is the norm, and it is what we want to get away from when solving problems. Solve problems with building blocks that fade into the background. Define clear boundaries around them so you automatically know when to use them. If done properly, something emerges, and you're nature creating more nature. I think that's what nature is as well: elegant, made out of simple things that play together under specific rules. One last thought. A package you send via DHL can be fragile. What is the opposite? Robust? Nope. Robust is neutral. Antifragile is the opposite: something that benefits from chaos and mess. I think building blocks are robust. They don't benefit from chaos, but they don't get affected by it either. Emergence, though, is antifragile. It benefits from chaos. But those are thoughts I want to develop later, when I finish reading Antifragile.
