A Revival for Test First, If We Don't Waste It

Using a coding assistant might turn out to be the best thing that has happened to Test-Driven Development (TDD) so far. This is the seventh post in my series about coding with an assistant.

For more than twenty years the objection to TDD was always some version of the same thing. No time. Too much typing. We will add the tests later. The assistant removes that objection. It types the test for you in seconds and it does not get bored doing it. On top of that, the path of least resistance with an assistant now runs straight through the test. I made that case in Fitness Functions for an AI Coding Assistant. To get useful work out of the assistant you have to tell it what done looks like, and a description of done that a machine can check is a test. TDD stops being the disciplined choice and becomes the efficient one.

Fitness Functions for an AI Coding Assistant

This is the sixth post in my series about working with an AI coding assistant. The earlier posts covered getting started, observations, rules, results, and communication. This one is about the gap between a rule the assistant might follow and a constraint it cannot get around.

Pipe Suggestions Straight to the Clipboard

My AI assistant suggests commit messages. For a while I copied each one out of the terminal by hand, selecting the text with the mouse and pasting it into my git client. It works, but selecting text in the terminal drags the line breaks along with it. The terminal wraps the text to fit its width, and those wraps come through as real line breaks in whatever you paste into. Then you have to clean them out.

If You Can't Finish Your Sentence, Neither Can Your AI

This is the fifth post in my series about working with an AI coding assistant. The earlier posts covered getting started, observations, rules, and practical results. This one is about something I keep coming back to: communication.

An AI Coding Assistant as a Force Multiplier

This is the fourth post in my series about working with an AI coding assistant. The rules from the previous post are in place. Now I want to talk about the results.

Spell It Out: Rules for an AI Coding Assistant

This is the third post in my series about working with an AI coding assistant. The first two covered getting started and early observations. This one is about what happened when I started writing down the rules.

AI Coding Assistant: More Observations from a Practitioner

In February, I wrote about my early experience using an AI assistant for Test-Driven Development, TDD. This is a follow-up. It may become a series, we'll see. A lot has happened in the six weeks since that post, and I have more to say.

TDD with an AI assistant, my perspective as a beginning practitioner

I have been practising Test-Driven Development for more than 25 years. The red-green-refactor cycle is second nature.

I have of course heard a lot about AI tools and LLMs over the last couple of years. The times I have tried them, I have not been impressed. Their proposals didn't compile. They seemed to solve the wrong problem. This was probably because they lacked the context of the project I'm working on. Honestly, a lot of what I have seen has been rubbish.

Not too long ago I saw a thread on LinkedIn where some people who I know really know what they are doing discussed their experience with AI assistants and specifically Claude Code. I decided to give it a try.