A Java Geek weekly 155

I didn’t know about the AI-managed vending machine. I wish I had the capital to try the full-fledged version on an actual business.

TIL:

My blog is using PlantUML. Until now, I had to install dot in my Docker image. With one additional line in PlantUML diagrams, i.e., !pragma layout smetana.

The author’s answers are as good as any. As for me, I’m clueless. I learned a lot by trial-and-error, but what if the LLM makes errors, but you don’t learn anything from it?

I wanted to teach me Gleam because it runs on the BEAM, but its syntax is pretty much Rust-like. I also wanted to leverage my OpenTelemetry Tracing demo repo. In the end, I only prompted, it worked. There was no tension or challenge for me to overcome and learn from it, and I learned nothing.

This is the new world we live in.

Very interesting read, especially because my (limited) experience is the opposite on the correctness part. I used the same models, Claude Opus 4.1 and 4.2, with both Claude Code and Copilot CLI. On every attempt, I felt that Claude Code offered the outcome faster.

Disclaimers: I didn’t implement the same task with the two harnesses. There were different tasks, and I didn’t measure anything, least of all the tokens consumption. Hence, the word above "felt" is the exact word I mean.

I think every team lead has the same issue at the moment. How do we un-pile the ton of PRs currently waiting?

Writing tests is an economic problem: do you spend more money by writing them and catching bugs before production, or by saving on the writing?

I happen to have written a book on Integration Testing, so I can speak a bit on the subject. The problem is of integration tests is threefold: slow, fragile, and flaky. These properties means they cost a lot to run.

In any case, I want to try Property-based Testing.

I don’t know how easy it would be to implement it in Rust, but I must admit that I love it in Kotlin.