# No More Slop

swyx, AI Engineer | AI Engineer CODE 2025 | 09:15

Source: https://www.youtube.com/watch?v=IoiHI7p12Ao
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/no-more-slop
Published: 2025-12-22
Tags: agents, coding-agents, context-engineering, human-in-the-loop, prompt-engineering

## TL;DR
- AI-generated work is not automatically slop, because humans can also produce low-quality, inauthentic, or inaccurate work.
- AI engineering needs to judge the quality and accountability of code, rather than celebrating token volume or autonomous run time.
- AI can help reduce slop through codebase understanding, computer use, subagents, and clear boundaries between human design and machine-generated code.

## Summary
swyx declares a war on slop, which he defines as low-quality, inauthentic, or inaccurate work. He rejects the idea that AI alone produces it. Humans and models can both create slop, and high-quality work can deteriorate into it as trends spread. The problem is asymmetric because generating more tokens is becoming much cheaper while applying taste and review still takes human effort. In code, this creates risks that range from large amounts of technical debt to exposed private data. swyx argues that autonomy needs accountability, so claims about how long an agent can run are incomplete without judging the resulting code. He describes several ways to fight code slop: keeping human attention on difficult work, using AI to build code maps, operating software through computer use, using subagents to reduce context rot, and preserving modular boundaries between human-designed parts and machine-generated code.

## Key ideas
### Slop is a quality problem that humans and AI can both create
[01:13](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=73s)
swyx uses "slop" for work that is low-quality, inauthentic, or inaccurate, while rejecting the Oxford English Dictionary's implication that artificial intelligence is required. A person can be an agent of slop just as easily as a model. He compares the idea with "kino," internet slang for work with taste and quality. The same studio, model, startup idea, or coding approach can produce either outcome. Work that feels fresh early in a trend can become slop once it is copied and diluted. His examples include Netflix productions, startup ideas, vibe coding, and presentations that can feel either thoughtful or generic.

### Fighting slop takes much more taste than producing it takes effort
[04:30](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=270s)
swyx adapts Brandolini's law into what he calls "Fix's law of anti-slop." The amount of taste needed to fight slop is an order of magnitude larger than the amount needed to produce it. He connects this imbalance to the falling cost of generating tokens, which he says is dropping by 100 to 1,000 times every year. The response cannot be to produce even more material without judgment. People have to raise the quality of what reaches the world. He points to AI Engineer News as one small example, since it can tell readers not to read the newsletter when there is nothing worth reporting.

### Prompting can reduce low-quality output
[05:28](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=328s)
AI can also be used against slop. swyx points to a skill set used by Mahesh and Barry that explicitly tells Claude not to produce slop. He says the resulting output improves significantly across the examples shown from left to right. The practical lesson is simple: quality requirements need to be stated in the instructions given to a model. A system that names the failure mode and asks the model to avoid it can produce a better result than one that only asks for an answer. This is one of the few examples where his warning about slop leads directly to a concrete prompting practice.

### Code autonomy needs a judgment about the code it produces
[05:45](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=345s)
swyx treats code slop as a serious engineering problem. Two engineers can use AI to create the technical debt associated with 50 engineers, and AI-assisted systems have exposed private data belonging to millions of users. He is also skeptical of claims that a model can work autonomously for 30 to 60 hours when those claims do not say whether the code was good. Duration alone is not a useful measure of engineering value. He summarizes the standard he wants with the phrase, "You don't want autonomy without accountability."

### Human attention should stay on the hardest engineering problems
[06:21](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=381s)
swyx describes a "semi-async value of death," where human attention and close collaboration with the machine are reserved for the hardest problems. Work that has become commoditized can move through a more asynchronous process. He presents this split as a way to use AI without allowing human review to disappear everywhere. The point is not to keep people involved in every small task. It is to spend their attention where judgment matters most, while letting more routine work proceed with less direct involvement.

### AI-generated code needs codebase understanding
[06:41](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=401s)
Another way to fight code slop is to use AI to scale codebase understanding. swyx points to his more recent work on code maps, which help people and systems understand how a codebase is structured. He separates this from simply asking an agent to write more code. Without a model of the existing system, generated changes can be locally plausible while creating problems elsewhere. Code maps give engineers a way to inspect and reason about the wider codebase. He directs attendees to the Cognition team for a more detailed explanation.

### Computer use and subagents can reduce operational and context problems
[06:57](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=417s)
swyx says computer use, which he associates with Anthropic's introduction of the idea the previous year, can now operate complex applications, including an integrated development environment. His team uses Devin to automate website updates. He also says subagents can help fight context rot, where a long-running task loses track of the information it needs. These tools are presented as practical ways to reduce the amount of repetitive work and context management that engineers must handle directly. They still belong inside a system with quality checks and accountability.

### Modularity keeps human decisions visible
[07:29](https://www.youtube.com/watch?v=IoiHI7p12Ao&t=449s)
swyx says Greg Brockman repeatedly advocates modularity: keep clear boundaries around what humans design, then let AI write the code between those boundaries. This gives the system explicit places where human intent is defined and reviewed. The machine can handle implementation inside those limits, while the overall design remains legible to the people responsible for the result. He presents modularity alongside code maps, computer use, subagents, and selective human attention as part of a broader response to code slop. His final instruction is a shared refusal to accept more output simply because it is easy to generate.

## Notable quotes
- "Any human or AI can be an agent of slop, right?" (02:13)
- "The amount of taste needed to fight slop is in order manually bigger than that needed to produce it." (04:50)
- "You don't want autonomy without accountability." (06:21)
- "No more slop." (07:49)

## Tools & references mentioned
- Oxford English Dictionary
- Brandolini's law
- Paul Rambles
- Sora
- Sam Altman
- Netflix
- K-pop Demon Hunters
- Game of Thrones
- AI Engineer News
- Claude
- Mahesh and Barry
- Devin
- Cognition
- Anthropic
- Greg Brockman

## Who should watch
- You are approving AI-generated code based on how much was produced or how long an agent ran, without a clear review of its quality.
- Your team is adding AI to development and needs practical ways to preserve codebase understanding and human judgment.
- You are building prompts, skills, or agent workflows and want to reduce generic, inaccurate, or low-quality output.

## Related talks

- [Beyond the Prototype: Using AI to Write High-Quality Code](https://aietalks.com/talks/beyond-the-prototype-using-ai-to-write-high-quality-code) (Josh Albrecht, Imbue, 17:59)
- [Ending AI Slop](https://aietalks.com/talks/ending-ai-slop) (Thais Castello Branco, Taste Labs, 16:30)
- [Don't Build Slop (4 Levels of AI Agent Maturity)](https://aietalks.com/talks/dont-build-slop-4-levels-of-ai-agent-maturity) (Ara Khan, Cline, 18:52)
- [Fighting Slop with Slop](https://aietalks.com/talks/fighting-slop-with-slop) (Vaibhav Gupta, Boundary, 21:32)
- [The State of AI Code Quality: Hype vs Reality](https://aietalks.com/talks/the-state-of-ai-code-quality-hype-vs-reality) (Itamar Friedman, Qodo, 21:15)
