May contain traces of AI

It’s a horse!

2026-01-04T00:00:00+00:00

I’ve been walking for fun and profit all my life. From the exciting first hikes where everything was new and each step a small victory, to the routine daily walks that feel like errands with the occasional challenging trail or interesting detour. I often heard about some new gear that would change walking forever. It would be easier, faster, not as tiresome. New paths and shortcuts that would make popular destinations easier to reach. Most of those promised revolutionary improvements felt incremental at best. Except for shoes, but that was so long ago we barely remember the transition. The barefoot crowd kept insisting it wasn’t real walking. That crowd doesn’t exist anymore. Even the legendary Don, who describes all his specialized techniques for barefoot hiking, uses shoes when he’s out on a trail. I have to admit that there are a few rare cases where barefoot is better, but most of us won’t encounter those scenarios in our whole lives.

And then the rumors started: people saying they were able to get on a horse and it would walk for them. “No way that’s safe,” we thought collectively. We heard about all the horrible accidents. “Told you!” said the seasoned hikers loudly and gleefully, with a hint of relief. The evil beast was impossible to guide properly. Walking would always be faster.

I had to try it for myself. I had a companion dog for some time at that point. It would help me find my way along the trail, but it helped me about as often as it got lost. I learnt some tricks to help him focus, like throwing a stick to where I wanted to go and watching the dog zoom there successfully almost every time. How hard could it be to figure out how to use a horse? It was hard, tiresome, and mostly a pain in the butt. Walking was definitely faster, but this crazy beast was new and exciting!

I said I walk for a living. However, that’s not entirely true. I actually run trade routes. Walking is a large chunk of the work, but it’s probably the lowest value work. Figuring out what trades to make, which destinations to visit, and how to route efficiently is where the value is. Walking there, once you’ve walked many many trails, is just a chore. But I digress.

I started to get better at riding the quadruped, and slowly but surely it was getting easier, less painful. I learnt about saddles, reins, different riding techniques. I found myself guiding it better, nudging it successfully through every checkpoint and reaching my destination quicker while enjoying the scenery. I was convinced horses were here to stay. My horse Claudio would be with me on all my adventures as far as I could tell.

I would tell fellow hikers about my experiences. When talking to a hiker who was going through the same thing, we would immediately start sharing tricks and have a laugh about some crazy quirk we noticed in these majestic creatures.

I would tell horseless hikers about these beasts, how weird it was in the beginning, how different it was from plain walking, but how enjoyable the trails were becoming again. I heard so many dismissive rebuttals.

“Walking is faster.” Not for me. Not anymore. Not for many of my usual destinations.

“But that’s not proper hiking!” I like this better. I get to explore more routes and destinations. I venture to places that used to be too far for me to reach in a reasonable time. Things like crossing a wide, shallow river are super easy, barely an inconvenience now.

“I tried a saddled horse with reins and it wasn’t that fast, and still a pain.” Yes, you still need to learn how to ride for it to be fast and painless.

“But you have to feed and take care of the horse.” Yes, but I transport things for a living. Having a good horse pays for itself in a single day! (At the current hay prices.)

I don’t think I’m even close to taking full advantage of my horse. I’m hearing wild things about what people are achieving using horses. Carts attached to horses, using horses to guide herds of horses. Sounds crazy, but it’s probably true. I still walk sometimes, but nowadays I prefer riding.

Shoes, Dogs and Horses

I learnt to program in BASIC using an old Talent MSX around Y2K. Soon after, I was using Turbo Pascal in early high school. But it wasn’t until I was programming PIC microcontrollers in assembler, before moving to PICBASIC and C, that I really appreciated how large the productivity jump was between plain assembly and a compiled language.

By that time, it was common knowledge for software developers, but that wasn’t always the case. People complained about early compilers, about the horrible assembler those evil programs would produce, about how that wasn’t real programming. Many years later, it’s unthinkable to write plain assembly except for very niche scenarios. A compiler becoming self-hosted is a celebrated milestone.

When the ChatGPT revolution came, we immediately started to find ways to use this magic box to write code, mostly unsuccessfully. It was just a toy, and it couldn’t produce production-ready code. But the tools always get better.

Copilot was getting pretty good at guessing the next line. Writing a short comment about what I wanted made it lock in. It was great at writing repetitive unit tests, and it came up with an original edge case once in a while. It wasn’t just a toy anymore. It was a useful tool. It did hallucinate APIs and functions sometimes, but who hasn’t?

And finally, the agents came. Things moved fast from “this thing writes OK code that I have to clean up” to “I gave the agent instructions on how I want my code and it’s doing it how I like it”. It felt weird demoting the IDE to a secondary tool. I find myself using the IDE mostly to write and change specs. Software development and coding are overlapping less and less for me.

I think we are in the early compilers era regarding AI agents, but with a much stronger and faster feedback loop. The LLMs keep getting better every few months. And even if that wasn’t the case, the tools and techniques are evolving constantly.

There is a steep section at the beginning of this learning curve, but the payoff is huge. I was able to create a complete non-trivial Android app without ever writing a single line of Kotlin. The starting point was an empty directory with two markdown files, FEATURES.md and MILESTONES.md, 200 and 158 words respectively.

