LessWrong

The Art of Shipping Slopware

Brief

In practice lsusr reports organizational change: spec-tracking tools become messaging, managers give vague goals, and engineers consult internal users and LLMs to produce features. Major risks include overproduction of features (UX bloat) and faster code rot; recommended controls are product analytics to prune unused code and strict ownership for cleanup. Commenters add important caveats: Brendan Long says LLMs often duplicate or over-abstract code and miss related copies, creating maintenance and performance headaches (unnecessary sequential I/O), while Karl Krueger recommends stronger network-behavior monitoring (e.g., detecting novel activity from an Artifactory caching proxy and auto-suspending VMs) or airgapping to prevent sandbox escapes.

Why it matters

lsusr (LessWrong post, 2026-08-02) reports that Meta and another unnamed big-tech firm run internal AI token-usage leaderboards that create 'tokenmaxxing' incentives; a friend at the other company felt tempted to waste tokens to rank higher.

Key details

  • lsusr argues LLMs (examples named: Claude, Codex; frontier models: Opus 4.8 — May 2026, Fable 5 — June 2026) are materially cheaper than humans for implementation work, so 'slopware' (AI-written software) should replace 'artisanware' where the LLM matches human quality; he cites GPT-5.6 Sol: "LLMs find code readable when the program’s behavior and intent can be inferred from a small, local region of text," and summarizes 'skills are the new source code.'
  • Management and workflow change: lsusr describes shifting from classic Agile/spec-driven work to asking internal users directly and using spec-tracking tools as lightweight messaging; because implement is now cheap, programmers should move up to deciding what to implement rather than merely coding specs.
  • Operational risks and mitigations: slopware teams tend to overspec and 'write too much code,' producing UX bloat and faster code rot; recommended countermeasures are usage analytics to delete unused features and strict ownership boundaries for cleanup.
  • Community responses: Brendan Long warns LLMs often duplicate code and miss parallel copies (creating incoherent codebases and testing blowup) and still require human intervention to prevent performance errors (e.g., unnecessary sequential I/O); Karl Krueger suggests detecting sandbox escapes (e.g., via an Artifactory caching proxy) with behavioral network monitoring and automated VM suspension, noting airgapping as preferable.
Cleaned source text

Meta famously created an internal AI-usage leaderboard in pursuit of tokenmaxxing. I thought this backwards incentive structure was an anomaly until my friend who works at told me that his company has one too. Token usage leaderboards are obviously stupid because of incentives. My friend was tempted to waste tokens just to get on the leaderboard, and only his personal honor stopped him.

Tokenmaxxing leaderboards illustrate that big tech companies have no idea how to best use AI to accelerate software development. Most seem to have bought their programmers subscriptions to Claude/Codex and otherwise continued business as usual. In my experience, this is a mistake. LLM-based software development is different enough from artisan software development that it requires brand new best practices.

The frontier is moving fast. Best practices for Fable 5 (released in June 2026) are different from best practices for Opus 4.8 (released May 2026). For this reason, I'm going to pretend that Fable 5 is the best LLM we'll ever get. This post may be obsolete in a matter of months.

Programming Top-Down

The most important thing to understand about writing software is that human labor is orders of magnitude more expensive than LLM labor. In practice, LLMs are always cheaper than humans. If an LLM can do a task as well as a human being, then the LLM should do the task. Consequently, artisanware (human-written software) should never be shipped when slopware (AI-written software) can do the job.

Traditional software companies have not internalized this. Often, at established companies, the following happens:

A junior programmer writes code with Claude.

A senior programmer reviews the code, declares it ugly and unmaintainable, and commands the junior programmer to write it by hand instead.

I can understand why this happens. For decades, the only way to prevent bugs in software was for human beings to review code line-by-line. Therefore, artisanware is heavily-optimized to be human-readable.

But in the age of slopware, that doesn't matter. LLMs are way better at reading and reviewing code than human beings are. Having a codebase that is easy for LLMs to read is way more important than having a codebase that is easy for humans to read.

What makes code readable to LLMs? Let's ask an LLM.

LLMs find code readable when the program’s behavior and intent can be inferred from a small, local region of text. The main enemy is not complexity per se; it is hidden context.

―GPT-5.6 Sol

LLMs program top-down. They tolerate verbosity so as to minimize bespoke dependencies [from outside of their training data]. This is precisely the opposite of how Paul Graham advises writing powerful, maintainable artisanware.

It's worth emphasizing that bottom-up design doesn't mean just writing the same program in a different order…you will get a larger language with more abstract operators, and a smaller program written in it

―Programming Bottom-Up by Paul Graham

This is not to say that slopware does not contain custom abstract operators. Slopware does. It just doesn't do so at the level of source code. It does so at the level of skills. Skills are the new source code.

Management

A few weeks ago, I posted the following in our company chat.

My boss's management style:

Week 1: Do

mjx-math {

display: inline-block;

text-align: left;

line-height: 0;

text-indent: 0;

font-style: normal;

font-weight: normal;

font-size: 100%;

font-size-adjust: none;

letter-spacing: normal;

border-collapse: collapse;

word-wrap: normal;

word-spacing: normal;

white-space: nowrap;

direction: ltr;

padding: 1px 0;

mjx-container[jax="CHTML"][display="true"] {

display: block;

text-align: center;

margin: 1em 0;

mjx-container[jax="CHTML"][display="true"][width="full"] {

display: flex;

mjx-container[jax="CHTML"][display="true"] mjx-math {

padding: 0;

mjx-container[jax="CHTML"][justify="left"] {

mjx-container[jax="CHTML"][justify="right"] {

text-align: right;

mjx-mi {

mjx-c {

mjx-utext {

padding: .75em 0 .2em 0;

mjx-c.mjx-c1D465.TEX-I::before {

padding: 0.442em 0.572em 0.011em 0;

content: "x";

mjx-c.mjx-c1D466.TEX-I::before {

padding: 0.442em 0.49em 0.205em 0;

content: "y";

mjx-container[jax="CHTML"] {

mjx-container [space="1"] {

margin-left: .111em;

mjx-container [space="2"] {

margin-left: .167em;

mjx-container [space="3"] {

margin-left: .222em;

mjx-container [space="4"] {

margin-left: .278em;

mjx-container [space="5"] {

margin-left: .333em;

mjx-container [rspace="1"] {

margin-right: .111em;

mjx-container [rspace="2"] {

margin-right: .167em;

mjx-container [rspace="3"] {

margin-right: .222em;

mjx-container [rspace="4"] {

margin-right: .278em;

mjx-container [rspace="5"] {

margin-right: .333em;

mjx-container [size="s"] {