Is getting the same output as everyone else bad? I'd say not necessarily. When you're making something, you might want to spend your "innovation tokens" on the core of what you want to do better. Then do a good-enough job at everything else.

To me it feels like the subtext in this is that making things more accessible is bad because then your stuff isn't unique anymore? I do not think this zero-sum / scarcity mindset is really accurate or helpful, IMO.

> What shipped, who's using it, and how it's helping them matters FAR MORE than lines of code, prs merged, tokens spent, or the number of agents running in parallel.

Sometimes when I hear shocking amounts of money spent on AI tokens, I wonder if someone's obsessing over the tech and forgetting that only the result matters.

Slop is when we put less effort into producing something than we ask the consumer to spend understanding it.

This really connect with the latest conversations I had with coworkers regarding how can we review gigantic PR generated by AI. One way could be to ask the submitter to give their prompt as part of their contribution. This way it's easier for the reviewer to understand what was the thought process of the contributor and if this very process is sound. Not saying that this way to review is a silver bullet, but at least it removes some weight.

1. PRs come with "the prompt". In openspec parlance this is a set of docs: a proposal, design, specs, task list.

2. I have a tiny skill to slice and dice PRs, so I can review each part of the system separately by rewriting commits in order of reviewal: specs/docs, production code, tests, evidence. I sometimes pull DB queries to a separate commit for focused review.

3. The evidence bit is built by another skill: go over all added spec scenarios and produce a markdown document with links to the code implementing the scenario and the tests proving the implementation works. Emacs helps me jump back and forth via those links and read the parts I'm interested in.

My next goal is to extend openspec schemas with custom workflow steps to make PRs land in my preferred review structure and contain the evidence report, so I don't have to build it.

The discipline of splitting them up helps in almost every dimension.

To add to my openspec shilling above, I've been known to "fix" large PRs by reverse engineering specs from them and building each spec out in a separate PR.

Last week me and a coworker turned a 15k line PR into 10 x 1.5k line ones that went in smoothly.

For a rewrite, I guess sometimes it's better to have a spec then write to that, and PRs might be larger.

That was a comment written in a particular context, where the original commenter was concerned with large PRs.

>> how can we review gigantic PR generated by AI.

It was not a comment written in a vacuum saying that all PRs should be small (or not large, whatever that means). Though grey-area does provide some reasonable commentary for why it's good to shrink them (easier to roll back, easier to isolate bugs, etc.). Maybe grey-area does mean to ban all large PRs, but that's not evident in this thread where they wrote a response to a specific comment offering their take on how to resolve the problem raised in that first comment.

> You're loosing big swing aggressive efforts to make sweeping progress.

Just a tip: "losing" not "loosing". We loose arrows at our enemies, we let loose the dogs of war, we loosen our purse strings. But we do not "loose big swing aggressive efforts", we "lose big swing aggressive efforts". It's funny that you get it right once, but mix the two up in the very next sentence.

What are the PRs you're thinking of though. If you mean a full clean rewrite, they'd probably proceed with spec first then just write it in bits to the spec. No reason it has to be large prs or smaller that's a design choice.

Often an exercise I find useful is do a quick big PR, then split it into small chunks that make sense independently for review. Or you can chain prs. Both those things can be done.

You're welcome to do large PRs, I'm not a fan of huge PRs though and would not pretend to review them (as pretending is what it would be), nor would I like to work somewhere where this is the culture.

Zed's delta (https://delta.dev/) seems to be solving this problem by extending the version control to the conversation layer. I don't know if I'd want all my conversation to be tracked, some stuff belongs to the draft sheet.

I also think that might not be everything you need to really vet/recreate those PRs since there's a lot of strategic and operational stuff that goes into the pre-composition runs (sometimes I actually throw everything away and restart), so something a little more sophisticated would be interesting.

However, having a rigorous spec process which ends up giving lots of details to the agent seems to me the right way to build stuff with LLMs. Rather than iterating and piling changes after changes.

Claude absolutely loves to reimplement the wheel locally instead of just calling a method in a library we already depend on. Every doc comment and README.md update is bloated by 2-5x what's needed to communicate intent or to actually be read by a human later. It makes random drive-by edits that aren't necessary and weren't asked for in the prompt. It's a well oiled machine for producing astronomical bloat by default if you don't supervise and rein it in!

I had a recent case where I, being the lead, sliced up the work real good into an epic and what not and a guy on the team just did a "hurr durr, Claude, go wild with all that" and threw a huge PR over the wall linked to 5+ stories.

Well, we got to have "the conversation" after that and learned how to fix these kinds of PRs together...

AI has really disrupted that, and I’m thrilled to see folks trying to bring back the best parts of it (namely shared understanding and contribution). But I agree with others, making the movement anti slop feels the wrong way around. What it’s getting at IMO is deep understanding and shared understanding are crucial to human progress, and reckless AI use compromises that

