Sneak Peek
A team of AI agents, run by one person, can build production-level apps. Real software. Designed, built, code-reviewed, tested, security-audited, and shipped. The exact process your company’s engineering team goes through to ship software.
In this write-up I’m going to cover a system that can build production level native Mac and iOS apps. (I’ve got a fullstack web one going too. Not as far along yet, but the same approach.)
I know how that sounds. So let me be straight about who’s making the claim.
I’m an engineer. Two decades in product, technology, and engineering. But I don’t write Swift. The last native app I built by hand was 13 years ago. A barbell plate calculator. I powerlift, and the on-the-fly math gets old. My program says squat 475, and you’re standing at the bar working out how many 45s, 25s, 10s, and 5s to load on. So I bought a Udemy course, learned just enough Swift, and built it. One input box for the target weight. One button. It told me the plates. That was the ceiling of what I could build on Apple’s platforms.
All of the engineering I’d done before that was backend. APIs, databases, scripts. No frontend, no fullstack.
Today I direct a team of agents that can ship real apps to the App Store.
I’m not going to ask you to take that on faith. The toolkit is real. The apps are real. Below, you can watch the team build.
This is not “vibe coded slop.” Vibe coding is prompting a model and shipping whatever it hands back, no review, no tests, fingers crossed. This is the opposite of that, start to finish.
This team wasn’t built in a weekend. It started when Opus 4.5 landed and the models got good enough to carry the work instead of just helping with it. Then it was months of building agents, writing their rules, watching them break, and tracing why. One step forward, three steps back. Two forward, one back. Every time something broke, I didn’t go fix the code myself, I fixed it in the system. You can see that same kind of process up close in the retrospective for a writing system I built.
This isn’t Replit, Lovable, Bolt, Base44, or v0. Those are great at what they’re for: a web prototype, an MVP, an internal dashboard, spun up fast, often by someone who’s never written a line of code. But they top out at the web, they stop at the generated code, and the AI that wrote it is the same one that checks it. No independent review. No real QA. No separate security audit. Great for proving an idea. Not for shipping production software.
A team in a folder
To engage the team you open the terminal, launch Claude Code and discuss what you want to build. You aren’t talking to just the Claude model. You’re talking to a full development team.
A product manager that pins down the problem before anyone writes code. A discovery agent that runs you through a real Q&A: who it’s for, what it has to do, what it looks like, what it connects to. A designer. Developers for macOS and iOS. A staff engineer who reviews every change. A QA agent that writes and runs the tests. Three separate security reviewers and a lead who rules on what they find. A build engineer that handles the commits and the release.
Each one is an agent. An AI with a single job, a clear role, and the skills to do it. The same way you’d staff a real team.
And you run it. You don’t write the code. You direct, in plain language, the way a good manager directs people who are better at the hands-on work than they are. You build the Epics, Stories, Tasks just as you would in Jira (except, the AI Product Manager handles most of it for you). The system carries the structure. It walks you from a rough idea, through discovery, design, build, review, and testing, to something ready to ship. You make the calls. It does the work.
And be clear about what this is for. If you just want to throw together an MVP, this isn’t it. Use one of the tools I mentioned above. This is built to operate like a real agile product delivery team. The same stages, the same reviews, the same gates serious software goes through before it ships. It doesn’t skip the process. It is the process, run by agents.
Watch the team work
Most AI demos stop at the code. This one you can watch, start to finish.
This is agile-maestro, a board I built that reads the same task files the agents write to. Think Jira, except the team filling it in is the agents, and you’re watching them in real time.
Work starts as a backlog. The product manager and discovery agents break a feature into epics, then stories, then tasks. Each one gets its acceptance criteria written before anyone touches code.
Then it moves across the board. A developer agent picks up a story and builds it. The staff engineer reviews the code. QA writes and runs the tests. The security reviewers make their pass. Nothing advances until the stage before it clears.
Near the end, it stops. On purpose. Before anything ships it lands in human UAT, and that’s me. I test it. I make the call. If something doesn’t work as expected, I file a bug with the system. The agents do the work, but the judgment stays human.
You’re not looking at a black box that spits out code. You’re looking at a team, and a process, with every handoff on the board. You’d be hard pressed to find a real agile delivery team that doesn’t operate in a similar manner.
Why it ships real software
Production-grade means the work cleared every gate a real engineering team runs before it ships. Design review. Real tests. A security audit. A human sign-off. Skip them and you’ve shipped a demo, not a product. That’s the line this toolkit is built around.
The catch is that an agent will tell you the work is done long before it is. Same as a young kid in grade school left to grade their own homework... passing grade every time.
So this toolkit doesn’t take an agent’s word for it. The checks are independent. Most of them aren’t even AI. They’re plain scripts that look for proof, and an agent can’t talk its way past a script.
Three of them, and every one exists because something broke on a real build.
The agent that graded its own homework. An agent would finish a story and mark it done. Tests written, screenshots taken, criteria met. Except it was the same agent deciding whether its own evidence was good enough. Sometimes the test it cited didn’t exist. The screenshot it pointed to was never saved.
So I built a gate. Before a story can leave QA or close out, a script runs (ac-evidence-check.sh). It doesn’t judge quality. It checks that the proof is physically there: the test it named exists in the code, the screenshot file is on disk, the comment it referenced is real. If anything doesn’t resolve, the story is blocked. Not by an opinion. By an exit code.
It’s a dumb check, on purpose. The system doesn’t ask an AI whether the work passed. It checks whether the receipts exist. No receipts, no passing.
The UI that was “done.” Agents kept finishing screens and marking them complete when nobody could prove the screen actually worked. “Done” meant “I’m pretty sure.”
Now every UI task ends with a picture. The agent launches the app through a tool called Peekaboo, captures the running screen, and looks at it before it’s allowed to mark the work complete. “Done” means “here’s the screenshot.”
One security reviewer who caught nothing. I started with a single security agent. Too broad. Asked to watch for everything, it flagged nothing useful. So I split it into three, each with one narrow job. One scans for known-bad patterns, like secrets in the wrong place or weak encryption. One reasons across files for logic flaws. One checks Apple-platform specifics like app sandboxing and entitlements. A fourth, the lead, reads all three reports and makes the call.
One generalist guard misses things. Three specialists and a supervisor don’t.
That’s the pattern, over and over. Every time the team cut a corner, the fix was never to make the AI try harder. It was to build a check it couldn’t dodge. That’s the difference between code that looks done and software you’d actually ship.
What I built with it
None of this is theoretical. Here’s what the toolkit has actually built.
Start with the board you were just looking at. agile-maestro, the app showing the agent team at work, was built by that same team. Start to finish. The board watching the agents was built by the agents. It’s a real, native Mac app, with 298 passing tests behind it.
Then there’s parsely. I’ve been teaching myself to fine-tune models, which means living in JSONL files. Every editor I opened showed them as a wall of single-line text running off the right edge of the screen. Unusable. So I had the toolkit build me a viewer that parses each line into a clean, collapsible tree. One session, start to finish.
And there’s one more, a few weeks out from the App Store. An organization app, with a couple of features I haven’t found in anything else I’ve tested. That’s all I’ll say for now.
Every one of these started as my own itch. 13 years ago, scratching one meant a Udemy course and a lot of fumbling to ship a single button. Now it’s a session, or an afternoon, with a team doing the building.
I’ve run teams. I’ve shipped apps used around the world. But I never built those myself. That took specialists, and years of training I don’t have (and skills I didn’t feel the direct need to build). AI is the first time the building has been in my own hands.
So I did with it what I’d do with any product. Find the real problem, then build the thing that solves it. Every agent, every skill, every rule started as a problem I hit on a real build. That’s the whole job. This time, the product I built was the team.
Coding is becoming a commodity. Being a great engineer who writes beautiful code, that skill matters a little less every year, and that won’t reverse. The skill that holds its value, the one that’s actively needed, is knowing which problem to solve and building something that solves it. Call it product work. It’s the part AI doesn’t replace, and it’s the part worth getting good at.