Slop factories and agent skills

I originally drafted this post half a year ago, when the slop factories landscape looked very different than now. I've changed my mind on the matter mostly because of how useful the Fable (and then sl0pus 5.5) models turned out to be. I wouldn't have reached the point I am at right now if not for the research I did back then, including all my past skepticism that I'd like to present here.

Sit back and enjoy the ride, as I decompose the psychosis around automated software factories, walk you through what I learned, and showcase what actually worked for me in the end. Here are my notes from back when I analyzed the workflows and tools of most prolific vibe coders... And what I ended up with half a year later.

Human bottleneck#

There are different levels of the programmer's involvement that you can operate on:

1. trad coding - doing everything by hand, the old-school way
2. tab coding - relying heavily on LLM autocomplete in your IDE
3. copilot in the sidebar - whether for research, reference, or delegating small units of work
4. agent and editor in two panes - you are the one doing small units of work when most is done in cooperation with the LLM
5. agentic engineering - when all you're doing now is planning and code review, everything in between is fully delegated to the LLM, and you've created a new workflow around it
6. agent orchestration - decision making delegated to the LLM managing multiple subagents, you only feed the system with more tasks and it burns tokens itself
7. agentic swarm overlord - that's where we land eventually; you don't care anymore, only note down ideas as they come

As you go further down this list you can see how it becomes easier to tackle multiple things at once. You can also mix different kinds of work that require different levels of involvement. Sometimes you want to learn something new, so entirely delegating the task misses the point. On the other hand, there are certain projects that don't matter enough to warrant a lot of human time spent on them. During a single workday you could delegate a few less important tasks to the autonomous agent swarm while you work by hand on a high-stakes task around a more important code path, and in the background another TUI agent works out some refactoring task with your direct guidance. If this sounds tiring - I can assure you it is.

With all these approaches the human is always the bottleneck of the process, only with different throughput characteristics. You can't really work on that many things at once by hand. There's only one editor in which you can actively type. The upside of this is presumably deeper understanding of the project or system. For most people on most projects this is likely just wishful thinking tho. Close cooperation with the LLM helps get that quick understanding. It gets worse the more work you delegate.

Delegated thinking#

You can't instantly respond to all agent messages, but you can decrease the amount of your input required per chunk of work. Why bother with the internals if you can have multiple LLMs check each other's work? You don't need to think anymore. You can't make informed decisions about the project anymore. You fall into the trap of delegated thinking and start regressing instead of progressing faster.

It's really sad to see people treat LLMs as the absolute source of truth. Instead of reading the source material or doing minimal research many people instead rely on Google's AI Overview, GPT, or Claude, whichever had better marketing that week, to ask and judge things for them. Attributing any sort of higher intelligence or insight to a fancy autocomplete is straight up insanity. I've heard of cases where a person will not listen to any arguments unless coming from the ChatGPT WebUI. How can you disregard the opinion coming from a person in front of you in favor of made up blackbox authority? LLM spits out responses that are best aligned with the average of their training data, a bunch of random internet content, perhaps a preselected knowledge corpus. Is the average from that data really that much more "intelligent" than you or your interlocutors? Delegated thinking is the exact opposite of critical thinking and the death of informed judgement.

As models get more intelligent they really seem to beat the average. Still, I'd like to aim higher and strive to beat them at least in my own fields of expertise. Someone should understand things. The Chinese Room has no understanding of what it handles, even if it seems to demonstrate insight. It's still only a curved mirror. The more competent you are in reading through these curved reflections, the more sense you'll make of it.

Delegated quality#

Having an agent copilot in a side-pane, utilizing the new agentic engineering workflow, having a 24/7 personal LLM assistant with a dedicated operating system - these all feel really great. Yes, you certainly can do more using these tools, but there is also a point where you can start to over-delegate to your detriment.

In my opinion the key is to hit the right balance between direct involvement and development velocity. Cost, volume, quality - these should all be optimized at the same time. Unfortunately, most vibe coders forget that last part: quality. It also gets delegated to the "highest-quality" language model available at the time and flatlines there.

