LLMs are cats, not dogs

LLMs are cats, not dogs. You can train dogs. They respond well to commands and are eager to learn to please their owner. They are malleable to your desires.

But LLMs are cats, not dogs. LLMs seem eager to please with their sycophantic tone but their actions betray their language. They do what they want - system prompt be damned!

You might guess I’m a dog person, not a cat person, and you’d be right. But the lesson remains …

Don’t treat cats like dogs. And don’t treat LLMs like people.

This matters a lot in the crazy new world of agentic engineering. Our software development tools were designed to aid humans but there are better ways to use them for LLMs.

Take git for example - a tool for distributed version control. Over time, we’ve built many workflows around it so that we can coordinate and merge the work of many individual developers concurrently. We embrace branching, create PRs of a particular size, and squash working branches into main for clean atomic histories. But try to follow these same patterns with multiple agents on the same machine and you are going to have a bad day. (Hint: worktrees are your new best friend.)

Humans can learn and remember between activities. LLMs can’t.

Agentic engineering requires us to think very carefully about intra-context vs inter-context memory - something Geoffrey Huntley calls “deterministically malloc-ing the context array”. When agents can spew out code faster than we can write requirements, the need for concurrency diminishes. A single agent thread is more than enough when that agent can work 24/7.

So git becomes more of a tool for memory management than version control. Branching becomes less important. Our commits become smaller and more frequent. We don’t need to fix mistakes as much as git reset --hard and try again.

The same is true for processes. Painful experience has made me an advocate for TDD but no matter how hard I try, I just can’t get LLMs to do it. Like the untrainable cats that they are, LLMs just can’t help but one-shot a full solution - they code all at once and then add tests as an after thought.

The more imperative my prompting, the worse the outcomes. So I’ve stopped fighting - now I use tests as verification rather than trying to force test driven development. I let my coding agents do their thing and use reviewer agents to incrementally herd the system towards a state that I am happy with.

Describe the goal, set the guardrails, and get out of the way.

Don’t fight the model. Understand it and herd it.