The AI Factory Still Needs Humans

July 2026

Over the weekend, a post crossed my feed describing a “personal software factory.” It’s a system of AI coding agent skills that turns an idea into a working product overnight. How does it work? An “interviewer” agent pulls a product brief out of you. A “planner” agent breaks it into small tasks. A “professor” agent writes the exam before any code is generated. The system then builds the product unattended overnight, with circuit breakers in place to prevent it from digging a deeper hole while you sleep. Finally, a “grader” agent checks the result, and it’s all ready for you in the morning.

Here’s Mike Fishbein’s design, open-sourced on GitHub if you want to build it.

I have a similar system running. But mine started with this second brain idea and grew from there. My “factory” evolved naturally from the marriage of a history in manufacturing and the emerging possibility of actually building things with AI. I’m documenting that build as it happens at ai.ae4jc.com — the first month is up now, mistakes included. In fact, my system produced this article… mostly.

That’s the point I keep coming back to. The “mostly” point. People keep hyping loops, agents, and unattended AI operations — feeding into a bigger story going around right now: that AI is about to take over and make humans obsolete.

I’ve heard a similar story hyped for years in physical factories: the holy grail of “lights-out” manufacturing, processes that run unattended, in the dark. Possible, but kind of rare — for a few different reasons.
Outside of market forces (a whole topic in its own right), the main practical reason lights-out systems are rare is that they are genuinely hard to build, and quality is the first thing to slip when nobody’s checking.

That’s what keeps bringing me back to Fishbein’s closing statement:

NOTE ON BUILDING AI

Cursor and Claude Code have made writing code dramatically easier. But getting AI to work reliably and at scale for you can’t be fully automated.

LLM-as-judge helps, but a judge needs a rubric, examples, and input from someone with subject matter expertise. You still need a human reviewing the work and teaching the system how to perform better.

Every lights-out system still has a customer that demands quality. AI factories are no different. The determination of quality is a judgment call (pass, fail, good enough, not good enough). So, as long as humans remain the customers (the ultimate judges of the product), it remains important to have humans in the manufacturing quality process … Ensuring that quality (from the customer standpoint) is still being delivered.

Recent example: The judge needed a human, and didn’t know it

My system runs its own version of “LLM-as-judge” — a daily pass that reads whatever I’ve bookmarked on X and decides whether it’s worth acting on. Sounds like a great idea, but here’s how it’s going so far:

1. The rubric flagged the same pattern in five different accounts — two posts in one day, both linking to the same underlying post, which never actually got read (every one of those links returned an access error). It fired the same verdict five times anyway: recommend block.
2. I went to act on the list and recognized one of the accounts — not a stranger the rubric had correctly caught, but someone I actually know and value, one of the people whose work started me down this whole path. I didn’t want to block that account!
3. That one recognition forced a real audit. All five verdicts rested on the same unread signal. One got reversed outright — the exact account that would have been quietly cut off, with no reason for me to ever notice it happened. Two more got pulled back and left alone rather than risk the same blind spot deciding them too. Only two of the five actually held up.
4. The rubric got fixed — a stranger’s guess no longer stands in for actually reading the content. But the fix isn’t the point. The near-miss is. I almost blindly trusted AI to lead me down a path of error. Lesson learned.

The judge wasn’t malfunctioning. It applied its rubric exactly as written, every time. The rubric just had no way to tell “one honest post, promoted twice” from spam, and no subject-matter context on any of the five accounts to fall back on. In this case, that context wasn’t technical — it was recognizing one specific person and how they actually post. That’s the kind of expertise Fishbein means: not “knows Python,” but “knows the difference a stranger can’t see.”

Example two: Not a one-off

The same week, building a new webhook receiver for a live server, a second AI agent reviewed the plan cold — one that never touched the first draft — and caught a real error before it shipped: the plan would have retired a data feed that was, in fact, still working. One job: independent review catching an assumption nobody had checked. Separately, a full security audit — prompted by nothing more than reading someone else’s security checklist — found a secret token already being logged in plaintext on a live, running system. Nothing in the build process itself had caught it; it took a human (me) going looking for that exact pattern to find it. A different job: a deliberate check for the thing nobody thought to ask about.

Neither catch was due to the AI being bad at its job. Both catches came from a human with context the system didn’t have — and from building the checks so a fresh reviewer had to work from the artifact alone, not the builder’s own story about it.

Writing the exam first still isn’t enough

Fishbein’s own pipeline writes success criteria before any code — his “professor” skill gives every task an exam up front. My version of the same habit: one-sentence given/when/then criteria, decided before building, not after — “given a wrong password, when the form is submitted, then the user sees an error and is not logged in,” not “handles errors gracefully.”

It’s a real practice, and it’s necessary. It is not sufficient. A written spec is a factory floor’s work instruction — a good one prevents most defects. It doesn’t replace the inspector. My bookmark rubric was written up front, in exactly this spirit — and it still needed a human to catch what it missed once it met the real world.

Where things remain

Cursor and Claude Code really have made writing code dramatically easier — Fishbein’s factory is real proof, and I’d tell anyone building with AI agents to go build one. But lights-out is still rare on the factory floor for a reason, and it’ll be rare here for the same one: the AI factory builds fast, but it doesn’t do a good enough job yet at inspecting its own work (at least my system doesn’t). That part is still ours (for now) — the rubric, the examples, the subject-matter judgment, and the willingness to actually check.

Go back and reread this article’s own production note: “mostly produced with my system.” Not “fully.” That’s not a hedge — it’s the inspection station, stated plainly instead of hidden.

Try this on your next AI-assisted build: before you trust a verdict — a code review, a content flag, a “this is safe to do” — ask what a reviewer would need to know that isn’t visible in the artifact itself. If the answer is “something only I know,” you’re the inspector on the line.

With all the hype right now about AI taking over and making humans obsolete, it’s comforting to know that we’re still necessary, at least for the foreseeable future.