When we can build everything

I think we’re going to build a lot of things we don’t need, simply because we can get an agent to do them quickly.

A feature that needs weeks of work usually gets a discussion about whether it’s worth doing. A working prototype can make that discussion feel unnecessary. Once the code is there, keeping it starts to seem like the obvious choice.

Suppose agents get good enough that maintenance becomes cheap too. They fix the bugs, keep the docs correct, and handle the awkward cases.

Even then, the person using the feature may have to stop and figure it out. I’d want to know whether we’re asking them to learn another setting or make a decision they shouldn’t need to make. Someone still has to decide what the product should ask of its users, however little it costs us to build.

Imagine two invoicing tools built for freelancers. Both support reminders, reports, and custom workflows. One asks you to choose a workflow and configure its settings before you can send an invoice. The other opens an invoice draft and lets you send it, with those options there when you need them.

Setting up a workflow could make sense for a freelancer sending dozens of recurring invoices. They spend some time choosing how it works, then reuse it every month. Someone sending their first invoice might want to get it out before deciding any of that. The same setup step can be helpful to one person and an interruption for another.

For the second person, a sensible default and the option to configure things later might be enough. We can keep the feature while choosing when to ask them about it. Giving everyone every option up front leaves them doing the work of figuring out how the product should behave.

That’s what I mean by taste: understanding what someone came to do and making choices that help them do it. Sometimes that means a good default. Sometimes it means leaving a feature out because it adds more confusion than value for the people using the product.

If our competitors can build the same functionality, those choices could be why someone prefers our product. We might both have reminders, but ours could come with a schedule that works for most of our users instead of asking everyone to invent one. Having reminders on a feature list wouldn’t tell you that difference.

An agent could make these choices as well, possibly better than we would. It could choose the reminder schedule, simplify the setup, or investigate whether reminders actually help people get paid sooner. I don’t think taste has to stay exclusively human. But “match every competitor’s feature list” and “help freelancers get paid with less admin” give even a very good agent different goals to work towards.

If we build a prototype, I’d want to watch someone use it to send an invoice. Did it help them finish, or did it give them more things to work out? A perfectly good implementation can still fail that test. We should be able to change it or throw it away without treating the work as wasted.

A feature gets a demo. Choosing a default that saves people a setup step is harder to point to. So is finding that the existing flow already works and we can leave it alone. Those decisions should count when we judge engineering work. If we only give credit for adding features, we’re making it harder to recommend anything else.

I’d like “we looked into it and decided we didn’t need it” to count as good engineering work, even when building it would have been easy.

Related reading: Maggie Appleton’s Home-Cooked Software and Barefoot Developers , on software made for particular people and communities, and Kief Morris’s Humans and Agents in Software Engineering Loops , on organising work between people and agents.