You're not ready for minions: part 1 - ContextBridge Blog<br>(Ironically we’re an AI company, but this post was written entirely by a human named Josh).

Stripe’s Minions posts (see part 1 and part 2) caused quite a stir back in February. Now, a lot of teams are racing to build their own version of Minions.

It is an intoxicating idea; drop a ticket onto an agentic conveyor belt and get a perfect PR out on the other side. It’s the AI software factory we’ve been promised! And, frontier models like GPT 5.5 are now good enough to make this seem feasible. 2026 is now the year of agent orchestration platforms.

“Airflow for agents” products (e.g. Oz) that let you launch armies of clanker-clones via a cron-schedule or @-mention in Github/Slack/“Wherever the team works” are everywhere now. And if DIY is more your style, you can just plug into some webhooks, wire up some durable functions, and start naming every type in your codebase some variation of xxxOrchestrator…what fun!

But there’s a problem. Most teams aren’t set up to make minions actually work, Stripe included:

Comment<br>by<br>u/hronikbrent from discussion

in<br>ExperiencedDevs

Making Minions do real work (the kind that actually moves business metrics) is hard because:

Your tickets are not ready for minions. Your minions need Linear/Jira/Whatever tasks assigned to them. But your backlog is full of tickets with cryptic titles and empty descriptions. You can’t unleash your new minion army on that Grand Queue of Ambiguity without suffering The Monkey’s Paw.

Your infrastructure is not ready for minions. Minions need to run in a container that allows them to verify their work. They need to execute your tests, especially your integration tests that require a Dockerized database. Good luck with DinD though since most cloud agent vendors just hand you a “universal image” and tell you to run shell scripts. Your minions also need to do stuff. But arming them with a nuclear stockpile of CLIs whose tokens grant them the equivalent of full admin access to everything at your company is insanity (unless you’re trying to test the accuracy of your employer’s mttr claims and/or your agent’s prompt adherence capabilities).

Your codebase is not ready for minions. LLMs are statistical pattern matchers. Every line of bad code and every bad architectural decision (whether human or clanker made) is now a prompt injection attack on your minions’ output. No, the AGENTS.md file you haven’t updated in 3 months, a linter and 100’s of snapshot “tests” you let Claude write (mostly unsupervised on auto-mode, while you did the fun part of your job) are not sufficient. That will not save you from buring your team in a mountain of “garbagio” PRs, generated by highly-parallelized minions spewing 2,000 line diffs at 100+ tokens per second. Minions are like junior engineers with ADHD, amnesia and jetpacks. The quality vector of your codebase matters because, unless chaos engineering is your goal, you want all the little yellow guys pointed in the right direction (towards higher, not lower quality).

Your team is not ready for minions. Reviewing 10+ PRs a day at 2k+ lines each isn’t sustainable for humans. Humans can’t stand at the end of the clanker PR-firehose and keep their sanity. AI code review isn’t a panacea. It doesn’t reduce work; it adds more comments humans have to read (the value is that it caches things the humans missed). Some teams have resorted to becoming machine priests who never look at code anymore. That isn’t the answer either. You need to shift the work left.

Your coding agent harness is not ready for minions. It’s a vibe-coded, Ikea jetpack that only runs on a single brand’s jet fuel (Claude, Codex etc). Context is an agent’s most precious resource, especially on long running async tasks. So why would you strap your minion into a harness whose system prompt is full of junk about stuff you don’t use (e.g. Three.js)? You’re paying for those tokens, so your harness should contain only the context and tools you actually want.

Your budget is not ready for minions. Minions incur inference costs at API rates, not the massively subsidized subscription rate you’ve become used to. Most engineering teams aren’t prepared for the sticker shock, or the “what’s the ROI on our AI spend?” discussion with the CFO that follows if you only use the biggest, most expensive frontier model for every minion-task. There’s a Pareto frontier of cost/performance with open-weight models that’s much more budget friendly. But you need to solve your harness problem 1st in order to access it.

Overcoming these hurdles is a lot of work. But async cloud agents are here to stay. And, every newly minted minion-overlord has to start somewhere. So start with fixing your tickets . The rest of this post foucses on that.

The first step to becoming an AI overlord is having a plan

You’re probably aware that the cheapest place to fix AI slop is the plan. You start most local coding sessions in plan mode and iterate...