The Unreasonable Effectiveness of Claude Code

     

As I mentioned in my last post, I very much enjoy writing code “by hand”. It is the only thing I have consistently dedicated the last 30+ years of my life to. In fact, I have a hard time understanding what software engineering / building software products would even be if one didn’t have a solid grasp of, let alone enjoy, writing code.

However, the reality is that the point of building software isn’t to build software. The point is to make a product or a business. It’s to accelerate some real world process or enable some kind of commerce. Engineers often get hung up on linters, syntax formatting, some made up abstraction, or big O time complexity of some batch process that runs all night. While those things have a place, the end goal of software is to increase shareholder value and make the company money. It’s not my favourite thing to think about, but it’s the truth.

The exception to this might be open source and maybe academia, but even those places need money to operate. That money has to come from somewhere.

With that as the backdrop, let’s talk about using Claude code to write code for you.

Hype a Doodle Dandy

There is a difference between writing code and software engineering. Having an automatic nail gun and heavy equipment excavator does not mean you don’t need architects or people to operate those pieces of equipment. The double edged sword of AI tools is that anyone can, kind of, build things with them. Anyone motivated enough can get the base of something working - sometimes enough to make actual income.

If you look at it through that lens, it’s no wonder some people are bullish on AI taking everyone’s job.

If you are a software engineer and you look closely at one of these vibe coded applications, you can see that it’s going to have problems in a matter of months or years. And through that lens, it’s easy to see why some people are bearish on AI taking everyone’s job.

It is possible to vibe code an application, deploy it, and make money off that deployed application. Depending on the goal of the business, that might be enough. The ROI from having a buggy application vs. the income from the application might work out. From a business standpoint, the designer, engineer and DevOps people are already replaced.

I personally don’t think that is a good long term strategy or that that path will lead to a world changing or fortune 500 business; however, Meta just bought Moltbook and OpenClaw got bought by OpenAI for oodles of money; both of which were vibe coded apps… so… you tell me.

Unreasonably Effective

I just can’t stop writing code by hand. I get too much of a dopamine hit from it. However, I love learning new things, and I do need to keep up with the times so I got myself a Claude Code subscription and decided to take it for a test spin.

I asked it to do three things for me:

I thought that was a nice overview of what it could do. Modify some old code that hadn’t been touched in a long time, add a feature to an already existing code base, and create something totally new from scratch.

Spoiler: it did them all quite well.

Port an Old App

SC is a terminal spreadsheet application - think Excel in the terminal. I like using this application when doing some slight data analysis, but the original version wasn’t working on the arm64 macs. Most of the problems were just silly ANSI C to C99 issues, and I’d been slowly chipping away at fixing them.

Instead, I fired up Claude code and just said something along the lines of, “keep compiling this and fix all the errors it complains about until it works”. If you have a look at that diff, there isn’t anything magical that it really had to do. It was just a bunch of busy work and slight tweaks. The application now works.

Build an App From Scratch

I don’t want to talk too much about this one, because I am actually using it to process payments. Needless to say, with this one I looked very carefully at every single thing it did and had it create tests along the way.

I had it use this skill I made to have it break down the tasks and do them one by one. We talked through all the things it was going to do before it started doing them, and then, again, I sat there and verified every change it made. That was actually really tedious and tiring.

It tried to do a few really stupid things around 3rd party service keys, and some bad decisions around AWS infrastructure. For example, it was going to create a DynamoDB table for session management - the application didn’t need session management at all. At another point I had to stop it, and manually correct it (write the code myself to “show it”).

But all in all, it went from zero to a full AWS deployment with minimal intervention. I’d say it was about 85% hands off, but that 15% would have been disastrous.

Adding an API to an Application

L’Affaire is a little application I built for a friend of mine. It’s just a service that lets you create projects and add calendar events to the projects. The output is an ical feed which you can subscribe to. In the AI assistant world, this is helpful as it lets you add events to shared calendars without having to give actual access to anyone’s calendar directly.

(I didn’t squash this commit unfortunately, but if you want to have a look at the code you can see it in the commit log)

I pretty much let this one fly and didn’t try to intervene much. I still looked at every code change, but just mostly hit enter after a quick skimming of each change.

The only thing it did here that was kind of crazy was it tried to use the OAuth token for API access. It suggested people log into the application, copy the token from the browser, and then use that to do API calls - which is insane. I had to ask it nicely to make a bearer token instead, which it went and did.

Conclusion

So I tried Claude Code with three real world applications, and I was thoroughly impressed with each. However, I don’t think Claude would have “just done it” in any of those scenarios without a human in the loop. It would not have done any of them properly by itself, and in the case of the private application it would have leaked some catastrophically sensitive information.

In the hands of someone with a decent understanding of software engineering (and building an application that isn’t pushing the envelope in any meaningful way) I think these tools are very useful.

Can you vibe code a start up or a small business? Clearly yes, people are doing it now. However, to get to the next level, or to get there safely, I think you need a deeper understanding of how software and software engineering works. But replacing other types of business processes might be a different story. I’ll talk more about that next time when I document my experiments with “skills” (hint: they are unreasonably effective as well).