No AI Slop Manifesto Unites Builders Publicly

The document opens with a ski lodge. In 2001, the No AI Slop Manifesto reminds readers, 17 software engineers and leaders met at Snowbird in Utah to face the heavy process that ruled their work, and they left with the Agile Manifesto. A quarter century later, speakers and attendees at AIE Code Summit 2026 have borrowed that exact frame to face a different weight, the sheer volume of work that AI can now produce before anyone has read it.

The borrowing is the point. This is not a ban on AI, and the signers say so in plain terms. It is a pledge about review, intent, and taste, written by people who build with these tools for a living and who admit, in the second sentence of their own text, that most of them have sent slop themselves.

The Bigger Story

The manifesto sets out five values, then nine beliefs, then a set of resolutions that runs to 22 numbered points in total. The values are short enough to quote in full, because their order matters. Outcomes over output. Understanding over speed. Our own thinking over a model first draft. Better work over easier work. Improving the system over patching the output.

The beliefs give those values a diagnosis. A swarm of agents, the document says, can produce more work in a single day than a person can review in a lifetime. Slop happens when a builder passes AI output along without taking responsibility for the quality or for the experience of the person who receives it. AI cannot replace human judgement, the signers argue. It can only amplify judgement, or the lack of it.

That definition does useful work. It does not ask what tool made a thing. It asks who paid attention, and how much attention the next person must now pay because the first person paid too little. A thousand line change and a ten page plan are the examples the document reaches for, and both are familiar to anyone who has opened a review queue on a Monday morning and felt the week tilt.

The asymmetry is the engine of the whole piece. The cost of producing that change or that plan is falling toward zero, the manifesto notes, while the cost of reviewing it stays where it always was. Every cheap page therefore bills someone else. Multiply that bill across a team, a codebase, and a shared store of documents, and the next problem appears. Slop compounds, because the next agent reads what sits in the store and copies it, and the team slowly loses the will to fight a flood that never pauses.

The resolutions try to turn that diagnosis into habits a team could actually keep. Own the intent, the taste, and the consequences of what you ship, however much AI helped you make it. Say clearly when an agent wrote something you are sending, and check the parts that matter before it goes out. When someone sends you slop, tell them kindly and ask them to review it first. When the same mistake shows up twice, fix the system and its guardrails instead of fixing one more output by hand.

Latent Space, the newsletter of the AI Engineer community, reported on November 13 that Hacker News had voted the manifesto to its front page that day. The editors said they started it to offer a useful tool for discussion at work, and hoped it would be used that way. That modest hope may explain the speed of the signatures. A document a manager can drop into a team chat without starting a fight is a rare thing in this debate.

Context

Manifestos have a history in software, and the history is mixed. The Agile Manifesto, published at agilemanifesto.org, offered four values and twelve principles in February 2001 and changed how most of the industry builds software, as the new document itself puts it. It also became, in the years after, a label that teams could claim while changing very little about how they worked. Anyone borrowing its shape in 2026 knows that risk is part of the inheritance.

The slop debate has its own recent history on this site. Our earlier feature Slop Is a Slur Now traced how the word moved from a narrow test, unrequested and unreviewed, toward a broad insult aimed at almost any work a model had touched. The manifesto lands firmly on the narrow side of that line. It states that using AI does not by itself make something slop, and it even defends quick, loose ways of building when the stakes allow them, noting that unreviewed output is not always bad and becomes bad when it undermines the outcome.

1. 2001Seventeen practitioners meet at Snowbird, Utah, and publish the Agile Manifesto with four values and twelve principles
2. November 2025Swyx gives a talk titled No More Slop at AIE Code Summit, listed in the new manifesto as a resource
3. 2026Speakers and attendees at AIE Code Summit 2026 publish the No AI Slop Manifesto
4. November 13, 2026Latent Space reports Hacker News voting the manifesto to its front page
5. November 14, 2026The signature list in the public document reaches 391 names when checked for this article

The resources the signers chose to link tell their own story about where this argument has been building. The list includes that Swyx talk from the 2025 summit, a piece by Tejas Kumar on keeping slop out of his own writing, and the AI usage policy written by the maintainers of Ghostty, a terminal project. None of those sources calls for abandoning the tools. All of them circle the same demand, that a person stay able to explain and defend the work with their name on it.

Pressure sits inside the document as a cause, not as an excuse. A lot of slop comes from pressure, belief seven says, as companies push their people to redefine what is humanly possible. That line matters because it moves blame upward. A junior builder who ships an unread plan under a deadline set by someone else is a symptom. The system that set the deadline and counted the output is the subject.

Different Perspectives

The strongest support so far has come from readers who treat the manifesto as an operating rule rather than a slogan. Writing on November 14, Ken Ashe argued that slop is not a model category but an accountability category. If a team cannot say who checked a claim, why a piece exists, who it serves, and what was removed, Ashe wrote, the team is not publishing. It is spraying. His practical version adds checks before scale, a named owner for each piece, and review that removes weak output instead of polishing it.

That reading has force because it can be tested. A team either has an owner and a rejection standard or it does not. A review either removes work or it waves work through. Ashe also notes the cost that makes teams resist such checks. They feel slower at first, because review, source discipline, and taste take time that raw production does not.

A second view is cooler about the form itself. A signature costs nothing, and a public list of names can become a badge that a builder wears while their daily habits stay the same. The manifesto has no test, no audit, and no consequence for a signer who ships an unread thousand line change next week. Its own final belief concedes the limit in advance. None of us has this figured out, the signers write, and there is no single right answer. Readers who lived through the Agile years will recognise the pattern. A short document can start a real change in one team and become wall decoration in the next, and the document itself cannot tell you which fate is coming.

A third view asks whether review can scale at all in the way the manifesto hopes. The document grants part of this point. Agent reviews, linters, and verifiers are useful but not sufficient, it says, and for now a person should still review at least some subset of the output, with the subset set by the stakes. It also grants that what gets reviewed will change as models improve. A builder may stop reading most of the code and still review a plan, a design, or a result. That concession keeps the pledge honest. It also leaves the hardest question open, which subset is enough when the volume keeps rising and the reviewers do not.

Why It Matters

What shipped and how it helps the people using it matters far more, the manifesto argues, than lines of code, changes merged, tokens spent, or the number of agents running at once. Read that as a measurement claim and it bites deep. Most dashboards in this industry count production because production is easy to count. The manifesto asks teams to count consequences instead, which are slower to see and harder to fake.

It also reframes a debate that has grown lazy. Public argument about AI work often splits into camps that defend any use of the tools or condemn any use of them. The signers refuse both camps from inside the builder community. Their complaint is not that a model helped. Their complaint is that nobody did the human part of the job, the thinking before the prompt, the reading after the output, and the willingness to put a name behind the result.

That is why the document travelled beyond one conference in a matter of days. Almost every knowledge worker now sits on at least one side of the asymmetry it names. They have received the long, smooth, empty document that took minutes to make and an hour to untangle. Many have also sent one, under pressure, on a day when the queue was long and the deadline was not moving. A text that names that shared experience without shaming the people caught in it gives a team a language it did not have on Monday.

Closing Reflection

A manifesto cannot review your next change for you. It cannot read the plan, catch the invented detail, or tell the sender, kindly, to look again before the work lands on a colleague. Only habits can do that, repeated on ordinary days when nobody is watching a signature list grow.

But habits often start with a sentence a group can repeat to each other without embarrassment. Outcomes over output is such a sentence. So is the simple test at the heart of this document, that the maker should spend at least as much effort as the reader will. If those two lines survive the week after the front page moment, the signatures will have meant something. If they do not, the flood will have gained one more well written page, and the manifesto itself will face the verdict it wrote for everyone else.

Facts checked November 14, 2026, against the full text of the No AI Slop Manifesto as published by its signers, Latent Space reporting of November 13, 2026, and commentary published November 14, 2026. The signature count is the count shown in the public document at the time of checking and may have grown since.

Sources

• The No AI Slop Manifesto, written by the speakers and attendees of AIE Code Summit 2026: https://gist.github.com/dexhorthy/4cc96f01be5b1208519e75dad250a948
• Latent Space, AINews, The No AI Slop Manifesto, November 13, 2026: https://latent.space/p/ainews-the-no-ai-slop-manifesto/
• Ken Ashe, AI Slop Is an Operating Failure, November 14, 2026: https://kenashe.ai/blog/2026-11-14-ai-slop-is-an-operating-failure/
• The Agile Manifesto, 2001: https://agilemanifesto.org/
• Hero and body images: Dirty Static illustrations