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 <other major tech company> told me that his company has one too. Token usage leaderboards are obviously stupid because 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
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 using tool.
Week 4: Build what is needed to impress <customer>. (You can figured out what that entails.)
Week 7: Figure out how to ask our internal AI how to figure out what your next assignment is.
That was 3 weeks ago. Since then I have stopped asking my boss what to do entirely and instead I just go directly to our (internal) user and figure out what to work on from there.
This is in stark contrast from my first programming job. Back then, we used an "Agile" management system. A designer would carefully write specs for engineers to implement. These tickets would go into spec-tracking software that we all secretly despised. Engineers would take these specs (or be assigned them) to implement. Bugs were tracked in the same software.
While the slopware company I work for does have spec-tracking software, it's not an oppressive overlord anymore—just a glorified formal messaging platform. My boss uses it to give me assignments from time to time, but most of my assignments are never logged in the spec-tracking software at all. Why not? Well…it all has to do with the process of making features. The process goes design → implement → test
In the world of artisanware, a designer could design in 5 minutes of English a spec that would take a programmer days or weeks to implement in Python. Since designer could design faster than programmers could program, it made sense to hire one designer to write specs for several programmers.
But now that "5 minutes of English" design spec just gets fed into Claude Code. It still needs to be tested, but the human "implement" phase has gone from the most expensive phase to the cheapest phase. It no longer makes sense for a "designer" to write a spec for "programmers" to implement. If you do that, your good programmers will complain about not having enough work to do, and your bad programmers will slack off.
Instead, the solution is to let LLM agents replace programmers, and for programmers to move up the value chain to where their primary job is to figure out what to implement. This is why I write most of my own assignments, and why the instructions from my boss are very vague—stuff like "build whatever person needs".
Going Too Fast
In the past, a bad artisanware programmer was someone who got little done and introduced bugs into the code. Today, it is easy to get lots of work done with Claude and it is easy to get Claude to write bug-free code (for some narrow definition of bug-free). So, what is a bad programmer in the world of slopware?
As usual, bad slopware programmers make bad architectural decisions, name things confusingly and break existing workflows—but that is all business-as-usual. In one very important respect, bad slopware programmers are the opposite of bad artisanware programmers. Bad artisanware programmers wrote too little code whereas bad slopware programmers write too much code.
Is it possible to write too much code? If your job is to implement specs handed down to you by a designer, then no, it is impossible to implement too much. But if your job is to write specs, then any designer can tell you YES IT IS ABSOLUTELY POSSIBLE TO PUT STUFF IN THE SPEC THAT SHOULD NOT BE THERE. Half the job of a designer is deciding out what not to implement, especially in the domain of UX design.
If you're working with a bad slopware programmer, then that programmer will implement lots of features that shouldn't exist. This will clutter up your code, your database, and most importantly your UX. The best way to avoid this is to work with only good slopware programmers, but even the best will accrue UX bloat over time, if they're moving fast enough. One solution is good user analytics. Track what gets used, and delete what doesn't.
Another solution is ownership. Code rot is proportional to speed of development. When development happens much faster, so does code rot. When writing slopware, it is especially important to draw clear lines of ownership so that if code rots it is unambiguous whose responsibility it is to clean it up.
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 <other major tech company> told me that his company has one too. Token usage leaderboards are obviously stupid because 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:
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 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.
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.
That was 3 weeks ago. Since then I have stopped asking my boss what to do entirely and instead I just go directly to our (internal) user and figure out what to work on from there.
This is in stark contrast from my first programming job. Back then, we used an "Agile" management system. A designer would carefully write specs for engineers to implement. These tickets would go into spec-tracking software that we all secretly despised. Engineers would take these specs (or be assigned them) to implement. Bugs were tracked in the same software.
While the slopware company I work for does have spec-tracking software, it's not an oppressive overlord anymore—just a glorified formal messaging platform. My boss uses it to give me assignments from time to time, but most of my assignments are never logged in the spec-tracking software at all. Why not? Well…it all has to do with the process of making features. The process goes design → implement → test
In the world of artisanware, a designer could design in 5 minutes of English a spec that would take a programmer days or weeks to implement in Python. Since designer could design faster than programmers could program, it made sense to hire one designer to write specs for several programmers.
But now that "5 minutes of English" design spec just gets fed into Claude Code. It still needs to be tested, but the human "implement" phase has gone from the most expensive phase to the cheapest phase. It no longer makes sense for a "designer" to write a spec for "programmers" to implement. If you do that, your good programmers will complain about not having enough work to do, and your bad programmers will slack off.
Instead, the solution is to let LLM agents replace programmers, and for programmers to move up the value chain to where their primary job is to figure out what to implement. This is why I write most of my own assignments, and why the instructions from my boss are very vague—stuff like "build whatever
Going Too Fast
In the past, a bad artisanware programmer was someone who got little done and introduced bugs into the code. Today, it is easy to get lots of work done with Claude and it is easy to get Claude to write bug-free code (for some narrow definition of bug-free). So, what is a bad programmer in the world of slopware?
As usual, bad slopware programmers make bad architectural decisions, name things confusingly and break existing workflows—but that is all business-as-usual. In one very important respect, bad slopware programmers are the opposite of bad artisanware programmers. Bad artisanware programmers wrote too little code whereas bad slopware programmers write too much code.
Is it possible to write too much code? If your job is to implement specs handed down to you by a designer, then no, it is impossible to implement too much. But if your job is to write specs, then any designer can tell you YES IT IS ABSOLUTELY POSSIBLE TO PUT STUFF IN THE SPEC THAT SHOULD NOT BE THERE. Half the job of a designer is deciding out what not to implement, especially in the domain of UX design.
If you're working with a bad slopware programmer, then that programmer will implement lots of features that shouldn't exist. This will clutter up your code, your database, and most importantly your UX. The best way to avoid this is to work with only good slopware programmers, but even the best will accrue UX bloat over time, if they're moving fast enough. One solution is good user analytics. Track what gets used, and delete what doesn't.
Another solution is ownership. Code rot is proportional to speed of development. When development happens much faster, so does code rot. When writing slopware, it is especially important to draw clear lines of ownership so that if code rots it is unambiguous whose responsibility it is to clean it up.