Oh look, the first real post of the site and I am already talking about LLMs. I want to get off.

So, AI (sigh) is gonna replace us all

Or at least they say so. I don’t like being surprised by stuff, so I am looking into it as it evolves for as much as it makes me want to puke. This thing is here to stay it seems, and we need to learn to use it. At least if we want to get paid (aka: eat).

Today, I wanted to see how it fared on creating a full project. I know I am being a prick, as the space where these tools fare best is to implement small changes into wider codebases. But also I am being bombarded by ads on “Everyone can make sites now, even without knowing any programming language” (good targeting there Youtube), and I am a firm believer in having to try something before shitting on it, so…

The plan

I had for some days an idea about a little tool: mdsh. I’ll probably write at some point about it, but in short is a way to run snippets of shell code in a markdown document, the main application being a self-documenting setting up of a dev environment.

The idea shined to me as the perfect test ground for this experiment: it has a small and well defined project scope, I can list what dependencies to use off the top of my head so I can check the LLM output, and it is easily tested as it is a fully self-contained tool.

While the claims say that you can just “not look at the code”, I like to look at the code. I decided to write a README.md with the project full description, and a CLAUDE.md with the stack I wanted and some general guidelines on how I wanted it to handle the project. In particular, I instructed the LLM to follow a TODO.md point by point, instead of implementing the whole project at once.

Then I asked it to generate the TODO.md by itself. It gave a somewhat sensible plan, so I started to prompt it to “run the next point” until it reached the end. I sincerely think this is giving it the most chances of not triggering me and being thrashed on. Also, creating a viable product.

It worked?

TL;DR: yes. It introduced bugs, but under steering it made a functional tool.

Now that the LLM fanatics are satisfied and stopped reading, the details. The tool of choice was Claude Code, with under the hood Z.AI GLM 5 or 4.7, I don’t know if I am using the new one yet.

The documents I linked before needed little editing. The largest edit was adding links to the dependencies documentation, as the LLM was either not using functionalities or running into repeated errors.

Repeated errors were the main reason of steering, as it tended to go into a loop of fixing the symptoms, instead of addressing the issues. Error handling in particular became quickly a case of “format a string and put it in any variant that has a msg field”, before I steered away from it. I needed to add lines to the CLAUDE.md to ensure this wouldn’t happen, although this could be attributed to me having a particular idea in mind and wanting the project to adhere to that.

The main pain point was instead the model overdoing. It was really rare that the “do this point of this list” ended up doing only that point. Many times the model encountered points that it already did in previous iterations, and this seems to be a common theme. Worst thing is: you need to address this directly. In absence of specific instructions, the model marks the already done parts as already done, even if they are partially or not satisfactorily done.

Tests instead went… poorly, mostly. The test were created, and after being given llvm-cov as a tool it made sure the test coverage was well beyond what a human maintained code would ever have. Problem is, none of its tests caught actual bugs. It mishandled user input (piped the commands to the shell instead of creating a file and passing it as a parameter), and of course that was not tested. Generally, tests generated seem comprehensive, but end up testing only trivial cases. It rarely, even in a toy project like this, follows the essential testing line of reasoning “how this can go wrong?”. Or it follows it and utterly fails at it. It worries me because the resulting test suite seems impressive, but does almost nothing.

Giving the model access to read git commands went as usual very well. git log is a monstrously useful tool, and LLMs can use it to get things very right about the development process. Write git commands are a bit sketchier, you are putting your name and signature on something you did not do. The commit message, while pedantic and badly focused, are somewhat better that what you would be bothered to do on a low stake project.

Conclusion: do I need to learn farming?

Nah. While I am sure the model could create a working MVP, it kept trying to make choices that works exactly into that: an MVP. It gave me something I consider to be workable and I can somewhat trust only because it had someone with the full project in mind looking at it.

I would have written it, just slower, and 1) actually have fun in doing it 2) learned something. I guess it made me more productive from a “product generated now” point of view, by removing value from the “product generated tomorrow”. I’m trying to see this from a professional viewpoint, cause again thinking of this personally will only make me retch.

In sum: these things need senior supervision, and are for having to ship code now and without having stakes in the human learning process. I believe you are losing human value in the long run, especially if a junior uses it.