I did not manage to keep the cadence I originally planned for this newsletter. This year I am aiming to be more consistent about it. Here are some bits and pieces I gathered in the last period.

One big update from me that I have not yet shared on social media: I started an experiment called ChooseRuby.com. There is no content there yet, but the intention is for it to be a one-stop place for anyone who wants to discover Ruby.

Why call it an experiment? The Ruby on Rails web app I created for it (open sourced here) was entirely coded using Claude + Cursor. I did not manually edit any file. I want to see how far I can push the code quality with this approach. It can also act as a base for refactoring and talking about good practices in articles or videos as I always wanted to have as example a bit more complex code that does not feel didatic.

Please do not share the public URL of this project yet as it is still a work in progress. But you are welcome to contribute if you want to.

Seems like Ruby is pretty well positioned as a language that is token-efficient when used with LLMs.

If you have not yet used delta pager I think you should try it. It helps with seeing a syntax highlighting diff in both git diff and lazygit. After installing it add this to your ~/.gitconfig (you can also do this per project base)

And if you want to have it also in lazygit then add this line to your ~/config/lazygit/config.yml

I wrote an article where I posted also comparisons of before and after on Ruby code if you want to see it in action.

If you are doing some planning this week, consider adding checkpoints for upgrading your #Rails app

Specifically, if you are still running Rails 7.2T.x

Security fixes end: August 9, 2026

Working with LLMs to generate code has made me think about the relationship between tests and types.

Tests verify behavior through examples. They answer: Does the system behave as expected in these scenarios? They catch specific bugs but only check what you thought to test.

Types verify structure through constraints. They answer: Can this category of errors happen? They eliminate entire classes of invalid states but cannot encode business logic correctness.

When generating code with LLMs, this distinction becomes important I think. LLMs are surprisingly good at producing structurally valid code if you are matching a boilerplate case. The real problem is they often generate code that compiles and runs but does the wrong thing. They make wrong assumptions, miss edge cases, and misunderstand requirements.

A test suite that captures what the code should actually do catches these subtle logic errors that types cannot see. Types help ensure the code is structurally sound, but tests validate that the LLM understood what you needed.

Both matter, but when evaluating LLM-generated code, tests provide the confidence you need the most to decide if that should be merged or not. They verify that the system does what you intended, not just that it satisfies structural requirements.

Read the full article about Tests Verify Behavior, Types Verify Structure

Ruby's new identity statement caught my attention:

This is not about syntax beauty or elegance. It is about the developers who show up, contribute, and build alongside each other.

Every language claims community matters. Ruby is making it the central identity. In a world where a lot of resources online might be generated by LLMs I find it inspiring that the language choose to position itself a thing "where people gather".

It is not just poetic. It is a statement about what kind of knowledge-building Ruby values and I want to be part of this vision.

When writing RSpec tests, using let! can make it harder to understand what actually happens before a test runs.

Although let! looks convenient, it hides the fact that it acts as a precondition and obscures the execution order of setup logic.

This can make tests harder to read and reason about, especially when multiple let! statements depend on each other.

Moving preconditions explicitly into before blocks makes the setup clearer, easier to follow, and reduces cognitive overhead when reading tests.

I expended this in an article here.

Here are a couple of good resources to read to keep up to date with AI/LLM. They are not hyped but grounded ideas or tips and tricks that you can use. I don’t want to transform this newsletter into an AI newsletter so this is why I am groupping them here:

Seeing LLMs with a positive mindset

Antirez, the creator of Redis, wrote a thoughtful piece inviting us to approach LLMs and AI with an open mindset. The article resonates with ideas from creativity research: to see opportunities, we need to stay in an open mode rather than a fight-or-flight state. It is a perspective worth considering as we navigate these tools.

Read it here: https://antirez.com/news/158

Experimenting with AI and TDD

Thoughtbot published an interesting experiment on using AI to follow Test-Driven Development. What makes this article valuable is that it includes all the prompts they used, so you can experiment with the same techniques yourself. I have been exploring similar approaches, trying to make LLMs follow the red-green-refactor cycle, and this provides a good foundation to build on.

Check it out: https://thoughtbot.com/blog/prevent-the-robocalypse-with-tdd

Kent Beck demonstrating TDD with AI

Kent Beck, who invented TDD, recorded a session using Google's Antigravity IDE to implement a linked list in Python while forcing the tool to follow TDD principles. Watching the inventor of TDD work with these new tools offers a different perspective on how to integrate them into our workflow.

Watch the video: https://www.youtube.com/watch?v=ouGJSC5SdRQ

Getting concise plans from Claude

AI Hero shared a practical tip for working with Claude: add a line to your instructions asking for very concise plans. This small change helps generate smaller, more readable plans instead of overwhelming outputs. When working with AI coding assistants, this kind of constraint makes the collaboration much more manageable.

Read the tip: https://www.aihero.dev/my-agents-md-file-for-building-plans-you-actually-read

The Plan Mode Prompt from OpenCode

Someone shared a link to it and I think it is interesting to read it. Can be used also outside OpenCode if you need to:

https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/session/prompt/plan.txt

I had more things to include in the newsletter as there are almost 2 months since I sent the last update but with the amount of content published everyday I am sure I will discover many more resources.

Lucian