--------

We are uncovering better ways of developing systems by using AI and guiding others to use it responsibly.

Through this work we have come to value:

    Human accountability over delivery velocity
    Human dignity and control over unsupervised autonomous execution
    Human augmentation over replacement
    Impactful outcomes over raw code generation
    Human collaboration over individual uplift

There is a lot of value in the fact that none engineers can build products now! Should AI products adhere to a certain quality standards? Yes! Should they be treated similarly as "human created" ones... Well, yes. Like it or hate it.

Faster definitely, but even with the latest Fable model "better" is often debatable and varies a lot based on what you care about. I can often rewrite what Claude did in 1/2 the lines or less to do the same thing while making it easier for humans to understand and maintain. Claude gives me a sculpture in a good rough starting shape, but it usually needs to be sculpted down at the end whether manually or by prompting Claude about the unnecessary bloat it generated.

A major reason slop exists is because they are not "better" at coding, given some subjective criteria. They are notably worse at documentation and somewhat poor at choosing abstractions in my experience. For the most part, I witness the tools copying other examples out of the working repository, which makes them exactly as bad as the humans who originally wrote the code.

> will always code at a lower level with the time passes

For humans, this is traditionally an anti-pattern. We are good at intuiting abstractions and knowing when to use them or climb up and down the abstraction hierarchy. For LLMs, this is also an anti-pattern, because going lower-level is an exponential waste of tokens; both for writing and reading the resulting code, which they do constantly in order to understand the project again and again in order to fulfill your prompts.

Thinking of human review as a "bottleneck" is incorrect framing. We are quality control. You can choose to cede quality control to LLMs and agent harnesses, that's up to you. In my experience this generally leads to a meteoric rise in slop, because the tools increasingly resort to writing more code to solve a problem instead of updating existing code or writing the correct code. When I shake my head at some slop code, then read the slop comment that uses some slop justification that isn't real and only existed in the prompt context, I am happy that I took the time to review it. Maybe that makes me a bottleneck, oh well.

And this is something that has always happened. Way earlier than current AIs we had already coined the term "shovelware" that was mostly a large quantity of sloppy software. We also had plenty of sloppy drawings at sites like DeviantArt. AI just made it way easier for slop to happen, but the ones producing slop are always people.

What does alpha mean in this case? I only understand this term in from a finance perspective (excess returns). Is it used here to mean 'value'? E.g. there is always value in reviewing something?

Will "No AI[1] slop, aim for understanding system we ship in human brains instead" be advantageous in capitalism? I sincerely doubt it. And that makes me sad. Even in the public sector, I now am expected to deliver faster, since the industry changed comparable outputs of our private contractors.

[1]: Or, to prevent ``slop'': at least, no speed-up beyond catching up to what was still well-thought out in terms of input and/or reviewed by humans. AI can still be a tool, but must never take all roles in a process from gradle to grave.

So true, I feel guilty not fighting it at the place I work at, but it seems impossible.

This manifesto gives me a spark on hope I haven't felt in months.

This feels directionally right, but if you define slop this way then you put a cap on AI productivity. For example, I heard an interview with Terry Tao talking about how the work of mathematicians is now to understand the proofs generated by AI. He's, by definition, describing these groundbreaking proofs as slop (by the above definition).

The comparison doesn’t work for the music industry, at least. Many hit songs are written and produced on a whim, while people analyze it for years.

I think the problem with those Maths proofs was they were massively rushed and OpenAI just couldn't be bothered to do it properly or actually check them. They were more interested in the PR than in helping advance Mathematics.

Oh no, the horror

Industry: "What makes you think software not sucking is part of our equation?"

It really boggles my mind. I mean, come on just reuse the curriculum from the past 20 years. You do have that don’t you? Don’t you?!

This sounds like slop. Like an engagement bait. Also a no slop manifesto should start by defining “slop” as the first thing. That’s not something for the comment section.

> AI cannot replace human judgement, it can only amplify our judgement (or lack thereof)

Why not? Did you mean should not.

When you put it like that, seems the problem is on the human side

I'd say the cost actually grows as people get laid off left and right, and on top of that, a 1000 line PR from a good human, give me a case of beer and I'll make me some sense of it, but if it's AI slop, get ready to hand me a crate of homemade Slivo or I won't touch that...

More than 20 apps developed in the last six months, all top quality, I haven't coded a single line, speed and output is what matters, results improving by the day and will be unrecognizable in a couple of years by any metric

AI is unstoppable and no matter how many manifests luddites write AI won't care

It sounds to me like you're arguing against this point in particular.

More power to you. I'd like never to work at a place that sanctions slop-validated-slop.