I Hate To Say This, But Vibecoding Actually Kinda Works*

*for me personally

I'd hoped I'd never have to make this post. I've built my entire personality on being a good programmer. And to have this machine that this away from me…

It's reprehensible.

So I guess the hype finally got to me and I tried out the new "Claude Code" thingamajig all the cool kids are raving about. I signed up for the Max plan (which is $135 AUD PER MONTH btw) and decided to look at some long-standing issues in Clorinde.

But first you need to make a CLAUDE.md file, which according to the documentation:

[…] is a special file that Claude automatically pulls into context when starting a conversation. This makes it an ideal place for documenting:

• Common bash commands
• Core files and utility functions
• Code style guidelines
• Testing instructions
• Repository etiquette (e.g., branch naming, merge vs. rebase, etc.)
• Developer environment setup (e.g., pyenv use, which compilers work)
• Any unexpected behaviors or warnings particular to the project
• Other information you want Claude to remember

I basically just copied the file that the Zed editor uses and asked Claude to make a similar one to that after going through the project. This is the result, and honestly it didn't do bad job, I had to look over it a few times and make a few changes - mainly around the development workflow, but it was a good effort.

Now it's time to attempt some real features. I've had a few easy ones I've basically just been too lazy to work one. I started with this commit: feat: ability to change container image for schema command.

Basically, previously the schema command runs codegen against a Postgres Docker container (the postgres image specifically), I wanted the ability to run it against any Docker image ( timescale for my particular use-case). Claude basically got it first try… kinda - I added a test for using the Timescale image and found out that the wait we do to check if the database is ready is not long enough for Timescale since it has a lot longer of a startup time. So I then had to ask Claude to add another option to determine how long the wait is. I don't think this is any-ones fault for "missing" that on the first go around, that's kinda just how programming goes sometimes.

Next I decided that having to wait several seconds for codegen because Timescale was so goddamn slow to start was actually really fucking annoying. So I wanted to implement a feature one of the projects co-maintainers had been talking about wanting for a while - running on the codegen against a local Postgres instance but creating a new database. So previously, there were two options for codegen:

1. schema: Run a Postgres Docker container, import a schema file into it, and codegen the types/queries.
2. live: Connect to an existing Postgres server and codegen the types/queries.

This new command should connect to an existing Postgres (or Postgres protocol compatible) server, import a schema file into a new database, and then codegen the types/queries. This has the added benefit of not requiring Docker/Podman, and most other libraries of this sort do it like this as well.

Since this was a bigger feature, I decided it should go into a PR instead: #115. And again, no real issues in how Claude implemented it, and it even updated the docs which was nice. I mean, I did edit a few things, but those were minor details - I really had no major problems with what Claude generated.

And that concerned me.

It's time for a real challenge. Now I really wanted to see if it could tackle issue #86, "Define nullity for composite fields". I won't explain it here, the GitHub issue does it well enough I think.

This is an actual difficult problem because it deals with the parser. I fucking hate dealing with the parser. But I did want to give Claude as best of a shot at success as I could give it, so I put some extra upfront thought into this and decided it might be good to bust out some good ol' "test driven development".

I updated the existing nullity tests with new queries that would implement the required features to call the issue completed, told Claude how to run them, and to not stop until the tests were passing.

It did #116 in like an hour.

Now to be fair, I was actually helping it along the way. Claude Code requires that you review and approve all code changes (although there is an option to auto approve, I do not recommend that), so I was giving feedback and having it explain things to me (mostly explanations on what it's actually trying to accomplish) basically the entire time. But it generally picked up things fairly quickly and to be honest, if I was doing this on my own, it would have taken the entire day at least.

I've also been using Claude Code with a completely new project which is being built from the ashes of Numby, which I don't want to talk about yet, but I'll say that Claude has provided a fairly similar experience to working with it as it has with Clorinde.

So that's that, I'm going to cut it here. And I'll be honest, I am very tired of constantly hearing about AI; I imagine you are too. So here, I'll do you a favour and give you a few opinions you can take for yourself so you can ignore everyone else.

• Is AI the most important human invention since the baguette? No.
• Is AI going to take my job? No.
• Is AI useless? No.
• Is AI worth $135 AUD per month? Probably just in terms of time savings alone (one hour of my time is $150 AUD, you can do that math from that). But I don't feel good about it.
• Is AI a plagiarism machine? Yes.
• Is AI a better programmer than me? No, but I am slower.
• Is AI "democratising" software engineering? No. Unless you consider a slew of garbage code prompted by people who have no understanding of programming, without the skills necessary to be able to instruct the LLM towards good practice to be software engineering, then maybe it is.

Seriously, if you are a junior programmer - I do not suggest you use AI, or use it extremely carefully.

Update 2025-07-24: It has come to my attention that what I was describing is not actually vibecoding, and that vibecoding is when you let the LLM do what it wants without any additional input, which I specifically said not to do.

Oopsie poopsie! Guess you got click-baited! I sawwy.