David recently posted a tweet saying he’s obsessed with a Codex Skill called [Ian Xiaohei Illustrations](https://github.com/helloianneo/ian-xiaohei-illustrations), which he uses to generate accompanying images for Chinese articles. He says this skill made him realize that with proper guidance, AI can absolutely produce truly unique, non-slop work. “AI slop is just a process problem.”

This line is the key to understanding his other long-form article, [Building software factories (with no slop)](https://x.com/i/article/2090141685116510208). That article explains why modern codebases are getting messier and messier, and how to fix the problem.

David’s argument is straightforward: AI’s code-writing capability is already very strong; the problem lies in the review step. Code generation speed improves every quarter, but the speed at which humans can read code is fixed. When output far outpaces review capacity, review becomes a formality — you glance over it, mark LGTM, and quality drops as a result. So the root of slop is that the process bottleneck is human reading.

His solution is to treat the codebase as a black box. Instead of reading every line of implementation, you split the system into domain-independent modules, each with clear inputs and outputs, add sensors to check output behavior. At the same time, you have AI log all out-of-spec decisions to form a “decision ledger” — you only read the ledger, not the diff. He says he ran an unattended 1 day 16 hours job, and only reviewed the ledger at the end, never looked at the code.

This approach sounds counterintuitive, but he points out we’ve been doing this all along: none of us have read every line of the third-party packages our projects depend on, and we still ship them anyway. Accountability was never built on reading code — it’s built on a system structure that lets problems surface.

So what’s this illustration skill all about? It’s a Codex Skill built by Ian (@ianneo_ai) that turns the judgments, processes, and concepts from Chinese articles into plain white, hand-drawn, quirky illustrations. The main character is “Xiaohei”, a solid black stick figure with white dot eyes, thin legs, and a blank expression. It’s not just decoration — it’s an “absurd worker” that participates in the system’s operation.

David used this skill to generate several images for his articles, like these ones below:


This image depicts a “software factory”: a machine that takes “intent” as input on the left, goes through “bounded”, “sensored”, and “audited” steps, and outputs “verified behavior” and a “decision ledger”, with a trash can labeled “slop” at the bottom. This is his concept of a software factory: intent goes in, behavior comes out, code is just an intermediate product.


This image shows a spectrum of code from readable to machine-native: on the left is readable code like `if(x>0){total+=x;}else{total-=x;}`, it becomes garbled in the middle, and becomes a black box on the right connected to a device that says “watch behavior”. The point is that code will eventually become unreadable to humans, but we can still validate it by observing its behavior.


In this image, Xiaohei stands on a stool, feeds a “business problem” into the machine, turns the crank, and out comes a gift box labeled “solved problem”, with “code is the medium” written below. This is his definition of a software engineer: the output is a solved problem, not code.

These images aren’t generated randomly. Ian’s skill has a defined process: first it analyzes the article’s cognitive anchors and outputs a shot list, with each image communicating only one core action, then it reinvents a low-tech physical metaphor, has Xiaohei perform the core action, and finally checks against a QA list. By default it outputs 16:9 landscape, pure white background, black hand-drawn linework, with a small amount of red/orange/blue Chinese annotations.

Ian clearly states in the repo that this skill is not a generic illustration prompt, nor a PowerPoint infographic template. It’s for people writing Chinese articles, knowledge content, and AI workflow content who want an illustration style that’s lighter, quirkier, and more recognizable than standard infographics. It’s not suitable for commercial illustration, complex architecture diagrams, or children’s cartoons.

What’s interesting is that in the replies to his tweet, David said someone pointed out this style is similar to another account @illo_skill, and he replied “a little, but the style is very different”. This detail shows that AI illustration has already developed personal style differentiation.

Going back to the opening line: AI slop is a process problem. The reason these illustrations aren’t slop is the constrained process: fixed style, fixed Xiaohei IP, one concept per image, forced metaphor reinvention, and QA checks. The process turns AI from “free creation” into “bounded creation”.

David’s software factory follows the exact same logic: give AI clear boundaries (domain modules, inputs/outputs, sensors), shift validation from “reading code” to “checking behavior” and “checking decisions”, leaving code itself as a black box. Both cases follow the same principle: don’t make humans read AI’s raw output — instead, design a system that lets AI output be structurally validated.

So it’s true: AI slop isn’t a model problem. It’s that you’re still using old processes to handle new output volumes.