Spending more time in planning, review, and QA than on creation - I'm not quite sure if I like that option any better. LLMs can generate good enough code, but does it always meet the quality standards? It's just like a slot machine. To increase your chance of success you have two options: improve the chance per roll, or improve your volume of rolls.

Finding success through increased volume#

Agent orchestration is a compelling idea and a natural next step in the adoption of LLMs. We want to delegate more and think less. This is exactly what drives the tokenmaxxing trend and what inspires the creation of slop factories.

You will see a few common building blocks:

1. task management: kanban board or issue tracker
2. communication: direct handoff, messaging, chatgroups
3. heavily relying on markdown skills

Let's start with Peter Steinberger's OpenClaw. It's a personal autonomous agent with broad permissions and instant messenger integrations, which unlocks the full ability of LLMs to do things instead of just writing about them, but can also easily turn into a security nightmare. OpenClaw can use system shell like a user would, so Peter built out a lot of smaller CLI tools to further expand the abilities of his agents in a very natural way.

Maybe you shouldn't run this on your own personal computer, but in a virtual machine or a dedicated VPS, with dedicated accounts for the bot, it's a really nice experience. OpenClaw encourages you to role-play with it and works more like a personal assistant in your messenger of choice rather than an agent purely for coding. It can modify itself, do research for you, create custom software, run scheduled tasks, hand off tasks to other agents, do background work and report results when ready, and do pretty much anything on the host machine it runs on.

Steipete is employed at OpenAI as of writing this, so with unlimited inference for free he is truly on the forefront of tokenmaxxing and pushing it beyond the limit. He has great ideas and a lot of active projects going on.

Around the OpenClaw ecosystem he's built:

• clawhub - skills repository
• clickclack - team chat for agents
• codexbar - status monitor for LLM subscriptions (kinda like my llm-usage)
• crabfleet - mission control for a swarm of agents, managing codex instances running in cloudflare microvms
• and many more...

I'm curious to see what the next evolution of his workflow will be. I first tried OpenClaw back in January and February, so back when it blew up for the first time, and after a little break I went back to using it. It's useful, it feels good, it's something that might be worth investing your time in. Not necessarily with the goal of replacing yourself as a programmer, but for that competent personal assistant experience. It can do a lot of things for you if only you allow it. It gets more and more useful every time I come back to it.

The success of OpenClaw spawned many spinoffs. One particularly popular is the Hermes Agent. This one is more focused on getting work done. The agent's permissions are dialed back a little bit. It doesn't encourage role-play as much. It feels more like a harness for coding. It also supports multiple agent roles and has a nice optional kanban interface in addition. It's got very strong self-improving capabilities. The agent is meant to grow better as you use it more. To me it feels like it could be very useful, but so far I've had more fun using OpenClaw. I'm still experimenting with both.

Garry Tan is a heavy user of solutions like this. He came up with his own repository of skills (gstack) and a persistent memory solution (gbrain). I glanced through the gstack repo and the only thing I was impressed with was how much slop one can include with simple markdown instructions. Unfortunately I don't think Garry's opinionated anything is for me, so I skipped on test running it myself. You gotta give it to him tho: the idea of shipping software as a bunch of markdown files parsed by the LLM was interesting.

Next up: Jeffrey Emanuel. This guy makes clones and re-implementations of existing software. Pretty much anything he could ever use he regenerates with LLMs to flex on github with the insane volume of commits. Spending more time preparing a high-quality contribution would be more useful to everybody, but it doesn't farm as much attention and traffic. Of course I'm overly cynical here... For high-velocity changes it makes sense to reimplement the program from scratch rather than forking it. Moving fast alone is clearly the priority for him. Admittedly among all the clones he's also tried a few interesting things. Somehow I've ended up on his GitHub profile multiple times when researching my random "I wonder if something like this exists" ideas.

