How I do AI
You can see I've been busy the past months, because it's been a while since my last post. I've been working hard on a new release of MonkeyCI, with mostly speed improvements but also a new underlying infrastructure. This required a lot of refactoring and some rewriting. This is not always very exciting, to say the least.
The Good
Just like most developers nowadays, I've also been using AI from time to time. Some use it all the time, some hardly use it. I think I belong more to the latter category. Now I have used Claude in some side projects, and the results are mostly excellent. But I almost always had to correct something. Sometimes its assumptions were wrong, or some code wasn't as efficient as I thought it could be. Call me old-fashioned, but I hate wasting CPU cycles!
But equally it has impressed me with how well it did understand my intentions. I'm a big fan of TDD, and so I've also tried doing that with an agent: I wrote the tests, Claude implemented the code. Once I made a mistake in one of the tests, and the AI noticed it and modified the test! It deduced correctly by means of the test description that it did not verify what it was supposed to verify.
What I use it mostly for is for stuff I find boring. Mailman is a library for writing event-driven applications. It has a core, but also different dependencies for various messaging implementations (like JMS or NATS). I wanted to add an implementation for core.async as well, but it was going to be very similar to the manifold version. So I just told Claude to do it, and it executed its task brilliantly. It saved me several hours of coding. But I also had to do some corrections here and there.
The Not so Good
So it's not all sunshine and rainbows. When I was technical lead of DN, the company I co-founded back in 2004, what I found most boring about my job was having to tell people what to do, and then reviewing their code and suggesting improvements. But what is agentic coding in essence? It's telling the AI what you want it to do, and then doing code reviews. Boring! I'm a developer, I want to code! I get a great deal of satisfaction from thinking of the best, most elegant way to write an algorithm. That's the main reason why I like Clojure: it allows me to write concise, elegant code. Using an AI takes most of the fun away from that.
Another thing I noticed when having an AI generate code is a feeling of loss of control. When writing code (if you do it yourself), you usually know exactly what you did, and why you did it. At least at first — that's why you need comments! But when an agent writes it, the only thing you can do is review the code it wrote. And that can never give you the same level of knowledge you reach when you write it yourself. And to me, that's a really creepy feeling. When other people write code, you can ask them why they did it like that, but an AI doesn't really "know" why it did. Whenever I did ask it something, it immediately assumed I wanted it to correct it. So it didn't give me a valid explanation, it just started to rewrite the code again. The AI is clearly meant to "please" the user. One of the advantages of working with a team (a human team) is that you can bounce ideas off of each other, you can go into discussions and the result will be better because of it. That's something I'm missing with an AI.
Conclusion
So to me, it's a mixed bag. It's great to take the boring things out of your hands, or the stuff you don't really know much about. Or it can explain something to you and then you can ask it to go into more detail about one aspect of it. But it's really not a good replacement for a human developer, as I hear is now happening in many companies. It's a great tool, but it still remains "only" a tool. A very powerful tool, that is. The end responsibility still lies with the human developer. And you know what they say about great power...
What I think the future of AI will bring, once the dust settles, is it will remain an excellent assistant to developers (or any worker). But it will finally also bring about true user-friendliness of software. Gone will be the days where you had to take courses to get to know an application. No longer will you have to rummage through countless menu options to find that feature you need. Instead, you will be able to ask the application itself and go into discussion with it. Finally software will deliver what it has always promised: help the workers in doing their jobs instead of adding more work! Well, if we apply it correctly, that is.