Why Overkill Skills Lead to AI Workslop Instead of Deep Work — dupflo.dev<br>I am always looking to optimize my process. And to be honest, that behaviour is exactly what leads me to produce AI workslop today.
The word is not mine. Researchers at BetterUp Labs and Stanford’s Social Media Lab coined it in Harvard Business Review in September 2025, for AI-generated work that looks polished but carries nothing that moves the task forward. Their survey found 40% of US desk workers had been handed some, and that each instance cost about two hours to repair.
I test a lot of plugins and skills. RPI workflows, gstack, Garry Tan’s Claude Code setup, twenty-three skills that play CEO, designer, eng manager, QA lead and release engineer. I even built my own decision-ledger skill. There are cases where none of it is productive, and cases where it actively adds complexity.
Rewind a couple of years, before AI showed up. I was one of those developers working for big companies. And one of those developers who never understood why we needed ten people in a meeting to decide the color of a UI button.
Today I catch myself acting like those people. For two reasons:
I know AI needs a workflow, otherwise you get slop and out-of-context decisions.
I think my process has to be perfect from the first line of my spec, or the project will look AI-generated and the code will be garbage.
Both of those are true, up to a point. I have experienced them.
The pain of launching a SaaS with AI when you are a developer
I launched Getzatjob, my first AI SaaS, to solve a specific need: identify my strengths and weaknesses for a job application and find the resume positioning that passes ATS screening. Looking back, the project was my sandbox. It rapidly became a pile of AI-coded features I never wanted to read, and at first I kept telling myself “never mind”. That was real vibe coding, and honestly, it is painful. And the UI, arggg, not that good.
I developed it by firing off a pile of prompts without ever verifying anything, with “it works fine” as the only argument I had, until the first wave of bugs made me realise the product was a mess, and that it needed refactoring from the very first line of code.
So when I decided to build Getzatjob V2, now called Applyzi, I started using gstack and I gave it a lot more information about the way I code. My motto was: I want a product whose code I understand, coded the way I would code it, and good-looking enough that a recruiter at an AI company would look at it and think: this guy ships a product with the quality we would want from our own team.<br>That way, I was happy to work on it.
The other big difference was the pace of delivery. With Getzatjob, I had 80% of the project standing in less than 24 hours. That is the promise you see on social media. Great. After that it took me weeks of stacking features and duplicating garbage code on top of lazy prompting.
With Applyzi, it took three to four weeks of planning and controlling every feature, spending more credits to make React components reusable. Exactly like I used to do before. It cost me more time up front, but three months in, the project is maintainable and scalable, and I am not scared of recoding parts of it myself.
When workslop enters the scene
I had a feature to develop on a client project I have been working on since 2021, long before the AI hype. Add some data to an existing screen, and add one more screen. Five, maybe six files impacted. My usual workflow when it is just UI integration: I take a Figma screenshot, no Figma premium here so no MCP, and I give it to Claude.
Then I go to my git history in VS Code, look at the modified files, read them, add manual corrections, and I am done. Thirty minutes: ten of AI, twenty of polishing. Instead of an hour if I had done it by hand.
As an experiment, I ran the RPI method instead. Research → Plan → Implement, with a validation gate at each phase. RPI is not one prompt: it dispatches twenty-three agent skills across its phases. On paper it is a good workflow. In practice, on my six files, it was pure overkill. It spent minutes identifying “pain points” in the project, read the entire codebase, contradicted its own findings along the way, and finished by handing me this:
File<br>Lines<br>Content
pm.md<br>730<br>12 user stories, 19 acceptance criteria, 8 arbitrated PO questions
ux.md<br>813<br>3 flows, 14 states, 40 i18n keys
eng.md<br>1385<br>API contract, types, real code, 12 risks
PLAN.md<br>490<br>5 phases, 44 tasks
Three thousand four hundred and eighteen lines of planning. Its own verdict: medium complexity, 13 new files, 9 modified, seven to ten person-days.
I shipped it in thirty minutes, touching six files.
Look at what the research phase actually runs: a requirement parser, a product manager, a UX designer, a technical CTO advisor, a senior software engineer, a documentation writer. Six roles. To add data to one screen.
I took a step back and said to myself: this is the ten-people-meeting for a...