His workflow, the flywheel project, is very transparent and very well documented, including reasoning behind every part of his extensive toolset. I may have my own opinions about it, but I definitely agree with the overall direction. Much like steipete, Jeffrey creates a lot of custom CLI tools and his workflow heavily relies on them. His full setup is quite involved and very much custom-made. I'm pretty sure it feels amazing for him to use it, but I doubt anybody else would have the muscle-memory to utilize it effectively. Out of all the slop factories I looked at, this one seems to be the most hands-on practical. The user can still be in control of the high level plan, but delivery is greatly accelerated.

The flywheel core is simple:

• br - beads rust reimplementation for task/issue tracking
• bv - beads viewer TUI for task management
• Agent Mail MCP for coordination, agent-to-agent communication
• custom AGENTS.md documenting the workflow and CLI tools
• it works with any agent harness

I looked at more examples at the time, but I'll spare you details for what lacks proper educational value. Frankly, these systems left alone couldn't really produce any useful work by themselves. Even more involved setups would fail in practice. That was also the conclusion of my previous draft - perhaps we can improve efficiency, but full delegation was not possible then. It took a few more model releases, and a few more tooling refinements, to become a reality.

Let's try to find a common thread so far: agent harness that's easy to speak to, heavily customized tooling, accumulating learnings (skills, memory, agents guidance), keeping track of progress, making the best use of models' strengths, letting them cooperate. Sounds like this could be the key to going blazing fast.

Improving chances is a matter of skills#

There are a few ways to increase chances of getting higher quality output from a random language model. They are called "good engineering principles". The same exact approach as before the introduction of LLMs, only now packaged for modern times in the form of a few handy markdown skills. And better yet, adjusted for personal taste.

This is what Matt Pocock gets absolutely right (did you get the Claude pun?) with his skills. His proposed approach highlights the importance of defining problems precisely, using a common language, and clarifying ambiguities before they are baked into the codebase.

Impeccable follows a similar idea for high quality frontend work. It forces intentional design, drills in on the details, and helps improve both the UX and overall code quality.

Finally, superpowers is yet another repository that attempts to encode good engineering practices in the form of opinionated markdown skills. It provides a solid framework for effective and well-structured work with LLMs.

Agent skills can be used mainly in two ways: as a recipe on how to do certain things, or as guidance on what to do in certain situations. The aforementioned packs mix the two together to trigger certain desired actions (the what) and then shape the result of these actions towards desired goals (the how). You can often trigger skills by referencing them directly. Let me give you an example.

I used to rely on slash commands a lot to trigger certain behavior before. For instance, when I wanted a model to commit their changes with my preferred convention, I'd call /commit and wait for my agent to process the instructions that would be sent in place of that command. With skills I can invoke imperative-commits the same way and wait for the model to figure out that it is supposed to follow the instructions and commit changes; or the agent can pull this skill dynamically when it is trying to commit by itself. It references these same instructions as a guidance on how to do certain things. If any other skill references "imperative commits style", the agent will pull this skill and again reference my exact instructions as guidance. This shapes the result to what I like in a simple and repeatable way.

The skills can be composed too. My pr-ship skill that creates new PRs from WIP branches references pr-summary to shape the PR description just the way I like it. I can tell the agent to open up a PR and it will use both automatically. During manual review I can also just invoke the PR summary skill and have it show me the things I want to see at a first glance. This is where skills get really powerful. They let you compose specific workflows, easy to customize and adjust.

You can use skills like commands to drive the flow yourself. You can use skills to shape the output towards your preferences. You can also reference skills to reinforce certain capabilities for the model, teach it how to use tools and APIs, or what certain phrases mean like "a beautiful UI design".

Here are a few more examples:

• ayghri/i-have-adhd - shapes text output to be more action oriented, less verbose, and with less distractions
• blader/humanizer - shapes text output to reduce LLM tells and make it feel more human
• cloudflare/skills - teaches agents how to build on Cloudflare
• clerk/skills - teaches agents how to use Clerk

But why bother?#

Can't LLM agents just look up the docs and reference that? Can't they just try things and self-correct if necessary? Yeah, more often than not that works just fine. Even though it's not as much bloat as MCPs, having too many skills installed isn't always beneficial. They work very well for very specific things. Agents will pick up patterns from their environment too. In a well architected codebase, with good quality code, they will thrive. With docs that overspecify everything, many distracting tools (ah, MCP...), in code with shaky foundations, projects with complex setup, questionable quality - you will get matching results.

Overspecification in particular is my pet peeve and a reason why, even though I gave it an honest try, workflow frameworks like GSD or BMAD didn't quite work for me. I like the structure, but not at the cost of time and increased verbosity. Again, KISS! Keep it simple stupid, the system builds itself over time.

I don't want to say the same thing over and over again. I don't want to make trivial decisions. I don't want to be disturbed all the time. Ideally I want to have multiple layers of delegation that go deep, and a single simple interface with a ton of capabilities behind the curtain, that only surfaces things when they are relevant and truly important.

If you want to improve the quality of your LLM agent's results, using proper skills is the way to do it. Making it your way is a big part of making it good, but in case you want to see how I made it my way...

Putting it together#

My wykwit/llm-skills are mostly focused on streamlining my flow, making it reusable by agents in delegated sessions, and dispatching agents for the task in the most effective way.

$ bunx skills add wykwit/llm-skills

When it comes to proper coding principles - I try to encode them per repo for the specific tech stack I use there: typechecks, restrictive lint and formatting rules, integration tests, benchmark tests, dependency audits, and all of that in CI too. It's part of the initial project scaffold, I haven't noted it down in any of the skills.

My harness of choice as of late is OMP. It can auto-correct common anti-patterns in flight. You can use it with any model and any provider. It packs all kinds of tools the agent might need. It even lets subagents communicate with each other.

I have automated cron jobs set up through OpenClaw and Hermes to watch my repositories. They dispatch OMP sessions on a remote VM to target particular pull requests, focusing on particular actions per session. Each session needs a defined deliverable. Otherwise it's just a waste of time and compute. I'm not trying to be wasteful. I'm trying to simplify the information that reaches me at the end. That's all easier when agents know how to collect and bring back solid evidence as deliverables. I still want to make my own informed decisions.

The whole thing moves forward by itself. All that's left for me is to open up a work ticket or issue and I can come back to a pull request that went through multiple rounds of reviews and is ready to merge. I'm not at the point where I let agents merge by themselves yet, so I always have a final word on what code makes it in and what doesn't. I can focus more on product decisions rather than engineering details. Nonetheless, I still try to read into both.

Whether a feature is actually ready to merge and in a state where I like it is always my own call in the end. That's a big difference between my flow and a proper slop factory - I can choose to discard or refine work that I recognize as slop before it becomes a liability. Still, most of the work I don't have to do by hand anymore. What failed for me half a year ago now mostly works out thanks to my better guidance encoded in principles that drive the loop, strong repo-level foundations, and improved model capabilities. I can now wish things into existence if only I describe them well enough. Good example being my latest product calenda.sh, which I first wished for over two years ago, but only now I could see it through to completion.

For all of this to work I rely a lot on my self-hosted VM fleet connected through a tailscale network. I started using CLIs even more to access external services: gh, glab, linear, etc. My agents can use that without clicking through additional setup too.

I have a lot of my own custom tooling:

• bra - workspace and worktree manager with project-aware configuration, so every agent gets its own isolated checkout
• madgit - runs the same command in every git repository under a directory, so I can manage multiple projects more easily
• llm-usage - dashboard for monitoring LLM subscription usage and rate limits
• llm-sessions - workspace-first explorer for LLM coding agent sessions, federated, and now with a web API
• llm-sessions-app - hands-free voice control of my agent fleet through llm-sessions
• achat - one board for all my chats as side-by-side columns in a TUI or web UI, with llm-sessions backend support too

All of this comes together into a really comfy setup that can push the work forward while I sleep and quickly show me what's going on while I'm awake. It's not a full-on slop factory, and I don't exactly ship without human oversight, but I can certainly burn quotas while away from the computer and still deliver more than ever before. Yet, my flow still has a lot of room for improvement. I'm glad I found a good use for all that subsidized inference. The way I approach software development has changed drastically over just a few months.