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.

AI coding agents work the same way. (I suppose it’s worth noting here Sawstop saws won’t cut your fingers off and there’s probably an analogy here somewhere about guardrails for AI agents.)

Very effective at the stated task

Power tools excel at precise, rapid execution of operations. A router cuts profiles. A drill makes holes. A planer flattens surfaces. A CNC mill precisely removes material according to a plan. Each tool is optimized for its purpose and can perform that operation faster and more consistently than hand work.

Coding agents are remarkably effective at generating code that does what you ask. They can write a function, make a test suite pass, or implement an existing interface quickly.

The mechanical work of turning a decision into code has gotten dramatically cheaper. As with power tools, this changes the most effective way to make things. A bit more design up front, a bit more building the thing, looking at it carefully, and then throwing it away to build another one based on what you learned is much more feasible.

No judgment, no taste

A table saw won’t tell you that your design has a fatal flaw. It won’t suggest a better joint. It won’t notice that the grain direction will make your piece weak. It’s not even that it assumes you know what you are doing—it doesn’t judge at all. If you ask an AI agent to consider if a plan might work, it can often give useful feedback, but if you don’t ask it will not.

Coding agents will generate code that is technically correct and architecturally terrible. They’ll build on bad abstractions without hesitation. They’ll propagate anti-patterns. They’ll create something that works today and will be unmaintainable tomorrow, or even in the next five minutes given how fast they can make code.

I’ve started thinking of agents as “pattern amplifiers”—they observe and reproduce whatever patterns exist in your codebase. Good patterns get amplified. Bad patterns get amplified. The agent can’t tell the difference.

This is the critical gap. Agents can execute decisions. They cannot make good decisions about what to build or how to structure it. The judgment about whether a design will hold up, whether an abstraction will age well, whether a trade-off is worth it—that remains human work.

Taste matters more now. The ability to recognize good design, to choose the right approach from many valid options, to sense when something is wrong even if you can’t immediately articulate why—these skills have become more valuable because the cost of implementing any given design has dropped.

Applying taste has gotten cheaper as well. When implementation was expensive, you had to get the design right in your head before committing to code. Now you can build it, look at it, and rebuild with what you learned. Cheap prototypes change the design process—taste still requires experience, but experience accumulates faster when experiments are cheap.

Good at picking up existing style

Power tools don’t impose a style. A table saw will cut for Mission furniture or mid-century modern or baroque revival. It follows your lead.

Coding agents are remarkably good at matching the style of existing code. They pick up naming conventions, structural patterns, error handling approaches, comment styles. Feed them a codebase with consistent patterns and they’ll extend it consistently. This is one of their genuine strengths.

The implication is that establishing clear patterns early matters more than it used to. Whatever you establish, the agent will follow. Whatever inconsistencies exist, the agent will reproduce inconsistently. The first few implementations of any pattern now carry more weight because they template everything that follows.

This also means code review has shifted. When reviewing agent-generated code, I spend less time on “does this code work” and more on “is this the pattern we want propagated.” Accepting code that works but follows a mediocre pattern means accepting that pattern as the template for future work. The human review zooms out—from line-level correctness to architectural direction.

The same pattern-matching that makes agents good at writing code makes them good at reviewing it. They can spot bugs more deeply than linters, and they’re good at catching when new code doesn’t follow established patterns—particularly with clear guidance in their context documents. But they’re checking consistency with what exists, not whether what exists is good. The agent can tell you the new code doesn’t match the pattern. It can’t tell you the pattern is wrong.

One frontier is capturing more of what “good” means in ways agents can apply—not just patterns to follow, but principles behind them. The better we get at articulating why certain approaches are preferred, the more agents can do. That articulation is itself craft, and can sharpen our own thinking.

Work best with rails, even sketchy ones

Power tools are most effective with jigs and guides. A table saw with a good fence produces consistent cuts. A router with a template produces consistent profiles. The tool does the cutting, but the jigs constrain it to useful paths.

Coding agents work the same way. They’re most productive when operating within constraints—type systems, test suites, well-defined interfaces, established patterns. Even imperfect constraints help. A sketchy test suite is better than none. A rough interface definition is better than asking the agent to design the interface.

Test suites function as specifications for agents. The tests are rails. They constrain what “correct” means. Without them, the agent has to rely on your verbal descriptions, and you have to manually verify everything it produces.

I’ve found that even incomplete rails dramatically improve results. A partial type definition. A few example implementations. A rough sketch of the architecture. These give the agent something to follow, something to be consistent with. The agent doesn’t need perfect guidance—it needs enough structure to stay on track.

This is where the tooling ecosystem matters. Strong type systems, good test frameworks, clear API definitions—these were always valuable. They’re now load-bearing. They’re the jigs that make the power tool useful rather than dangerous.

And we can use power tools to build better jigs. Formal verification, property-based testing, exhaustive type constraints—techniques that were often too labor-intensive to justify are now more accessible. Agents can help build the scaffolding that then constrains their own future work. The investment in better rails pays off faster when the tool running on those rails moves faster.

Respect the tool

Experienced woodworkers respect their tools. They know a table saw can produce beautiful results and can also take a hand off in an instant. The solution isn’t to avoid the tool—it’s to understand it, establish good practices, and never forget what it can and cannot do.

The same applies to coding agents. They’re not magic. They’re not colleagues. They’re power tools. Tremendously effective, completely without judgment, good at following patterns, and most useful when constrained to well-defined paths.

The craft is still there. It’s in the design decisions. In the judgment calls. In the taste that recognizes good from mediocre. In setting up the rails that make the tool effective.

Use the tool. Respect the tool. Don’t confuse the tool for the craftsperson.