--- title: "Unslop software" description: "AI should make software cheaper, more secure, nicer to use and quicker to respond to the people using it, not worse. Open tools like emBEADings are a small part of that." author: Jackson Cantrell date: 2026-10-08 updated: 2026-10-08 canonical: https://jacksoncantrell.com/blog/unslop-software image: https://jacksoncantrell.com/images/blog/unslop-hero-og.png --- # Unslop software ![Pixel art of a road at sunset that forks below the Verdugo Hills, with a signpost reading More to the left and Better to the right. The dark left road runs into a smoggy heap of mismatched blocks covered in pop-up windows, sale and free billboards, antennas, sagging cables and smokestacks. The sandy right path leads to a small white studio with a teal door, a lit window with someone at a desk, a radio mast, palms, a flower bed and a pink lawn flamingo.](https://jacksoncantrell.com/images/blog/unslop-hero.png "Same tools, two roads. I know which one I'd rather live at the end of.") 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. ![A hi-fi meter panel titled Two ways AI can go, with four rows: cheaper, with a coin; more secure, with a padlock; nicer to use, with a heart; and responsive, with a speech bubble and a check. Each row has two LED meters. The slop meters light only a few orange segments; the unslopped meters are nearly full of teal. The scale runs from worse to better, with no numbers.](https://jacksoncantrell.com/images/blog/unslop-meters.png "No numbers on this one, on purpose. It's the direction that matters.") None of that happens automatically. It takes [a few people keeping the decisions](https://jacksoncantrell.com/blog/few-people-many-agents) 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](https://embeadings.jacksoncantrell.com) 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.](https://jacksoncantrell.com/blog/agent-mail) ![On the left, under Tangled, coloured beads knotted into a snarl of string, with two loose beads rolled away. A magnifying glass and an arrow lead to the right, Found, where the beads hang on three neat strands: same bug, with three orange beads; related, with four teal beads; and fixed by a PR, with a gold bead strung next to a PR tag. Along the bottom, a small person with a raised hand beside the words It shows you. You decide.](https://jacksoncantrell.com/images/blog/unslop-tracker.png "Issues are beads, so here they are as beads. It doesn't close anything; it just shows you the strings.") I built it on my own and gave it away. The source is [on GitHub](https://github.com/CantrellJax/embeadings). ## 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](https://jacksoncantrell.com/blog/dont-be-a-meat-proxy). There's more about me on the [about page](https://jacksoncantrell.com/about).