Thomas Vogelaar

Slopware

Over the past couple years I’ve frequently been critical of AI coding tools, but it’d be silly to not admit how much attention they’ve captured in our industry. The articles, speeches and proclamations that these tools will completely upend our industry are relentless, and yet… I haven’t seen it? Sure, there are tons of posts of developers making their next million dollar SaaS product, or “one-shotting” some app you’ve never heard of. But it’s been a few years now, has the industry really changed that much? This is a genuine question, I’m honestly not sure.

I think like a lot of developers I’ve landed in a place of using AI as a glorified search engine. Figuring out exactly what keywords you need to type into Google for whatever specific problem you’re facing can be time consuming, and tools like ChatGPT and Claude often do an incredible job at understanding very vague explanations and pointing in the right direction. But I’m still writing the code.

Around me I see these posts - as we all do - of developers proclaiming their 10x productivity and I want to know more. I’ve tried on several occasions now to dig into these tools, and find myself frustrated. My main focus in this endeavour for the last few months has been Claude Code. I’ve used it on and off for personal projects, but it’s always left me feeling unsatisfied.

The Problem of Context and Control

I’ve worked on codebases of all sizes, from tiny startup projects to enterprise systems. One constant allowing me to work efficiently on all of these is context. Having a good understanding of the system, its purpose, and how it’s composed allows me to work efficiently on new features, bug-fixes etc. And I think this is where my problem with tools like Claude Code has been.

Each time I try and take more advantage of these tools, I find myself slowly giving up more and more control to Claude to write new code. The more I do this, the less understanding I have of what I’m actually working on. I can slowly feel my understanding and control over the code slipping away. When I try and fight this, I just end up using the tool less.

I think to some extent this would be manageable in a larger codebase at work (not that I’ve tried yet), because this feeling already exists to some extent when working with others. I think the difference though, is that when you work on a codebase with other people, you’re still actively coding yourself. You end up gaining the same context over time as you interact with the code written by others, both through code review and through your own changes. I just can’t get that feeling when working with Claude Code, and I can’t figure out why.

One-off Slopware

A notable exception to this however is what I’ve been referring to in my head as “slopware”. I think I’ve seen this term used a few other places to mean different things, but in my head it’s any one-off software you can slap together with AI that doesn’t need to be maintained.

A good example of this is when working with some data (say tens or hundreds of thousands of rows), and you want to quickly visualise it to get a better understanding of what the data looks like. Sure, you could spend a couple of hours writing a collection of various queries that you’ll never use again, but with these tools it’s simple to put something together in a few minutes, see what you need to see, and then toss it all away.

Unfortunately this relegates AI tools to a sort of auxiliary role; assisting in some menial tasks here or there but not actually increasing velocity in general that much. Definitely nowhere near the 10x performance improvements that some profess.

What’s next?

I’m not giving up on this just yet. I’d love to hear from anyone who reads this. How have you used these tools successfully? What am I missing? Please reach out at [email protected] or send me a message on LinkedIn.

In the meantime, I think I’ll be trying the following:

One-off Bugfixes

I think I’ll try assigning Claude small, contained bugfixes. Claude Code has a github actions feature that allows you to tag it in issues and PRs. Maybe keeping it contained to these small isolated changes removes some burden while allowing me to focus on the details that matter.

Code Review

I’ve already used it here and there to review my own PRs. I might try moving this a step earlier and have Claude review commits before PRs are made. I’m hesitant to let it make too many changes itself, but perhaps I should allow it to be more critical of my own work.

Planning and Delegation

I’m not really sure how to approach this, but I’m going to try and place more emphasis on breaking down larger tasks into very small components. This would allow me to assign perhaps one or two discrete tasks to Claude (probably the less enjoyable ones) and let it churn away in the background while I complete the rest.

This seems to me what’s most likely to pay off, but also the toughest to implement. Especially tough will be figuring out how I can let Claude do this without it stepping on my toes if we’re working on the same repository.

Interfaces

When working on personal projects (which I never finish) I often end up wasting a ton of time building the UI, making tons of choices that don’t end up mattering all that much (component libraries, layouts, the works). This seems like something worth delegating to Claude so I can focus on the actual logic underneath. This doesn’t really translate well into a professional environment though.

Final Thoughts

As critical as I can be of these tools, I really do want to embrace them however I can. It’s clear the industry is heading in this direction whether we want it or not, and I don’t intend on being left behind. In saying that, I do expect that for the next few years the quality of software will decline noticeably as developers grapple with how to use these things effectively. Expect to see a lot of security incidents and even more bugs. At some point we might all be out of a job, but I don’t see that any time soon.

Tags: