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.

Suppose you’re building a service that depends on several other services to work. You write a bunch of code and carefully include error handling code and have a plan for what happens if each service your new service calls fails. Naturally, you want to test your code. These services are invoked over a network. Perhaps they’re web services but they may be some other network protocol. Suppose further your code is nicely factored so there’s a “client” class that presents the network service as a library API to the rest of the service.

Code is communicating. Communicating with the computer to make it do something useful. Communicating with the future people that will read and maintain the code.

The former doesn’t care how clever you are. The latter may know where you live. The latter may be you.

In my learning programming post I wrote about some approaches for learning to program and linked to a bunch of resources. Some of my insightful friends pointed out that most programming teaching doesn’t cover debugging and that lack leads to a lot of frustration. This is particularly hard on those working alone or with other people that don’t know how to debug.

Debugging is the art of figuring out why a system doesn’t work. The skills of debugging apply not just to errant programs but to any system that needs diagnosis.

I’m interested in how people learn to program. Over the past few years, friends or relatives have asked me about resources for learning to program for themselves or for people they know. I’ve collected and refined that advice here. It’s hard to know what approach will work for someone to learn to program. It’s hard work so it’s important that each step be interesting and rewarding enough to keep going particularly when there’s no external force such as formal courses.

RFC 761 section 1.2.2.

2.10. Robustness Principle TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

RFC 1122 elaborates with section 1.2.2.:

1.2.2 Robustness Principle

At every layer of the protocols, there is a general rule whose application can lead to enormous benefits in robustness and interoperability: “Be liberal in what you accept, and conservative in what you send”

[Read More]

I’m a software developer. There are tools I like and have successfully built applications using but I also enjoy learning new tools and languages.

My goal is to use the best tool for the job. Most of the time the “best tool” is not a choice based entirely on the merits of one platform over another. If I want to hack my WordPress install, I have to use PHP. If I want to use Lucene for something, I have to use Java.

FileIO

I wrote (the first version of) the LambdaMOO FileIO patch a long time ago, but I didn’t use it for very long and haven’t been the maintainer for a long time.

The link I had to the current version is dead.

toaststunt is a LambdaMOO fork which includes what appears to be a modern version of FileIO. I have not used it.