Dev.to · 10 min read

"I Wired Five Open-Source Tools Into One Command (Part 1): The Report Was All Green, the Game Was Dead"

"I Wired Five Open-Source Tools Into One Command (Part 1): The Report Was All Green, the Game Was Dead"

I used to believe one thing without examining it: if the report is all green, the thing is correct. That night I was staring at my terminal. Four batches of AI agents had just built a multiplayer online game piece by piece, and the report they spat out at the end read: four goals verified, four completed, zero failed. I was genuinely a little moved, because all I had typed was a single command, and out of one sentence of an idea it had grown something that ran. I was about to close the terminal and go to sleep when, for no good reason, I clicked open the browser. The game was dead. What I opened was a pile that didn't connect. The teacher's admin panel wouldn't even load. The page the students were supposed to see on their own was fused with it, so you couldn't tell which was which. (The finer faults — buttons that did nothing, the question the teacher picked never reaching the server — were things a model called Fable teased out one at a time later, in a sandbox. That's the next post.) The all-green report hadn't lied to me by a single word. It also told me almost nothing. This post is about how I walked into that "all green, all broken" late night. The next one is about how a model called Fable made me see what I was actually missing — and it was not a smarter AI. I Had a Cabinet of Tools, Not a Line Let me start with why I built this pipeline at all. Over the past six months I'd been building alone while learning, and only recently had I extracted a few of the flows I kept reaching for into small open-source tools: one that interrogates a vague idea into a spec and then breaks it into a dependency-ordered task graph; one that grinds a single task until it's precise enough to start work; one that scans my work before I commit and blocks the mistakes I keep making; and one that's just a plain-text board, so when I have several AI windows open at once they don't step on each other. Each of them works fine on its own. The problem was they were a cabinet of parts, not a production line. When I actually wanted to go "from one sentence to a running MVP" (a minimum viable product), the carrying in the middle was still done by these two hands. Run the first tool. Read it myself to work out which tasks have no ordering between them and can run at the same time. Open three or four windows myself and feed each one a task file. Watch them run myself. Check the output myself, one by one. The pipeline was always there. I was the carrier. The idea behind specmit was as simple as one sentence: take the part I was carrying by hand and fold it into a single command. The name is the position — spec plus submit. Take the spec you've settled, and submit it for execution. (One thing I muddled myself at first, so let me clear it up: the tool that converges an idea into a spec and breaks it into a task graph is not the same as specmit. The former is the design layer — it draws the graph and stops. specmit is the execution layer — it starts from that graph and runs it into code. They're the two ends of one pipeline, and I wrote the "how to converge an idea into a graph" half up in another series.) I Deliberately Didn't Weld Them Together The easiest mistake to make building this pipeline, and the one I deliberately avoided, was welding the five tools into one big program. I let them talk to each other only through files. The upstream tool spits out a task graph and a few task files; specmit reads those files, starts assigning work, and writes a report when it's done. No tool calls another tool's code directly. They only know what the files they hand each other are supposed to look like. There's something nice about this decision. I can delete any one tool and nothing upstream breaks; each layer can grow on its own without dragging the others along. At the time my head was full of those upsides. What I didn't see was the other side. The place where the coupling came loose was exactly the place nobody ended up owning. The file format where two tools hand off is the most fragile seam in the whole pipeline, and back then I wasn't looking at it at all. That setup comes back to find me, painfully, in the next post. I Handed a Game to a Line I Hadn't Written by Hand For the first guinea pig I picked something hard enough: a multiplayer game that was "Plants-vs-Zombies-style tower defense, plus middle-school math, plus the whole class splitting into teams for a realtime battle." I picked something this complicated on purpose — realtime connections, a game engine, a teacher in control — because simple things can't tell you whether the pipeline is real. The upstream tool broke it into seven tasks and two frozen interface contracts, arranged into four batches: do the room system and the question-bank system first, the two tasks with no dependency between them, at the same time; only then build the connection infrastructure; then run the three tasks that feed off the same connection contract together; finish with the teacher console and the statistics. I typed the command, and then I just watched. The first batch of two agents started at once, finished, and only then released the second batch, like a real production line stacking a realtime multiplayer game cell by cell. The picture was honestly kind of mesmerizing, and I'll admit I felt a little pleased with myself in that moment. "All Green" When it finished, the numbers the report gave me were spotless: four verified, four completed, zero failed. Every task had ticked every line on its own acceptance checklist. Rooms could be built, the question bank could be queried, the student interface could be drawn. All green. I have to be honest: in that moment I was already writing the opening of this very post in my head, something in the self-satisfied register of "how I generated a game with a single command." Looking back, the most ironic sentence in the whole thing is true. I just had its meaning backwards at the time: Every agent did exactly what the spec it was handed told it to do. Across the whole pipeline, not one agent fell down on the job. I thought that sentence meant "so the system is correct." It took me one uncomfortable late night to work out what it actually means: "so the places where the system is broken are none of them on any single agent." Those two things sound alike. They're worlds apart. What Was the Green Actually Greening Before I describe what I saw when I opened the browser, I have to honestly answer a question I skipped that night and only dared to face afterward: what does "all green" even mean, the way this pipeline says it? Its green was defined like this: every acceptance criterion had been claimed by some task, and mechanically checked off. Rooms can be built, the question bank can be queried, the student interface can be drawn — ticked cell by cell. Did you notice that nowhere in this whole definition does anything ask whether the game can actually be played? "The teacher presses start, and a question pops up on the students' screens" — that thing crosses three tasks. It doesn't belong to the teacher console, doesn't belong to the connection layer, and doesn't fully belong to the student interface. It lives in the seam between three tasks. And my acceptance checklist hangs line by line under each task, with no line claiming that seam. Same with "what you should see when you open the home page" — nobody ever asked, from start to finish, so nobody checked it. What was green was that each part passed on its own. It never said the parts would move once you connected them. I was staring at all that green, about to shut the machine down. Before I did, I clicked open the browser. What happened after that, and the one sentence a model left me with, is the next post. The First Thing I Took Away From That Late Night If you're also using AI to stitch together a flow that "turns ideas into things automatically," there's one thing I want you to remember from this post, and I'll save the rest for the next one: A green light does not mean it moves. In any automated report, the only thing that's green is the stuff it was designed to check. The things it didn't check — especially the ones living between module and module, belonging to no single module, the seams — don't turn red. They just quietly don't exist. The most dangerous moment for a beautiful all-green report isn't when it's lying. It's when it honestly answers only the small part you asked about, and you think it answered all of it. In the next post, the model called Fable shows me that these seams aren't a handful of stray bugs but a whole category of thing that nobody was minding across my entire pipeline. It also leaves me with a sentence that changed how I see this: the next thing worth inventing isn't an AI that generates better, it's something that reconciles. → Read on (Part 2): the all-green illusion, and the thing I came to call a reconciler This pipeline, contract over code, and the "reverse organ" that points out my blind spots are really the same obsession: rather than hoping I won't make mistakes, build something that watches for me. Except this time I learned that even the obsession itself has a blind spot. The Open-Source Tools This Pipeline Uses (all MIT, take them) specmit isn't a single tool. It strings together the independent open-source repos below into one pipeline, and each one also works on its own: specmit — the pipeline runner that turns a spec into an MVP: one command, batched parallel agents, frozen contracts. https://github.com/dragon375014/specmit spec-sonar — converges a vague idea into a spec and breaks it into a dependency-ordered task graph, platform-agnostic. https://github.com/dragon375014/spec-sonar goal-workflow-designer — a shaping coach that interrogates a single task until it's precise enough to start. https://github.com/dragon375014/goal-workflow-designer claude-skills-governance-meta — a library of governance patterns that block common mistakes before execution. https://github.com/dragon375014/claude-skills-governance-meta agent-work-board — a single-file coordination board that keeps multiple parallel AI sessions from stepping on each other. https://github.com/dragon375014/agent-work-board Install with npx specmit init, or clone each one and copy the skill into ~/.claude/skills/. The full index is on my open-source tools page. Further reading How the upstream converges one sentence of an idea into a task graph (another series) Contract over code: what I learned reusing work across projects I gave my governance system a "reverse organ" that steps back 本文原載於我的部落格:"I Wired Five Open-Source Tools Into One Command (Part 1): The Report Was All Green, the Game Was Dead"

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

More AI & Machine Learning News