AI Slop in Software: How to Stop Shipping Features Nobody Needs

Merriam-Webster picked "slop" as its 2025 word of the year and defined it as "digital content of low quality that is produced usually in quantity by means of artificial intelligence." Most people picture fake images and filler articles. Software has its own version, and it's harder to spot, because it compiles, passes its tests and looks finished.

AI slop in software is code nobody needed, shipped because building it was cheap. Coding agents made writing code close to free. They didn't make it any easier to know what's worth writing. This post explains how slop gets into a product, why agents make it worse, and how we built Starko to keep teams tied to what their customers actually do.

Key takeaways

• Slop comes in two kinds. Bad code that works badly, and good code for a feature nobody wanted. The second kind costs more and is harder to catch in review.
• Agents remove the old filter. When building took weeks, the effort itself forced teams to ask "do we need this?" When it takes minutes, nobody asks.
• The fix is upstream. Start every change from evidence: a customer's words, a session replay, a page error. Don't start from a prompt someone dreamed up.
• Starko is built around that rule. Work starts from customer evidence and counts how many people it affects. Starko asks before it builds, a person decides what gets built, every pull request stays inside the ticket, and the customer hears back when it's fixed.

What is AI slop in software?

AI slop in software is code produced quickly and in volume by AI tools that doesn't earn its place in the product. It shows up in two forms.

The first is low-quality code. GitClear analyzed 211 million changed lines and found that 2024 was the first year in which duplicated code outpaced refactoring. Churn, meaning code rewritten soon after it was written, rose from 3.3% in 2021 to 5.7% in 2024. This kind of slop is real, but review, tests and linters catch most of it.

The second is a well-built feature nobody needed. Clean code, good tests, a tidy pull request, for a problem no customer has. Code review won't catch it, because reviewers check whether the code is right, not whether the feature should exist. It ships, adds surface area, adds support load and slows down every change after it.

That second kind isn't new. Pendo studied 615 software products and found that 80% of features are rarely or never used, while 12% of features produce 80% of daily usage. That was in 2019, before coding agents. Agents just let you build the unused 80% faster.

Why do coding agents make the slop problem worse?

Building used to be expensive, and the cost worked as a filter. A feature that took a team three weeks had to survive a planning meeting, a prioritization debate and somebody asking "who asked for this?" Most bad ideas died there.

Coding agents removed that filter. Three things happen when building gets cheap:

1. Every idea looks worth trying. If the agent can do it in twenty minutes, why not? The cost moves from building to everything that comes after: review, support, maintenance and a product that gets harder to understand.
2. Agents say yes. A coding agent does what the prompt asks. It won't tell you the feature is a bad idea, that three customers asked for something different, or that the real problem is a confusing button two pages earlier.
3. The prompt replaces the customer. When work starts from what a developer types, the product drifts toward what the team imagines instead of what customers do.

Product people have names for this. John Cutler called it the feature factory: a team that measures itself by what it ships rather than what changed for customers. Melissa Perri called it the build trap. Coding agents turn a slow feature factory into a fast one.

Where should the fix start?

You can't review your way out of building the wrong thing. By the time a pull request exists, the expensive decision has already been made. The only reliable fix is to change where work comes from.

The rule is simple: no change without evidence of a customer problem. A customer described it, a visitor got stuck on it in a session replay, or an error fired on a real page. Real evidence also tells you the scope. You build the smallest change that fixes what was seen, not the biggest feature someone could imagine around it.

This is the idea behind a software factory that starts from customers rather than from prompts.

How does Starko keep you in touch with reality?

Starko turns customer feedback into tickets and lets Starko AI, Starko's own coding agent, turn those tickets into pull requests. Each of the guardrails below exists to stop the factory from building things nobody needs.

Work starts from what customers did, not what someone imagined

Tickets in Starko come from real sources: support conversations, session replays, page errors caught by the Starko widget, GitHub issues and Slack. The evidence stays attached. A ticket filed from a conversation links back to it, and a ticket filed from a replay has a "Play recording" button.

Starko also counts. Page errors are grouped, and the ticket keeps a running tally: "Still happening: N occurrences across M sessions so far." When another visitor hits a problem that already has a ticket, Starko adds "Another visitor ran into this" to that ticket instead of filing a new one. The same goes for questions your help content can't answer: the Topic gaps page ranks each one by evidence and shows how many customers asked it. You can see how many people something affects before anyone writes a line of code.

Starko asks before it builds

A thin report is how slop starts. Without enough detail, an agent fills the gaps with guesses. So Starko checks every incoming ticket first. For a bug, it looks for steps to reproduce, expected and actual behaviour, and the page or version. If something is missing, Starko leaves the ticket owner a note: "Before Starko AI can take this ticket, the report is missing what an engineer would need first." An incomplete bug report is never started automatically.

For features and improvements, Starko drafts three to six acceptance criteria in the customer's terms and raises at most two questions that block the work. If Starko AI hits an open question halfway through a run, it stops, pushes nothing and asks once. The ticket shows "Needs more information" until someone answers.

A person decides what gets built

You choose how much Starko starts on its own, from "Off (only @starko mentions)" up to "Bugs, docs and small changes (xs/s)." Even at the widest setting, larger features never start on their own. Someone on your team has to decide those are worth building.

