Unslop software

There are two ways AI can go for software, and I think it’s still up to us which one we get.
In the first, AI makes it cheap to produce more of everything. More features nobody asked for, more code nobody read, more screens designed to keep you clicking. Software gets bigger and worse at the same time, the slow decline Cory Doctorow calls enshittification, now with much more output behind it. That’s slop.
In the second, the same tools make software cheaper to build, more secure, nicer to use, and able to respond to the people using it almost in real time. That’s the one I want to work on.
What unslopped software looks like
Cheaper. If agents do a large share of the work, building and maintaining software should cost less. Some of that saving should reach the people who use it, in lower prices or in tools that didn’t make economic sense to build before.
More secure. Agents don’t get bored. They can review every change, write the tests nobody had time for, and go back through old code looking for the problem everyone suspected was there. Security work that used to lose out to feature work can now actually get done. It still needs people deciding what matters and checking the result, but there’s no longer an excuse to skip it.
Nicer to use. The polish that used to get cut for time, like clear error messages, careful empty states, and pages that work on a phone, is now cheap enough to keep. A small team with a lot of agents can sweat details that a big team used to leave on the floor.
Responsive. This is the one I’m most excited about. When someone reports a problem, the distance between “this is broken” and “this is fixed” can be very short. Agents can reproduce the bug, draft the fix and write the test while a person decides whether it’s the right fix. Software can listen to the people using it and change in response, the same day.

None of that happens automatically. It takes a few people keeping the decisions and caring about the result, instead of letting the agents produce whatever is easiest.
Slop shows up in the tracker first
When many agents are working on a project, a lot of them file issues. The same problem gets reported more than once, in slightly different words. A pull request fixes something and the issue that described it stays open. Related work ends up scattered across a dozen tickets that never reference each other.
That’s slop too, just in a place users don’t see. It wastes the people’s attention, and it misleads the agents, who read the tracker to decide what to do next.
I built emBEADings for that. It’s an open-source tool that looks at a Beads or Linear tracker and finds the issues that belong together, and the open issues that a merged pull request already fixed. It’s read-only: it doesn’t close or merge anything. It shows you what it found and you decide. That’s the same rule as everywhere else in this weblog. Agents propose, people decide.

I built it on my own and gave it away. The source is on GitHub.
Share the tools
Open tools are part of unslopping software. If every team builds its own private version of the same helpers, we all start over, and the good ideas stay locked up. When the tools are open, teams can build on each other, fix each other’s mistakes, and spend their time on the part that’s actually theirs.
That’s a small contribution, and emBEADings is a small tool. But I think a lot of the good outcome comes from small tools like it: things that make the work a little cleaner and leave the decisions with people.
If you’d rather read about why the people have to stay in charge, start with Don’t be a meat proxy. There’s more about me on the about page.