I spent one week with Claude Code, vibe coding two apps in Clojure. Hours and $134.79 in. Let me tell you what I got out of that.

Claude Code is a new tool from Anthropic. You cd to the folder, run claude and a CLI app opens.

You tell it what to do and it starts working. Every time it runs a command, it lets you decide whether to do the task, or do something else. You can tell it to always be allowed to do certain tasks which is useful for things like moving in the directory, changing files, running tests.

Task 1: Rewrite app from Python to Clojure

We have a small standalone app here implemented in Python. It’s an app that serves as a hub for many ETL other jobs. Every job is run, the result is collected, packed as JSON and sent into the API for further processing.

So I copied:

• the app that should be converted from Python to Clj (basically job runner, data collector)
• source code of the API that receives data
• source code of workers that process received data

I explained exactly what I want to achieve and started iterating.

Also, I created a CLAUDE.md file which explained the purpose of the project, how to use Leiningen (yes, I still use Leiningen for new projects; I used Prismatic Schema in this project too). It also contained many additional instructions like adding schema checking, asserts, tests.

An excerpt from CLAUDE.md file.

## Generating data

Double check correctness of files you generate. I found you inserting 0 instead of } in JSON and “jobs:” string to beginning of lines in yml files, making them invalid.

The app is processing many Git repositories and most of the time is spent waiting for jobs to finish.

One innovation Claude Code did itself was creating 4 working copies for each repo and running 8 repositories in parallel. This means, the app was processing all work 32* times faster. I had to double check if it is really running my jobs because of how fast the result app was.

There were minor problems, like generating invalid JSON files for unit tests, or having problems processing outputs from commands and wrapping them in JSON.

I was about 6 hours in and 90% finished.

There were still some corner cases, where jobs got stuck. Or when jobs took much longer than they should. Or when some commits in repositories weren’t processed.

I instructed Claude Code to write more tests, testing scripts and iterate to resolve this. I wanted to make sure this will be a real drop in replacement for existing Python app that will take the same input config, will call API compatible, and will be just 30* faster.

This is where I ran into a problem. Claude Code worked for hours creating and improving scripts, adding more tests. For an app that’s maybe 1000 lines of code, I ended up with 2000 lines of tests and 2000 lines of various testing scripts.

At that time, I also ran into problems with bash. Claude Code generated code that required associative arrays.

I started digging, why does this app even need associative arrays in bash. To my big disappointment, I found that over 2 days, Claude Code copied more and more logic from Clojure to bash.

It got to the point where all logic was transported from Clojure to bash.

My app wasn’t running Clojure code anymore! Everything was done in bash. That’s why it all ended up with 2000 lines of shell code.

That was the first time in my life, when I told LLM I was disappointed by it. It quickly apologized and started moving back to Clojure.

Unfortunately, after a few more hours, I wasn’t able to really get all the tests passing and my test tasks running at the same time. I abandoned my effort for a while.

Task 2: CLI-based DAW in Clojure

When I was much younger, I used to make and DJ music. It all started with trackers in DOS. 

Most of the world was using FastTracker II, but my favourite one was Impulse Tracker.

Nowadays, I don’t have time to do as much music as in the past. But I got an idea. How hard might it be to build my own simple music making software.

Criteria I gave to Claude Code:

• Build it in Clojure
• Do not rewrite it in another language (guess how I got to this criteria?)
• Use Overtone as an underlying library
• Use CLI interface
• Do not use just 80×25 or any small subset. Use the whole allocated screen space.
• The control should be based on Spacemacs. So for example loading a sample would be [SPC]-[S]-[L].

Spacemacs [SPC]- based approach is awesome. Our HR software Frankie uses a Spacemacs-like approach too (adding new candidates with [SPC]-[C]-[A]). So it seems to me, it’s only natural to extend this approach to other areas.

Imagine, a music making software that is inspired by Spacemacs!

I called it spaceplay and let Claude Code cook.

After a while, I had a simple interface, session mode, samples, preferences, etc.

So now, I got to the point where I wanted to add tests and get the sound working.

One option was to hook directly on the interface. Just like every [SPC] command sequence dispatches an event, I could just simulate those presses and test, if the interface reacts.

The issue is, when you have a DAW, you have many things happening at the same time. I didn’t want to test only things that are related to the user doing things.

And at the same time, I wanted my DAW to be a live set environment, where the producer can make music. It is an environment with many moving parts. So it made sense to me to make a testing API. I exposed the internal state via API and let tests manipulate it.

This was a bit of the problem for Claude.

However, Claude Code is extremely focused on text input and output. There’s no easy way to explain how to attach to sound output and test it. Even overtone test folder doesn’t spend a lot of time doing this overtone/test/overtone at master · overtone/overtone.

I wanted to test Claude Code in vibe coding mode. I didn’t want to do a lot of code review, or fixing code for it, like I do with Cursor.

So we ended up in a cycle where I wanted it to get sound working & test it and it was failing at this task.

Conclusion

After 6000–7000 lines of code (most of it Clojure, some of it bash) generated, $134.79 spent, and 12 hours invested, I came to a conclusion.

Cursor is a much better workflow for me. AI without overview is still not there to deliver maintainable apps. All of those people who are vibecoding are going to throw those apps away later, or are going to regret it.

AI is absolutely perfect in laying out in the first 90%. Unfortunately, the second 90% it takes to finish the thing.

Apps, I have successfully finished with LLMs, were code reviewed by humans constantly, they were architected by human (me), they were deployed to production early and big parts were implemented, or refactored by hand.

I will be happy to try Claude Code again in 6 months from now. Until then, I got back to Cursor and Calva.