Ideas that come from Starko itself always wait for a person. When Starko spots friction in session replays, it files a recommendation, such as "3 visitors on /pricing tried to …, but …", with the smallest change to test and the replay moments as evidence. Nothing is built until you click "Accept" or "Fix now." If you click "Decline," Starko asks why: "Not a problem for us," "Already planned or fixed elsewhere," "Not worth the cost right now," "Maybe later" or "Other." The reason you give is fed back to Starko AI, so its later suggestions take it into account.

Prototype before you build

Some ideas need to be seen before anyone can judge them. Choose Prototype on a ticket and Starko AI makes two or three mockup pages, writes no code and opens no pull request. When the request came in through Slack, the mockups appear right in the thread as images. If you work with customers in a shared Slack channel, they can look at the options and tell you which one solves their problem before anything is built. Your team picks a direction, or decides the idea isn't worth building at all. Throwing away a mockup costs much less than reverting a merged feature.

Every pull request stays inside the ticket

Scope creep is slop too. Starko AI is told to keep changes small and scoped and not to refactor around them. Every pull request opens with Problem, which says what the customer hit or asked for. It ends with Out of scope, which lists what was deliberately left alone. If the agent had to depart from the ticket, the pull request says so under "Deviations from the ticket." You can see at a glance whether the change does what the customer needed and nothing more. The run walkthrough shows one end to end.

The customer hears back

A fix that ships quietly only does half the job. When the work behind a customer's report is done, Starko tells that customer it's fixed, so the person who took the time to report a problem learns it mattered. Their next report is more likely to come, and it will come with more detail. If a project is internal work your customers shouldn't follow, you can switch that off with "Stop emailing the customer."

You see what it changed for customers

Starko's Improvements page shows how many suggestions were proposed, accepted, shipped and declined over 30 days. It also shows "Visitors spared," the number of visitors the shipped fixes were based on. Every Monday, a weekly digest groups the week's replay analyses into themes: "What visitors wanted," "Where the UI failed" and "Smallest change to test." Your team sees a list of real problems, not a backlog of imagined features.

What does this look like in a real week?

Here is how the guardrails play out in practice.

Monday. Three visitors on your pricing page try to switch to annual billing and give up. Starko's replay analysis files one recommendation, because the second and third visitors are added as sightings, not new tickets. It proposes the smallest change: make the annual toggle visible above the plans. Your PM reads the evidence, clicks "Accept," and Starko AI opens a small pull request that cites what the visitors hit. It's reviewed and merged by Tuesday.

Wednesday. Someone posts in Slack: "We should add a full analytics dashboard for customers." Starko files it as a feature request, sizes it as large and drafts acceptance criteria. Because it's large, it will never start on its own. The ticket waits for a person to decide. Nobody can point to a customer who asked, so it stays in the backlog, and the team doesn't spend a sprint reviewing a dashboard nobody will open.

Both requests went through the same factory. The one backed by evidence got built in a day, and the visitors' problem was gone by Tuesday. The one backed by enthusiasm got a pause and a question.

What can't Starko do for you?

Guardrails help, but they don't replace judgment. Starko has real limits:

• It can't set your strategy. Evidence tells you what customers struggle with today. It won't tell you which market to enter next. That decision stays with your team.
• Small features can still start automatically if you choose the widest autonomy setting. If you'd rather a person approve every feature, use "Complete bug reports" or "Bugs and docs gaps."
• Evidence has to exist. If you never connect your support inbox, the widget or session replays, Starko has far less reality to work from.

How do you keep your team out of the slop?

Before and after any change ships, whether an agent or a person wrote it, ask:

1. Who hit this? Name a customer, a conversation, a replay or an error. If nobody can, stop.
2. How many hit it? One loud request and forty quiet sightings deserve different answers.
3. What's the smallest change that fixes what we saw? Build that first and measure before going bigger.
4. Did we look at it before building it? For anything visible, a mockup is cheaper than a revert.
5. Does the pull request stay inside the ticket? Check what it changed against what it set out to fix.
6. Did the customer hear back? Tell the people who reported it that it's fixed.
7. What changed for customers afterwards? If you can't answer, you're measuring output, not outcomes.

Our guide on how to build a software factory turns these questions into settings, step by step.

Frequently Asked Questions

What does AI slop mean?

AI slop means low-quality content produced quickly and in volume by AI tools. Merriam-Webster named "slop" its 2025 word of the year and defined it as "digital content of low quality that is produced usually in quantity by means of artificial intelligence." In software, it covers both sloppy AI-written code and well-written features nobody needed.

Is AI-generated code always slop?

No. AI-generated code is slop when it doesn't earn its place, either because it's low quality or because it solves a problem no customer has. Code written from a clear customer problem, kept to the smallest fix, reviewed and checked, is just code. Where the work came from matters more than who typed it.

What is a feature factory?

A feature factory is a product team that measures success by how many features it ships rather than by what changed for customers. John Cutler coined the term in 2016. Coding agents can speed up a feature factory, which is why teams using them need a tighter link between customer evidence and what gets built.

How do you avoid feature creep with AI coding agents?

Start each change from customer evidence, ask for acceptance criteria before building, keep a person in charge of approving larger features, prototype visible changes first, and check that every pull request stays within its ticket. Tools like Starko build those steps into the workflow, so the agent can't skip them.

How does Starko decide what to build?

Starko doesn't decide on its own. It files tickets from customer conversations, session replays, page errors, GitHub issues and Slack, counts how many customers each problem affects, checks that each report is complete, and asks a person before building anything large or anything it suggested itself. When the fix ships, it tells the customer. Start on the free plan and connect one source to see the evidence it gathers.