I can get things done in stacks I’m not proficient in. I can quickly find and fix bugs in unfamiliar codebases. I can explore and try multiple things in the background while I work on my main tasks. I get to spend more time and energy making sure I’m building the right thing before any code is written, instead of figuring it out during the implementation. I get to think more about the what and why and less about the how.

AI-assisted software development is here to stay. I’d recommend learning to ride.

P.S. I’m sure there are many people trying to figure out how to build a car. I can’t wait to see how that plays out.

P.P.S. You can learn a bit about my saddle and reins here.

My Claude Code Workflows

2025-12-28T00:00:00+00:00

Nowadays I exclusively use Claude Code as my agent. I used Copilot, Copilot Chat, and Aider in the past. This guide assumes you’re already familiar with Claude Code basics. If not, start with the official docs. Here’s what my workflows look like.

Research and small changes

I use the default mode for this. Asking questions about the codebase. Asking it to research some API (pointing it to the official docs helps). Fixing some copy or a small bug that requires one unit test. Beyond that, it becomes hard to get good results.

Medium-sized changes

This is the most common scenario. Making changes to an endpoint, rearranging part of the UI, fixing bugs that require refactoring. I use Plan Mode (a mode where Claude creates a plan before implementing, cycle modes with Shift+Tab) for this.

I give it a detailed prompt that looks like the description of a properly triaged ticket/issue. Something you would tell a colleague if you were offloading this task to them.
I review the plan, add clarifications, ask for more implementation details where necessary.
I ask it to “review the plan for gaps and inconsistencies”. It usually finds a couple of things, often things I hadn’t even considered.
I usually prompt it one last time with “thoroughly review the plan” to see if it picks up anything important.
If I’m happy with it, I let it implement it in “accept all edits” mode (edits are applied without confirmation). You might want to manually accept edits at first since you obviously can’t trust this thing, but you’ll start trusting it and letting it edit freely soon enough.
Once it finishes, I ask it to “review the implementation for gaps and inconsistencies”. It always finds multiple things. It seems LLMs are better at reviewing code than generating code.
I ask it to give me alternative ways to address each issue it found. I select my preferred solution, tell it to skip the issue, or explain how I want it addressed.
I repeat steps 6-7 until I’m satisfied. I usually do a couple of iterations.
Commit and push the branch!

Large changes

When a task is too big for a single session, I need to break it down. I use Plan Mode if what I’m working on is large but well-defined.

I use the same initial workflow as a medium-sized task, reviewing and improving the plan.
When I’m happy with it, I ask it to split the plan into stages.
I ask it to move tasks around as I see fit.
I ask it to write the plan to a markdown file.
I use a new session to implement each stage as a medium-sized change.

If it’s not well-defined or it requires architectural decisions, I use OpenSpec (a spec-driven framework for planning code changes through specification documents) instead.

I generate a proposal with the corresponding design document, specs, and tasks.
I iterate on the proposal, make the design decisions, review the specs, and verify the tasks.
I ask it to “review the proposal for gaps and inconsistencies”. It always finds things.
Once I’m happy with it, I accept it and move to implementation.
I either let it implement the full thing, or implement up to a stage where I want to manually verify (e.g., implement Tasks 1.x to 3.x, then pause for manual testing).
I handle each implementation stage like a medium-sized change, with the review cycles and committing.

Skills

I create skills for things I do often that become annoying.

I have a skill to address PR feedback. It uses the GitHub CLI to pull all the PR comments. It has interactive and bulk modes. It makes addressing comments so much easier. I don’t have to go back and forth between the PR, the IDE, and the terminal.

In interactive mode:

It shows me each comment’s content, with the code context and a link.
It gives me multiple choices for how to address it (or I can write my own).
It implements the fix, commits, and replies with a short description of how it was addressed and the commit hash.
It moves to the next comment.

In bulk mode, it writes a markdown document with all comments. I mark my choices, and it processes them all at once.

I have a “thorough code review” skill with a list of things I want it to look for and what the workflow should look like. It has similar interactive and bulk modes to the PR feedback skill.

Tools for the agent

To make all of this work well, you need to set up the agent properly. Having a decent CLAUDE.md file is important for the agent to be effective. The automatically generated one is a good start. It should include how to use tools to generate good and correct code.

Your CLAUDE.md should include:

How to run tests and linters
Anything that would help any engineer produce consistent quality code
Anything that would help verify the agent’s work is correct
Workarounds for things the agent repeatedly fails at (e.g., how to run a specific build, how to start the correct emulator, how to run tests in a specific way, how to create common seed data)

Context management

Another thing to keep in mind is context management. Agents are getting better at this, but it’s something that I keep an eye on. Sometimes if I’m close to the auto-compact threshold (when Claude automatically summarizes the conversation to free up context space), I will ask it to dump the session’s relevant context and progress to a markdown file, check that nothing important is missing, and start a new session. I recently added a rule to my CLAUDE.md: tests and builds should use Tasks (which run in a separate context) when detailed output isn’t needed. This keeps the main context clean.

Decay

Depending on when you are reading this, you might want to ignore some or all the things I mentioned. LLMs and agents are improving at such a rapid pace that I expect most of these things will be unnecessary or different in six months.