The "Shit Prompt" Method — build AI factories in under 5 minutes

A note on authorship: I'm not going to hide the em dashes. Yes, I used AI to help with this post, and no, I'm not going to pretend otherwise. I like the result. And I like em dashes!

Software Factory. AI Agent Harness. Automated Workflow Engine.

These phrases sound expensive. They sound like the kind of pitch deck fluff that comes attached to a £2,000-a-day Forward Deployed Engineer. But here is the open secret of the current AI landscape: building a factory isn't rocket science. The capability to build the thing that builds the thing is already baked into almost every major LLM on the market.

You don't need a 50-page spec document to start. In fact, writing one is usually a waste of time.

My entire methodology for building complex AI factories comes down to a dead-simple loop: write a terrible prompt, tell the model to fix it, tell it to build, then tell it to draw the loading screen. Four prompts. No spec document. No architecture workshop.

The ZX Spectrum Game Factory open-source repo — Cursor rules, agent prompts, engine scaffold, MIT license, and obligatory 80s pixel art banner — was generated from exactly these four prompts. Nothing else.

Step 1: The Shit Brief

When I wanted to build a ZX Spectrum Game Factory—a harness where a team of sub-agents (code engineer, pixel artist, audio specialist, QA tester) assemble modular Z80 code into playable retro games—I didn't start with a clean architecture diagram.

I wrote a half-baked stream of consciousness. It was messy, misspelled, and missing technical specifics. And that is precisely the point.

Prompt 1:

build me a factory AI harness for building spectrum games using common building blocks... ensure it has skills for artwork... create a team of specialist agent profiles, tester, artist, copywriter...

Step 2: The Magic Phrase—Improve This

Once your rough idea is out of your head and in the chat window, you append two words to the bottom.

Prompt 2:

Improve this.

Why does this work so remarkably well?

When you tell an AI to improve a raw brief, it immediately reveals what it already knows out of the box vs. what you actually need to specify.

Instead of guessing what context the model lacks, you let the model show you its baseline knowledge. Usually, you'll realise 80% of the architecture is stuff the model can already do effortlessly (like structuring JSON schemas, defining agent roles, or writing build scripts). Your job isn't to teach it how to code or format; your job is simply to spot the remaining 20% of missing business logic or domain constraints.

What came back — the actual factory spec

To make this concrete: here is the actual prompt Gemini generated when I ran this loop on the ZX Spectrum Game Factory idea. I gave it the shit brief from Step 1, appended Improve this, and this is what came back — unedited apart from fixing the formatting for the blog. The full text also lives in the repo as FACTORY.md.

Directory layout from the improved prompt:

zx-spectrum-factory/
├── .cursor/rules/
├── engine/
├── tools/
├── emulator/
├── agents/
├── workspace/
└── README.md

Look at what the model filled in that I never mentioned:

1. Technical precision — Screen RAM at $4000, attribute clash, .tap formats. I didn't know to ask for any of that; the model did, because it already knows Spectrum constraints.

2. Cursor-native structure — .cursor/rules/ for sub-agent personas. I said team of specialist agent profiles; it mapped that to how Cursor actually works.

3. Clear boundary separation — Tilemap, sprite driver, sound engine as explicit Lego blocks so agents stitch pre-tested components instead of rewriting from zero every time.

That is the 80/20 split in action. My shit brief had the intent (factory, agents, building blocks, Spectrum games). The improvement pass supplied the architecture (directory layout, acceptance criteria, workflow phases, hardware constraints). What was still missing — and what only I could add — was whether I actually wanted z88dk vs Boriel's Basic, which emulator to standardise on, and how opinionated the factory should be about memory maps for 48K vs 128K machines.

Step 3: Ship It — One Prompt to Build the Repo

The improved spec is not the deliverable. The repo is. Once Prompt 2 returns something you are happy to run with, paste the whole thing into a fresh Cursor Agent session and ask it to materialise the project.

Prompt 3:

Create all the artifacts I need to share this factory spec as a free open-source project — MIT license, Cursor rules for each agent, agent prompts, directory scaffold, README, and CONTRIBUTING. Place it in a new repo ready to publish on GitHub.

That is the entire instruction I gave Cursor. It read the improved spec from Prompt 2 and produced the zxspectrum-game-factory repo: .cursor/rules/ for producer, code engineer, pixel artist, audio, copywriter, and QA; matching prompts in agents/; stub engine blocks in engine/; tools/build.sh; FACTORY.md with the Prompt 2 output; the lot.

Step 4: The Obligatory Loading Screen

Every retro project needs pixel art. This is non-negotiable. If you are building a ZX Spectrum factory and you do not have a garish 80s/90s loading screen, you have not finished.

Prompt 4:

Generate obligatory 80s/90s style pixel artwork for this repo — ZX Spectrum loading-screen aesthetic, bold attribute-clash colours, chunky 8×8 blocks, factory robots on an assembly line building a .tap cassette game. Save it as the repo banner and social preview image.

Cursor generated the banner, dropped it in docs/zx-spectrum-factory-banner.png, and wired it into the README. Because of course it did.

Four prompts in, open-source factory out — with the loading screen your inner 1984 bedroom coder demanded.

The 5-Minute Factory Blueprint

You can use this exact four-prompt loop for almost any business process — whether it is a retro game engine, a client onboarding system, or an automated marketing pipeline.

Here is how to do it in under five minutes:

1. Dump the Raw Concept (Prompt 1): Spend 60 seconds typing out how you think the process might work. Don't worry about formatting, grammar, or missing details.

2. Run the Improvement Pass (Prompt 2): Append Improve this. and let the model structure, expand, and turn your brief into a production-ready system prompt or architecture specification.

3. Ship the Repo (Prompt 3): Paste the improved spec into a fresh Agent session and ask it to create the open-source project scaffold — rules, prompts, directories, README, license.

4. Draw the Loading Screen (Prompt 4): Demand obligatory era-appropriate pixel art for the repo banner. Retro projects without loading-screen art are legally suspicious.

5. Audit the Gaps: Step back and review what the model generated. Ask yourself: Where are the gaps? What domain-specific rules did it miss?

6. Refine or Automate:

(Not actual legal advice on the loading-screen art. But come on.)

Stop Overthinking the Architecture

Building AI infrastructure isn't about writing pristine code from scratch; it's about guiding an engine that already knows how to build.

The next time you have an idea for a complex, multi-agent pipeline, don't spend three weeks planning it. Spend three minutes on Prompt 1, two words for Prompt 2, one sentence for Prompt 3, one more for the loading screen — and watch your factory scaffold appear.

Four prompts. One repo. One banner. Five minutes.

• Prompt 1: the shit brief

• Prompt 2: Improve this.

• Prompt 3: Create all the artifacts I need to share this as a free open-source project…

• Prompt 4: Generate obligatory 80s/90s style pixel artwork for this repo…

The ZX Spectrum Game Factory is what those four prompts produced — a scaffold, not a shipped game.

Disclaimer — read this before you fork it

I have not built a game with this factory. Not one line of playable Z80 shipped to a .tap file. That was never the point of this exercise, and I am not pretending otherwise.

This blog post is about the first step in the journey: how fast you can go from a half-baked idea to a structured factory spec and an open-source repo skeleton. That is it. Prompts 1–4 get you off the blank page. What happens next is on you.

When you actually start using the factory — describe a game, run the agents, wire the toolchain, hit the emulator — you do the full gap analysis. There will be gaps. There always are. The model fills in the generic 80% (directory layouts, agent roles, memory map boilerplate, acceptance criteria). The remaining 20% — which z88dk vs Boriel's Basic, which emulator, how opinionated your memory budget, what your game actually needs — is what you bring to the table. That is the human part. That is the bit worth doing.

So: fork it, break it, fill the gaps, build the haunted coal mine platformer if you want. The repo is a starting pistol, not a finish line. If you ship something playable, I would genuinely love to hear about it. But I am not claiming I already did.