In my post about AI agents as power tools I wrote that agents are good at picking up existing patterns. Here’s a concrete example of what that looks like—both the strengths and the limits.

The setup

I have a project using SQLite with a bespoke database versioning and migration system. Nothing fancy, just a version number stored in the database and a set of migration functions that upgrade from one version to the next. The kind of thing you write when you need migrations but don’t need a framework.

In my post about AI agents as power tools I ended with “don’t confuse the tool for the craftsperson.” This is worth expanding, because the confusion runs in both directions and both cause problems.

The mentorship trap

AI agents communicate in natural language. They say “I” and “I think” and “let me try.” They apologize when they make mistakes. This makes it easy to treat them like junior colleagues who work very fast.

In an earlier post I wrote that code communicates to the computer and to future readers. With AI coding agents, there’s a third audience: the agent itself. The agent reads your code to understand how to extend it. Good architecture makes this communication clearer. Bad architecture makes the agent confidently generate more bad code.

AI agents are very good at using well-designed components. They are not very good at designing them. They can implement against a clear interface, follow established patterns, and generate code that fits into an existing structure. They struggle with deciding what the interfaces should be, knowing which abstractions will age well, and understanding the domain deeply enough to decompose it correctly.

AI coding agents can move fast. The constraint on their productivity is correctness. They are always confident, but they need clear, automatic signal about correctness otherwise a human ends up providing all of that signal (slowly). A robust test suite can ensure the confidence aligns with correctness. The shape of the test suite matters as much as its existence.

Interface tests vs internal tests

Tests that cover publicly exposed interfaces without depending on internal implementation details are a force multiplier for AI agents (and humans). These tests define what correct behavior looks like without dictating how that behavior is achieved. An agent can refactor freely, restructure internals, rewrite implementations entirely—and as long as the tests stay green, the changes are probably safe. A “perfect” test suite would cover the entire set of visible behavior, so a green suite would mean correct software. Don’t let the difficulty of a perfect suite prevent building a good one, and consider how lower development costs and higher ROI on tests may mean aiming closer to “perfect” than you might have once.

In my last post I called AI coding agents “power tools for software developers.” The characteristics of power tools explain the capabilities, current limitations, and exciting opportunities of coding agents.

A table saw doesn’t know what you’re building. It doesn’t care if you’re making a bookshelf or a coffin. It will cut whatever you feed it, exactly where you guide it, with tremendous speed and force. The saw has no judgment. It has no taste. It won’t tell you that your design is ugly or that the joint you’re about to cut won’t hold weight. It does precisely what you tell it to do, including cutting your fingers off if you put them in the wrong place.

Years ago I wrote about my enthusiasm for automation of toil. The advent of coding agents is the first time I’ve faced automation of a task I enjoy. I enjoy developing software, and I enjoy coding.

For fun projects, the ‘return’ on the investment is ‘fun’—and sometimes the fun is in the coding, sometimes it’s in solving the problem, and sometimes it’s in solving the problem by coding.

I found programming fairly young. I was lucky to have a computer and a technologist father who encouraged my interest. I enjoyed coding: making something “go”. I also enjoyed solving problems. Initially these were problems like “how do I make it do what I want” or pursuing an interest in a language or tool.