This week, I’ve been coding a lot with the new “wonder tool,” Claude Code, and I’m constantly oscillating between massive enthusiasm and, well… pretty serious disillusionment. I built two not-so-small web apps: a time tracker so I can quickly log my days, and a weight tracker where a few friends and I document our weight loss progress every Friday.

I also built a tool to quickly access my Claude session at home from my phone, and another one to get push notifications when Claude is done with a prompt. I mean, you can now realistically code a bit on your phone while out for a jog or picking up some bread rolls.

By now, I’m actually convinced that tools like Claude will change the way we code in the long run, even if it’s just for certain things. These tools are definitely far from perfect, but I believe the world of software development will adapt to them, because the promise of higher productivity is simply too huge to be ignored.

So, is it actually more productive? That’s a surprisingly hard question to answer. I think so, but I’m not sure. I’ve definitely had one of my most productive weeks in a long time, implementing some ideas I’ve had for ages. That said, I also had a sneaking suspicion that I only started all these little projects because I really wanted to test out my new toy, Claude Code, and was willing to work late into the night for several days straight. But I also got these projects into a useable and publishable state, which is far from what happens with all my side projects.

What I can say for sure is this: these tools are much better suited for some projects than for others. My impression is that you have to be able to explain exactly what you want. Do this, then do that, then put it together like this. On the other hand, you also have to be willing to be flexible. My weight tracking tool was supposed to get an Excel export. Instead, it now has a CSV export, a JSON export, and a SQLite export, simply because Claude decided to wildly misinterpret my prompt. Sure, I probably could have gotten it to actually make an Excel export, but it helps enormously to just tell yourself, “well, three export buttons are better than one.” The more you have to stick to an exact specification, the more rigid the design, the harder it will probably be to get what you want out of Claude. Organizations that value their structures might just get another complex and error-prone layer, and could perhaps become even slower, whereas flexible, small teams could certainly get a lot out of it.

To get anything useful, you have to be very flexible in your expectations but, at the same time, very, very specific in describing what you want, otherwise you just get silly nonsense. At one point, I told Claude I wanted a Caddyfile and a Docker container running Caddy and my server. It did that, and nothing worked. It was only when I said: “Generate the static site, compile the server, then build a Caddyfile that serves the static files and sends API requests to the server we just built, and then pack all of that into a Docker container”… that it worked on the first try.

I don’t think coding LLM tools like this will replace software developers. For one, the generated code is way too bad for that. For another, it takes a lot of experience to formulate the prompt in such a way that the code is just good enough in the places that really matter so it doesn’t immediately fall on its face.

But I also believe there are a ton of use cases where coding LLMs will definitely have their place. Where it’s okay for an app to look pretty generic, not work 100% perfectly, and be a bit quirky, but it’s still better than no app at all. The world runs on cobbled-together Excel macros and Python scripts built by some guy who learned to code out of boredom and has no idea what version control is. Maybe these tools are just the thing to make a dent in the never-ending backlog of digitizing processes.