A 44-minute tour of an open-source agent pipeline that turns a Linear ticket into a merged pull request, and the human checkpoints it still keeps.
Posted
1 weeks ago
Duration
Format
Tutorial
educational
Views
24.7K
374 likes
57 · 43
Big Idea
The argument in one line.
A software factory works when agents follow a fixed playbook with real verification and a confidence gate, so the human stops pressing continue and only steps in for unclear tickets and unverified work.
Who This Is For
Read if. Skip if.
READ IF YOU ARE…
A developer already using Claude Code or Codex daily who is tired of prompting every step from investigate to merge by hand.
Someone who wants to run several coding agents in parallel without them stepping on each other's files.
A builder deciding between local worktrees and cloud sandboxes for background agent jobs.
A small team that wants tickets in Linear or Slack to kick off agent work and report status back in one place.
Anyone curious how an agent can safely auto-merge its own pull requests and when it should not.
SKIP IF…
You want a no-code tool. This is a self-assembled stack of T3 Code, PStack, Neon, Modal, Linear and Vercel that you clone and wire up yourself.
You are looking for a line-by-line code walkthrough. The video shows the panel and architecture diagrams, not the source.
You only write occasional scripts. The setup overhead pays off when you are shipping many tickets a week.
TL;DR
The full version, fast.
A software factory is an automated development environment where coding agents use standard tools, workflows and project knowledge to build, test and maintain software, but it only works with a human acting as head chef over a kitchen of agent cooks. The author's open-source Marshal Factory takes a labeled Linear ticket, runs it through a fixed playbook (triage, investigate, implement, verify, open PR) using Claude Code or Codex inside T3 Code with PStack's playbooks, in either a local worktree or a Modal cloud sandbox. Neon stores every event and pushes realtime updates to a Vercel panel. The agent merges itself only when it is confident, CI is green and Bugbot is clean; otherwise it asks a question or hands the PR back.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Shows the factory board and promises to explain what software factories are and build one live from prompt to finished result.
01:08 – 02:44
02 · What is a software factory?
Defines the term and pushes back on the idea that a factory runs forever untouched; it needs a human layer like a house needs a foundation.
02:44 – 04:39
03 · The kitchen analogy
Borrows Lauren Tan's chef-and-cooks model: the human orchestrates, delegates and does quality control, landing between micromanaging and doing nothing.
04:39 – 07:00
04 · The factory playbook
Contrasts the old manual prompt-every-step loop with ticket-in, agents-do-the-rest, and explains the two merge outcomes gated on confidence, CI and Bugbot.
07:00 – 08:00
05 · Verification makes auto-merge possible
Auto-merge only works because agents get a project-specific verification skill from PStack that drives the real app, browser and CLI.
08:00 – 10:55
06 · Sponsor: TestSprite
Paid read for an AI testing agent that builds test plans, runs browser tests in parallel and returns structured failures to the coding agent.
10:55 – 17:00
07 · Tour of Marshal Factory and onboarding a repo
Walks the Vercel-hosted panel (inbox, jobs, machines, repositories, settings), then onboards a repo: a Modal sandbox analyzes it and opens a setup-recipe PR.
17:00 – 25:00
08 · Running three tickets in parallel
Creates three labeled Linear tickets; two move through triage to verified PRs while the vague one stops and asks a multiple-choice question, then resumes after the answer.
25:00 – 28:00
09 · Why agents need a recipe, and a failed verify
Argues factories without a fixed recipe are slot machines, then shows the factory refusing to auto-merge because the sandbox lacked browser libraries for screenshots.
28:00 – 29:00
10 · The stack: harnesses
Introduces the stack diagram, starting with the harness layer: Claude Code, Codex, Cursor and Antigravity, chosen per ticket by label or default.
29:00 – 30:15
11 · T3 Code as the orchestrator
T3 Code runs harness sessions in separate threads with their own repo copies and is driven via CLI, so the factory never talks to an agent directly.
30:15 – 32:00
12 · PStack, the coding agent framework
PStack routes a request to a feature or bug playbook with ordered skills and helper agents and an implement-verify loop; the factory adds its own playbooks for questions, reporting and confidence.
32:00 – 33:20
13 · Runner, reporter and panel
The runner is the foreman that claims and supervises jobs, the reporter streams every stage and token, and the panel shows it all.
33:20 – 35:08
14 · Where jobs run and where work comes from
Local jobs get a T3 thread and worktree; cloud jobs get one Modal sandbox each. Sources today are Linear and Slack, with GitHub Issues next.
35:08 – 43:30
15 · How it all connects, step by step
Seven-step flow: ticket webhook into a Neon ingest function, events table and realtime, runner claims the job, Modal worker image and hibernation, reporter writes back, Vercel panel updates, PR merges or hands over.
43:30 – 44:08
16 · Outro
Asks for likes and GitHub stars, thanks the sponsor and notes the project is a work in progress open to contributions.
Atomic Insights
Lines worth screenshotting.
A software factory is not something you build once and walk away from; it still needs a human supervision layer on top.
Think of yourself as a head chef with ten cooks: you orchestrate, delegate and taste for quality, but you never boil the noodles yourself.
The goal sits between micromanaging every step and letting agents run blind; nothing ships without the chef, but the chef does not do each step.
Prompting an agent to investigate, then write, then test, then open a PR, then merge is micromanagement dressed up as AI-assisted coding.
A ticket is just a prompt with success criteria, so Linear, GitHub Issues, Slack or any text source can feed the factory.
Auto-merge is only safe when the agent reports high confidence, CI is green and an automated reviewer like Bugbot has no open comments.
Agents can only auto-merge because they were given a way to verify their own work: drive the real app, use the browser, run the CLI.
A vague ticket like make the recipe book nicer should stop the pipeline at triage and come back to you as a multiple-choice question.
When the sandbox lacked browser libraries, the agent could not screenshot its change, so it refused to auto-merge and handed the PR back.
Most factories online are vibe-coding slot machines: input in, output out, with no fixed recipe the agent must follow.
Local agent jobs need a git worktree each so parallel work does not collide; cloud sandboxes skip that because each job gets its own machine.
Hibernating a sandbox that is only waiting on a human answer, and shutting it down after five minutes, keeps idle agents from burning money.
A pre-built warm image per repository, with the code cloned and dependencies installed, makes each new sandbox job start fast.
The runner that claims tickets and starts jobs should never write code itself; it is a foreman that watches, merges and cleans up.
Logging every stage, sub-agent and token to one events table is what makes a live cost and status dashboard possible.
The author reports spending around $3,000 in tokens building the factory, and one small ticket cost about 35 cents to run.
Takeaway
Agents ship alone only when they can verify
WHAT TO LEARN
A factory that hands tickets to agents works because of a fixed playbook, real verification and a confidence gate, with a human who only steps in when the agent asks or cannot prove its work.
02What is a software factory?
Treat a software factory as a supervised system, not a fire-and-forget machine; remove the human layer and the whole structure falls apart.
03The kitchen analogy
Act as head chef over agent cooks: set direction, delegate the steps and judge the result instead of watching every line being written.
Aim between the extremes of micromanaging each prompt and letting agents run blind; nothing should merge without passing your standards.
04The factory playbook
Write tickets as prompts with clear success criteria, because the ticket is the only instruction the pipeline gets before agents start.
Allow auto-merge only when the agent reports confidence, CI is green and automated review has no open comments; otherwise route to a human.
05Verification makes auto-merge possible
Give agents a project-specific way to check their work against the running app, browser and CLI, since unverifiable work cannot be trusted to merge.
07Tour of Marshal Factory and onboarding a repo
Onboard each repository once so the factory records how to install and run checks, then build a warm image so every job starts ready.
Choose cloud sandboxes over local worktrees when you want unlimited parallel jobs that cannot collide or slow down your own machine.
08Running three tickets in parallel
Let vague tickets stop at triage and come back as a concrete multiple-choice question, then resume the same job once you answer.
Keep an observability view of every stage, cost and live event so you can open a running session and steer it when something drifts.
09Why agents need a recipe, and a failed verify
Force every job through the same ordered recipe, because an agent with no playbook improvises and produces slot-machine results.
Treat a refused auto-merge as the system working: missing browser tools meant no screenshot evidence, so the PR correctly came back for review.
10The stack: harnesses
Pick the agent harness per ticket with a label, and fall back to a sensible default model when no label is set.
11T3 Code as the orchestrator
Route all agent control through one orchestrator with a CLI so the factory can start, message and stop sessions without clicks.
12PStack, the coding agent framework
Use a framework that maps each request to a feature or bug playbook with an implement-verify loop and evidence at the end.
Extend the base playbooks with your own rules for when to ask instead of guess, how to report each stage and how to judge confidence.
13Runner, reporter and panel
Keep the supervising runner separate from the agents; it claims, watches, merges and cleans up but never writes code.
Stream every stage, sub-agent and token count to a single events log, which is what makes live cost and status tracking possible.
14Where jobs run and where work comes from
Locally, give each parallel job its own worktree; in the cloud, give each job its own sandbox and skip worktrees entirely.
Accept work from any text source that can send an event, such as Linear or Slack, rather than tying the factory to one tool.
15How it all connects, step by step
Use webhooks into one ingest function and a database with realtime push so the dashboard updates the moment a ticket or PR changes.
Hibernate sandboxes that are only waiting on a human answer and shut them down after a few idle minutes to stop paying for nothing.
Close the loop on merge: a GitHub webhook updates the events table, which moves the ticket to merged on the panel automatically.
Glossary
Terms worth knowing.
Software factory
An automated development setup where AI coding agents take a request and carry it through investigation, coding, testing and a pull request using standard tools and project knowledge, with a human supervising.
Harness
The agent program that actually reads code, edits files and runs commands, such as Claude Code, Codex, Cursor or Antigravity.
T3 Code
A multi-agent coding environment that runs many agent sessions side by side in separate threads and can be controlled from the outside through a command-line interface.
PStack
A plugin framework for coding agents that routes a request to a playbook of ordered steps, skills and helper agents, including a project-specific verification step.
Git worktree
A separate working folder checked out from the same repository, letting several branches be edited at once on one machine without file conflicts.
Cloud sandbox
A short-lived, isolated remote machine created for one job, so parallel tasks never share files or compete for local CPU and memory.
Webhook
An automatic HTTP message one service sends to another when something happens, such as a ticket being created or a pull request being merged.
Triage
The first pipeline stage where the agent reads the ticket and decides whether it is clear enough to start or needs a question answered first.
Setup recipe
A small config file the factory writes per repository describing how to install dependencies and run checks, merged in through a pull request during onboarding.
Bugbot
Cursor's automated pull-request reviewer that leaves comments on likely bugs; the factory waits for it to pass before auto-merging.
CI
Continuous integration: automated tests, lint, type checks and builds that run on every pull request to confirm the code still works.
Hibernation
Freezing a sandbox that is only waiting on a human reply, then shutting it down after a few idle minutes and waking it when the answer arrives.
“It never writes any code itself. It's essentially just like a manager.”
surprising design rule for the orchestrator→ newsletter pull-quote↗ Tweet quote
The Script
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
17px
metaphoranalogy
This here is my software factory. I give it something to build and it turns that request into working software. Everything starts with a single prompt, in this case a linear ticket.
From there, the agents investigate the problem, implement the change, run the checks, and fix what fails. If something needs my decision, the factory asks me and continues once I answer. The work can happen locally on my machine or inside isolated cloud sandboxes.
The factory stores its progress, checks what's happening, and brings everything back into this panel. I can step in when needed and review all of the results, nevertheless most of the work gets handled autonomously by the factory itself.
Which means I finally get to retire from being the continue button. And that's why in this video I will show you what software factories actually are and how I built my own by bringing together Cloud Code, T3 Code and Cloud Sandboxes. And of course we will give the factory a real task and follow the entire process from the initial prompt to the finished result.
So with that out of the way, Let's get into it. Now, as a first step, let's answer the question, what even is a software factory?
What does it do? And why should you probably create your own one or use the one I already created for you? So at a high level, a software factory is an automated development environment where AI agents, coding agents, use standardized tools, workflows, and project knowledge to build, test, and maintain software.
And here's the thing, most people usually get this wrong. think that a software factory is something that they build once, it runs forever, and you never touch it again. And this is just not true.
It does not work like that. It's not a hands -off machine that works autonomously. You still need human supervision.
You need a human layer that stays in control. Let me give you an example. A house.
What does a house have? It has a roof, it has walls, and it has some sort of foundation. A concrete foundation.
What happens if you remove all of the falls apart. And that's the same thing we have with software factories.
But now you might say, Jen, I'm still kind of confused. So a software factory is an automated development environment, but we still need a human supervision layer. How does that exactly work?
Like what does the software factory do and what should I do? Great question. So recently I watched an interview between Lauren Tan and Matt.
And if you didn't know, Lauren Tan is a software engineer working at SpaceX AI. and she also created P -Stack. It's also a very essential, you could say, piece of my whole factory, but that's something we will dive into a bit later on.
And she used a very interesting analogy. Instead of talking about software factories, she likes to think about kitchens. So how does a kitchen work?
Well, you have a chef, I guess in theory, also a sous chef and patisserie chef, and then also cooks. But let's keep it simple. Let's take a 1 to 10 ratio, one chef and 10 cooks.
the chef do? Or in other words, what doesn't the chef do? Well, does the chef cook noodles in a pot himself?
No, not really. Does the chef taste every single component in a dish? No, of course not.
The chef is there to orchestrate, delegate, do quality control, QC, and at the same time also steer all of the cooks. Add more salt, add more pepper, add a bit of wine, maybe add a bit more, what did I eat today, a bit of cheese, for example. That's the role of the chef.
A chef shouldn't do every little... step. And that's the same thing we have right here with software factories.
You are the chef and the agents are your cooks. You are the central factor. You are there to do quality control, to steer your agents and also to decide, hey, is this good or is this trash?
But now you might say, okay, Jan, this already makes a bit more sense. I'm the chef. I'm the one who's in control.
Nevertheless, my agents, my cooks have the freedom to also do everything by themselves. I'm just the deciding factor, essentially. But what extreme should I pick?
Should I micromanage or should I do nothing? Well, you don't want to micromanage. You don't want to watch every little step or check every little line of code.
But at the same time, you don't want to do nothing. You don't want to let your factory run in the blind. The goal is to kind of be in between, just like a really good restaurant.
You as the chef should be there. You have to be present and nothing should go out without you. But you shouldn't be the deciding factor for every little step.
For that you have cooks on other words coding agents. And that's also what you will see here. Before using software factories, I had a very, could you say, manual workflow, meaning I would start by first of all opening my agent, cursor, cloud code, T3 code, codex, whatever, and then I would start talking to it.
So for example, hey, investigate this issue. Now write the code. Oh, now test everything.
Let's open the PR. The PR is opened. Great, let's merge it.
How is this called right here? Well, let's again go back to our kitchen analogy. micromanaging.
Essentially in the past what I did is that I micromanaged every little step. Writing the code? Let me micromanage it.
Testing the code? Let me micromanage it. Opening the PR?
Let me micromanage it. Is that what we want to do? No.
So with the factory everything is way more autonomous. The first step is to write the ticket. So in my case I use something called linear.
I will come to that in a second. In linear I create a ticket which essentially is just a prompt. So hey this is my issue.
This is the success criteria. This is what you should do. You don't have to necessarily use Linear for that.
You just need some sort of source. Linear, GitHub Issues, Slack, I don't know, Grogbot, everything works. And then we already have our autonomous pipeline, our factory.
So the factory starts investigating everything, writing the code, testing the code, and finally opening the PR. And this is where things now get interesting because the last step, the merging step, kind of depends on your factory and how autonomous you want it to be.
So in my case I have two outcomes. Either the factory merges everything itself or it hands over the work to me and I review the PR, review the code, review I guess whatever got generated and then either merge it myself or tell the agent hey you know what you made a mistake let's fix this or the code is incorrect, the architecture is incorrect, whatever makes the most sense.
So essentially you could say I have like a confidence criteria if the agent is very confident and if CI is green and if I don't have any cursor bug bot comments, then I let the factory merge everything by itself. But if the agent is not confident or if it's unsure, then it hands over to me.
I review everything and then do whatever is needed because I'm the chef. Now, what I want you to realize here is that the only reason why my factory is able to merge PRs automatically without needing any input from me, at least in certain scenarios, is because I set a very big focus on making it as easy as possible for my agents to review their work and with that also test it very thoroughly.
And I'm not sure if I already mentioned it, but I'm a very big fan and also user of P -Stack. And with P -Stack, you create a project -specific verification skill, which allows your agents to run real checks, meaning drive the actual application, use the feature map, use the browser, use the CL... Yeah, I mean, if you have CLIs, use the...
the CLI, use the terminal, use the console. Literally use everything available to you and at the same time use also XYZ playbook, use XYZ skills, stuff like that. And by the way, if you don't know what P -Stack is, that's absolutely fine.
I will explain it a bit later on, but I also recently created this video right here on P -Stack. I have no clue why this is in German, but yeah, it is what it is. It's a great library.
I will talk about it a bit later on. So P -Stack is the first tool I use, but there's a second tool called Test Sprite. And with that, here's a quick note.
from today's video sponsor, TestSprite. TestSprite is an AI testing agent that checks your running application and sends the results back to your coding agent. But now you might say, Can't my existing coding agent already do that for me?
Yeah, kinda, but not really. Sure, you can ask CloudCode or Codex to run your existing tests or use a browser to check a flow, but testing goes way deeper than that. It means deciding what you cover, checking edge cases, investigating failures, and repeating those checks after each code change and with that iteration.
TestSprite gives that work a dedicated testing workflow. It builds a test plan from your requirements and a running application, and with that multiple testing agents can then explore different flows in parallel, speeding everything up exponentially. Your coding agent can then hand over that work and get structured results back without having to manage every browser interaction itself.
And this also massively reduces the tokens spent on browser testing. In my own testing I've seen around a 50 % reduction in token consumption, which depending on how much you're coding can translate to $20 or more in savings per day alone. But what I really love is how easily everything fits into my existing coding workflow.
With the open source test sprite CLI, I don't even have to leave my coding environment. After making a change, my coding agent can simply trigger tests. to create new tests or rerun existing ones against my application.
TestSprite then opens a real browser and interacts with the application just like an actual user would. When something breaks, I get the step where it went wrong, supporting evidence, a likely explanation, and guidance for the fix. Inside the web portal, I can replay the session and see exactly what happened.
The coding agent can then update the code and rerun the same test. And since everything is saved in a re - usable suite, it can also check the behavior against future changes.
That's loop engineering in practice. Generate, execute, inspect, improve, and verify again. TestSprite 3 .5 also makes that process easier to follow.
Parallel agent work is visible, agent actions show what happened in each session, and the AI co -pilot lets me ask questions about failures or request another test case. There are also environment settings, GitHub options support, and shared workspaces for teams.
For me, the biggest value is the complete feedback loop, a test plan, evidence the coding agent can act on, and a reusable suite for the next change and with that iteration. So if you want to try TestSprite on your own application and let it find all of the bugs your coding agent generated, then you will find it linked down below in the YouTube description.
But with that out of the way, let's continue with the video. say, okay, Jen, enough with all of the theoretical stuff. Let's dive into the action.
Show me your software factory. How does it work? How does it look like?
And at the same time, how do you use it? Well, this here is Marshall Factory. This is what I built.
This is fully deployed on Vercel, by the way, meaning I can access it anywhere on my phone, on my desktop. It does not matter. And this here is the inbox route.
The inbox route is like the management observability panel. I can see all of my age. and what they are doing right now.
Currently, we don't see anything, and that's because no tasks, no agents are running. And one thing you should realize also right away is that this here is completely real -time, meaning I added real -time functionality live, as you see here, and this means whenever the state changes, when an agent goes over from investigating to implementing code, it updates in real -time without me needing to do a hard refresh.
Then in the sidebar, I also have a drops button, And look at this beautiful animation. Oh my God, it looks so good.
And here we now have the playbook. So if I go back to my little diagram I created, I created this one, then you will see here that we have a playbook inside of the factory. It's not that I just create a prompt and then say, hey agent, do whatever's needed.
No, the agent has to follow a specific like order. Do a triage, then investigate, then implement, then verify, then create a PR, ask me for help if needed, stuff like that. that's what you will see here step one cute then triage then investigating implementing verifying what else do we have here prci waiting on you and finally merged these are all of the states and i will explain this further in a second here we also have the other activity section this does not really matter this is if a task can't really be like grouped into a certain section i can also right here see all of my machines i currently only have one machine connected to this factory, which is my MacBook, and it's currently offline because it's closed.
But I can see when it was last seen 11 minutes ago, the CPU, memory, disk free, and then also all of my projects from the T3 state. I will explain T3 code in a second and how it connects to my factory. But yeah, I can also add more machines right here, my Mac Studio, some sort of like Linux server.
It does not matter. I can add multiple machines and then also use them whenever needed. What else do we have here?
Repositories. Inside of here, I can add repositories, which I want my factory to work on. Oh, and by the way, if I go back to the machines quickly, then you will see here that my MacBook is now connected online.
Let's also quickly check out the settings. Inside of here, I can set the default harness and model. In this case, I already selected Cloud Code and also Opus 5 .5, the best model ever created.
And this option is super interesting. Inside of here, I can select where each task, each job, should run.
If I select this Mac then this means every job will run locally on my MacBook. So every job will get a work tree and with that we can just work on multiple things in parallel without breaking anything. But I can also select cloud and this means every job, every task gets an individual cloud sandbox.
And this allows us to essentially scale infinitely. I'm not constrained by my local resources. Everything just works.
Everything just runs. And for the sandboxes I use a service called Modal, not sponsored or anything like that.
It's quite cool, it works quite well, and yet they provide sandboxes which are very scalable, but I will explain that a bit more thoroughly later on. Nevertheless, I want you now already get started, onboard a new repository, and then just kick off a few jobs, a few tasks. So inside of here in the repositories section, I can add a new repository.
Here I already installed the GitHub application, meaning I have access to all of the following repositories. set them right here. I want to onboard this repository, YouTube Factory Demo Test.
Let me click on it, and now it will essentially just pull all of the data and analyze everything. And now you might say, hey Jan, right here it says analyzing. What does that mean?
What is currently happening? Well, our factory, Marshall Factory, currently reads the repository by itself in a modal sandbox. It works out the setup, how to do checks, and then it will also open a recipe PR.
And if I go to the modal dashboard, you will also see it right here. One sandbox is currently live.
And you can also see it right here. So onboarding, building. Here we have our recipe.
We can also view the setup, right? So bun install, frozen log file. This here has all passed.
That's great. And here we can now also update a few settings. The display name is fine.
This repository takes new jobs. For the default harness, we want to use cloud code. Here we can also select where the jobs should run.
We want to say cloud. In other words, modal and then for merging I will select merge when confident.
So if the agent is confident it will merge the PR automatically. If I would now select off then this means I would have to do everything manually. But this is something I don't personally do.
I always have it set to merge when confident and it's safe it works well. And that's already it. Here I also set require bugbot review to true because I want to make sure that my agent actually waits for bugbot and also make sure that bugbot does not throw any errors.
us. So this all looks good to me, we are now ready, the sandbox has been built, the image has been built, meaning I can save everything right here. One thing I can also now do is open the GitHub repository and you will instantly see that we now have a new PR, add the factory setup recipe.
I can quickly check it out, let me open it, bum bum bum, here it is, and this essentially is just our setup .json file. This is how to set everything up, bun install, this is how to run the checks, and this here is our key.
So let's merge the PR. I will do it right here. Bum.
Merge PR. And now everything is finished. And since our sandbox is now built and with that also set up we can finally now create a few tasks.
So I have now created three linear to -dos in total, as you see here. Mark recipes as favorites, show the total cooking time of the visible recipes, and finally make the recipe book nicer. And as mentioned, yes, in this factory I'm using linear, but it's not a requirement.
You just need some sort of source. So if I go back to my software factory, you need some sort of source which allows you to create a ticket. Linear, GitHub issues, Grogbot, you could also...
use, I guess, ChatGPT with an MCP server. It all works. It does not really matter.
But the reason why I use Linear is because it's a product development system. You can see how the issue or how the to -do moves from, I don't know, assigned to progress to investigation to PR. So that's why I use Linear, but it's not a requirement.
And here's what will now happen. In a second, I will create a ticket. Then we should first of all have a triage step, meaning our agent will analyze the to -do and say either, uh -huh, this looks good to me.
Let's start investigation. Or the agent will say, you know what? This is kind of unclear.
What does the user mean? What does the user want me to do? And if that's the case, then the agent will stop everything and say, hey, user, please explain the issue further.
What do you want me to do? If not, as mentioned, we will go over to the investigation step, then to the implementation step, then to the verification step. And if the verification step fails, then we will go back to the implementation step.
Essentially, we have a loop. Implement, verify, implement, verify. And finally, once everything looks good, the agent will create a PR.
And as you already know, I added or, yeah, in the settings, I set the option to merge when confident. If the factory and with that all of the agents are confident, then everything will be merged automatically. If not, I will get a handover and I will review everything myself and then either merge it myself Or say this is incorrect, this looks ugly, whatever it might be.
So let's go back to Linear. Here's one thing I want to quickly show you guys. I added a few labels.
So first of all this here is not an issue but rather a to -do. And here I selected four labels. The first one is the harness.
I want to use cloud code for this to -do. Then the repository is this one right here. And the repository was added automatically once we created our repo.
So not only did we create like this setup. we also synced everything with linear. Then this will run in the cloud, not locally on my machine.
And I also added the factory label. This will create a webhook event and tell the factory, hey, we have a new to do, get started working. And now you might say, but Jan, didn't we add like default settings?
Yes, correct. So if I wouldn't add the harness and runs on right here, then we would just use whatever I set in the settings. So cloud, Opus 5 .5 and cloud code.
And also I want to quickly show you this to do because it's quite interesting. Because one thing you should realize right away is that it's kind of vague, right? Like make the recipe book nicer.
What does nicer even mean? And here I also changed the harness. Instead of using cloud code, we will use codecs.
And with that out of the way, I guess it's time to test everything out. Is anything running right here? Nope, zero drops.
So let me close the sidebar. Let's go back to linear and I will click. on create issue create issue and again create issue let's go back to our factory and what do we have inside of here currently we only have one ticket queued uh -huh interesting is there anything else running nope Is this an issue?
No. Because now we have them right here. It takes a second again.
Webhooks are asynchronous. They are not instant. And that's why we got the first issue.
Then the second issue. And then finally the third issue. And here we instantly already have something running.
Triage. Mark recipes as favorite. Oh my god.
It's already in the implementing stage. Isn't that cool? And I can even open this task.
And now look at the sidebar. What do we have right here? Triage.
Aha. Finished. Investigating.
Finished. Implementing. It's doing it right now.
Adding favorites .ts. A star button per card. And here you will also see that we are currently in the sandbox.
This is the sandbox ID. Codex login slot not held. And that's because we are using Opus 5 .5.
And I can even see all of the live events inside of here. What else do we have here? Oh, both tasks are now in the verifying stage.
Interesting. And we even have one which is now waiting on us. And if I now open this YTF9 task, then you will see the same thing.
I can even make this full screen. We now see again, this here is using Opus 5 .5, Cloud Sandbox, managed by my MacBook, my machine. This here is the cost, 35 cents.
And we also have evidence verified, four out of four checks, meaning tests, lint. type check and also build and by the way i see all of the commands this means again we have a full -on management observability panel i see everything i see what the agent did the timeline triage investigating implementing verifying and now we are in the prci and we can even see all of the live events the exact time and what the agent did in that specific moment on that specific event we also currently have a ticket that's waiting on me why is that Well, this here was super vague.
Make the recipe book look nicer. What does that even mean? And that's also what the agent realized right away.
Which scope should YTF10 implement? Visual polish or B or C? What should I do?
You were not very specific. So if I go back to my inbox, you will see it right here. This task is waiting on you.
I can now open it and I can also instantly respond inside of here. So what should we do? Visual polish only with clear wire typography.
Yeah, I will say, let's go with A. It will now send the answer to my agent and you'll see it right here. Answer sent, the job resumes.
It's now again queued because it got a new event, a new prompt essentially. And our agent will now then get started with the triage step, investigating, implementing, and then everything will already be finished. And you know what's quite cool?
If I go back to this task, which is now again running, I see the message I sent, let's go with A. And again, if we... look at the timeline, triage, waiting on you, answer received, triage, investigating.
But now you might say, hey Jan, this looks quite cool, but are we also able to like view everything in a coding environment? Am I able to take over? Well, yes.
So if I scroll to the top, I can right here open this in T3. So let me click on that. We are now asking the runner for a pairing link.
This takes a few seconds. I will now copy this URL and open it in a new tab. This will again take a few seconds.
This is not super fast, but that's absolutely fine. This here is currently running in modal in our sandbox and it will now open the T3ADE. And what do we have here?
This is our thread. So we had two sub -agents running, implement polish, and now our agent is almost already finished. And in theory, if needed, I could now go inside of here and say, hey, this is incorrect, do this, do that.
I can essentially step in and merge or steer the agent. Isn't that cool? And look, I hope you guys now understand why I'm so excited about this factory.
It's essentially everything I ever wanted. Most of the factories I saw on the web that other people created were kind of vibe coding slot machines, if I'm honest. It was like essentially input, output, that's it.
But that does not work. Your agent has to, or your factory, has to follow a specific recipe. I mean, again, let's take our kitchen analogy.
First of all, boil the water. Then Then I don't know, add some salt, add the noodles, create the sauce.
Then let's, I don't know, start with the meat, let's season it, whatever. You have to follow a recipe. And that's exactly what our factory is doing.
Everything starts with our ticket. Then triage, investigate, implement, verify. Oh, something failed?
Don't worry. Let's just go back to step three and let's continue in a loop until everything works. Create a PR.
You are confident? Then go ahead and merge. Is there something you are not sure about?
over to me. And since we are already talking about handovers I want you to look at our tickets. Did we merge anything or did our factory merge anything?
No. And why is that? Well it's relatively simple.
Right here it says confident but there was an issue. I couldn't check the page in a browser because the host lacks the browser libraries. And this is a mistake I created or I made.
I did not add the needed browser utilities and that's why the agent wasn't able to verify its changes. So if I go back to my factory a very important step was the verify step and the verify step has very important instructions like let's run learned tests let's run the build but at the same time also use the built -in browser and create a screenshot check out the result.
In this case it did not work and that's why we essentially failed if that makes sense or that's why our factory failed. It did not merge anything but the code was written everything is good meaning what I can now do is open the PR right here using the pull request button and I could now for example review the code.
I won't do that because I know it's clean so if I now click on merge pull request and go back you will see that it will also automatically update. So let's go back and now it's updated. It's not in the PRCI stage anymore but rather in the merged stage.
Now personally I'm not the biggest fan of this board view so I also integrated a list view and now I can view all of the tickets in a beautiful list and they are also grouped by the stages PRCI and also merged. Let's merge another PR.
I want to show you the real -time functionality. I will open the PR in GitHub so YTF8 and inside of here let's scroll to the bottom and I will click on merge pull request and then confirm merge. And if we go back to our admin management panel then it should automatically update.
Let's see. Bum! Did you just see that?
What exactly happened? Well, essentially GitHub sent a webhook event, our application got the event, updated the database and with that the UI also updated automatically. This looks beautiful.
Oh, and I didn't mention it yet, but Marshall Factory is completely open source. You will find the link down below in the YouTube description, underneath the like and subscribe buttons. Please don't forget you started, it took quite some time to create everything and quite a few around $3 ,000 worth of tokens.
So yeah, a like, a subscribe, and also a star would mean a lot to me and my heart. But now you might say, Jan, we now looked at what factories are, how they work. We looked at your factory, which is super fancy.
Nevertheless, you did not really explain how you built it. What technologies did you use? How are you able to open T3 code in the browser?
How are you using modal? And what about your local machine? How is every...
connected? Great question. So let's go back to Excalibur.
Inside of here I created a few beautiful diagrams and let's first of all start with the stack. So the first you could say, let's call it primitive, is the harness itself. That's our agent and we have access to cloud code, codex, cursor and I think also anti -gravity.
And in this case the harness is the program that reads the code, edits the files and also runs all of the needed commands. And our factory decides which harness each ticket gets. So, as you already know, in Linear, we added this label.
Where is it? Bum, bum, bum. It's right here.
And I can choose between Codex, Anti -Gravity, and Cloth Coat. Also, we have default settings. This means if I forget to add the label, then we will just use the default, which is Cloth Coat with Opus 5 .5.
Then, as a next step, we have T3 Coat. This is our multi -agent orchestrator. It runs many harnesses.
sessions side by side, each in its own thread. And each thread gets its own copy of the repo, so the jobs never get in each other's way, which is super important. And the most important reason why we use T3 Code right here is yes, because it's a multi -agent orchestrator, but also because you can control T3 Code from the outside using the provided CLI.
So the factory starts messages and stops threads without you clicking anything. And the factory also never talks to Cloud Code or Codex directly, it always goes through T3 Code.
It's our multi -agent orchestrator. And what do I mean by multi -agent orchestrator? Well, T3 Code allows us to use multiple models from different harnesses in one thread.
So if you want to learn more about T3 Code, then please head over to the best YouTube channel out on the market, Jan Marshall, because inside of here you will find this video. T3 Code has completely won me over. Let's now again go back, the next step is P -Stack.
And P -Stack is like our coding agent framework. It tells our agents how to work, in what order, what to do, stuff like that. So it's a plugin for cloud code, cursor, codecs, anti -gravity, it does not really matter.
And it provides playbooks for bug fixes and also features, skills, and then helper agents. As you already know, I created a full -on video on P -Stack. Check it out, it's quite big.
But as it TLDR, you get playbooks, functional skills, principal skills, agent definitions, and then also supporting scripts. And what you do is that you provide a prompt like, I want to implement authentication.
This here is the definition of done. These are my constraints. Get started.
You then invoke the potato mode skill. It acts as an internal router. So it interprets your request and then routes this prompt, this request to a playbook.
So if you want to implement a feature, it will route the request to a feature playbook. This feature playbook has then a set of steps with specific skills the agent should invoke, and then the agent will already get started.
It will invoke the needed skills, also use the needed sub -agents, the needed supporting scripts, and then we already have our verify step. This again is a loop, so if something fails, go back, update the code, verify, bam, bam, bam, and finally we then get the verified result with also all of the evidence which comes from our verify and review step.
As mentioned, please check out this video right here. It explains P -Stack on a way deeper level. But without P -Stack, the agent would just improvise.
With P -Stack, every job follows the same disciplined process. Investigate, build, test, review. It never skips anything because the playbook has a specific order.
And our factory, Marshall Factory, actually also builds on top of P -Stack. I added a few more playbooks and skills. So for example, when you ask instead of guess, how to report each stage, and how to judge whether the agent is confident.
And with that, if the agent should merge everything or rather hand over to me. Then we also have the factory. And this is what I built, right?
This is what essentially runs in the background. And we have three core primitives, runner, reporter, and finally panel. What is the runner?
Well, the runner is the foreman. So it runs permanently on my Mac, on my Mac Studio, on my Linux machine. It does not really matter.
It takes the tickets. starts the jobs, watches them, merges, and then cleans up afterwards. It never writes any code itself.
It's essentially just like a manager, if that makes sense. Then we also have our reporter, and it's like the jobs radio. It writes along inside every agent session and reports every stage, every sub -agent, and every token used.
With that, we are able to create our management observability panel. I'm instantly able to see, hey, four active runs, tokens, today 10 million, spent today 10 dollars.
Then what else do we have here? Our panel and this is our management panel which was deployed to Vercel. I can watch everything inside of there and step in when needed, OpenT3 code, stuff like that.
As the next step we have the where jobs run section and as you already know jobs can either run locally on my machine or in the cloud using a sandbox. If we would now pick local then this means everything would run on my Mac in a T3 thread with its own work tree.
So a separate folder with a copy of the repository so that nothing kind of merges or that nothing conflicts if we have parallel sessions. And then we also have our cloud environment and this means every job gets its own small machine with T3 code inside already installed and it's also completely separated. Every sandbox is an individual sandbox so we can run as many as needed in parallel side by side and nothing will ever conflict.
They are not in one machine. With a local machine, we have to create work trees because every job runs in one machine. But using our cloud sandboxes, every job gets an individual sandbox.
So we don't even have to create a work tree. And finally, we also have our sources. And this is where the work comes in from.
Currently, we offer Linear and Slack. But the next step would be to also integrate GitHub Issues, Cloud Duo, Grogbot. What else is there?
I guess, I don't know, iMess. that would also be quite cool. Essentially, you just need some sort of like text input, which can send events to our factory.
So now you might say, okay, Jan, this is quite interesting. We have a harness or multiple harnesses. T3 Code wraps the harnesses.
Then we have P -Stack, the factory, with a runner, reporter, and a panel. Then we can either run the job locally on our machine or using cloud sandboxes, in other words, modal. Then we also have our sources.
Nevertheless, I'm still a bit confused. Like, how does everything connect to each other? From my understanding, we start with the sources.
We open Linear, we create a ticket. But what's the next step? Do we send a webhook event?
And where do we send the webhook event to? To our application? To our database?
How does everything work? Great question. Here I created a diagram for the whole factory and how everything connects to each other.
As already mentioned, everything starts with our sources. And what did we do? Well, we created a ticket in Linear.
And what did we do in the ticket? We added labels. Let me quickly show it to you.
Here we added four labels. Codecs for the harness, then the repository if we want to run it on our machine or in the cloud. And I also added the factory label.
And the factory label tells our software factory that it should attack the ticket. No, I'm joking, that it should work on the ticket, fix the bug, implement the feature, whatever it might be.
And Linear then sends a webhook event with an automatic message. It then goes into our ingest function, as you see here, and the ingest function is a small program hosted on Neon. And since I already mentioned Neon, let's also talk about Neon.
Neon is the backend as a service I use for this whole software factory. If you didn't know, Neon provides the database, authentication, compute, storage, and AI gateway, and also recently they added real -time functionality.
And I use Neon pretty much for everything. So first of all, once we then get the webhook event, it then gets ingested into our webhook inbox. So every incoming webhook from Linear, GitHub, Grogbot, Cloud Duo, whatever, is stored inside of here.
And from there on, a small request is created, for example, take ticket YTF8, or what did have inside of here ytf10, whatever it might be. Then we also have our events and in this case events is just a database table.
Let me quickly show it to you. This here is the table with all of the individual events. Kind, stage, usage, then stage, agent launched, session start.
Essentially this table is our logbook. Every stage, sub -agent and token is stored inside of here which also then allows me to showcase everything in our management observability panel. I can instantly see the amount of tokens used and also the total spent for today.
Finally, I also have live updates. As already mentioned, Neon has a new primitive called Realtime. So when something changes in our database, for example, an event inside of here, maybe we added a few more tokens or we used a few more tokens, then Neon will automatically push this information to whoever is listening.
And this then means the runner and also the panel. As a next step, we then have my local machine, my MacBook, my Mac Studio. my Linux machine, whatever it might be.
And the runner here is super important. So the runner on my MacBook hears about the request and then within seconds, maybe even milliseconds, takes the ticket. So we essentially claim the ticket.
Neon gets all of the tickets from Linear. One, two, three, four, five. It then sends all of the tickets to my MacBook and then my MacBook or my machine, whatever it might be, claims the tickets.
Once the runner claimed all of the tickets, it then decides where the job should run, either locally on my machine or in the cloud. So if it happens locally then we will just use my MacBook as an example and use the T3 code and create a new work tree.
And if we want to use a cloud sandbox then the runner will start a cloud sandbox for every job. So if we have five jobs then we will spin up five individual cloud sandboxes and our local machine still stays in control. So the runner on our Mac will still start everything, it will watch everything and it will also be the one which will shut every everything down, our sandboxes and stuff like that.
For the cloud sandboxes I use a third party service called Modal. It's quite cool but there are also a lot of other alternatives out on the market which are also cheaper and faster but Modal has a quite cool free tier and that's why I used it. And here we also have like three core primitives, the worker image, the sandboxes and then also Hibernate.
So the worker image is a template machine with every tool at a fixed version. code, cloud code, codex, pstack, the reporter, the playbooks and then for every repository we have a warm version with the code already cloned and also installed. So if I go back to my factory and with that to my repositories then you will see right here warm cloud sandbox image ready.
That's what I meant. In terms of sandboxes every job gets an individual sandbox with the template and everything is of course completely separated and finally we also have our hibernation.
This means if a job only waits for a review or an answer then it will be frozen and after five minutes it shuts down so that we don't incur any cost. And once we then answer it wakes up automatically and carries on. Then we also again have stage four and stage four goes back to Neon.
So while the agent works the reporter sends every step back to Neon so that we can update our events. Hey we used the following amount of tokens. This is now the new stage.
We went from very verifying to PR or we went from triage to implementing, whatever it might be. And at the same time, as you already know, let me quickly go back.
Our reporter right here also reports back if something is unclear. So if the ticket is way too vague or if I did not provide enough information, then the agent will say, stop, wait a second, be more specific, whatever it might be. I mean, I showed you everything.
And then again, we will just send the message. Neon will then go back to our mark. Our runner will get the new message and then hand it.
over back to modal if we use cloud sandboxes. Step five is then our panel itself. As you already know, my panel runs on Vercel.
It's deployed on Vercel and it reads everything from Neon in real time. As mentioned, Neon has now real -time functionality and my panel is then connected to Neon whenever something updates in my database. Like for example, in event, it automatically gets updated in Vercel without me having to do any hard refreshes or as already mentioned, without having me to subscribe to something or create weird web sockets, manage them, scale them, stuff like that.
Step six is then already to push the PR. So the agent just creates a branch and then opens a PR. It also reports how confident it is and what it built.
And then finally, the agent or our factory either merges everything by itself or it hands over to me and says, hey, I'm not super confident or something is missing. I'm not able to verify everything. Please review the code and merge it yourself.
As a next step, we then create a webhook event. For that, we use our ingest function.
It updates our database, our events table, and we again update the cell, our panel. So if I go back to my factory, essentially we move our, let me quickly show it to you, we move our ticket from the PRCI stage into the merged state. So if I merge this PR, let me quickly open GitHub, it's loading.
Let me merge it inside of here, confirm merge. And if I now again go back, then you will see that it will now automatically update.
We sent a webhook event, Neon then used the ingest function, it updated our database, and since we use Neon Realtime, the Realtime primitive, it also instantly updated this panel, which is deployed on Vercel. And yeah, that's already it, as you see here, seven steps in total, and it's actually not that complicated. Again, step one is to essentially create a ticket in Linear or create a message in Slack.
Neon then gets this new request using the ingest function, it updates the database, and then essentially just routes this event to our Mac. My machine then claims these tickets and then hands over the work either to our local machine or to the cloud.
Model then manages everything, creates the needed sandboxes and hibernates if needed. While everything runs, our machine also reports everything to Neon, meaning the stage, the agents, the cost, and everything also updates automatically in my panel. Once our agents are finished, we then create a PR or our factory then creates the PR and either merges it automatically or hands over to me.
Once everything is merged, we again create a webhook event, our ingest function is used, our events table updates, and everything updates in real time, meaning also our panel, which is deployed on Vercel. It's as simple as that. And yeah, that's already it.
Please don't forget to like and subscribe. It would mean a lot to me and my heart, so please do it. As already mentioned, this factory is completely open source.
The link is down below in the YouTube description. Thank you Testsprite for making this video possible. And yeah, one thing I want to just quickly mention is that this year is still work in progress.
There are still bugs. I'm working on everything. I'm still trying to make it better.
If you want to help me create a few PRs, I would love your support. And with that out of the way, enjoy your day and see you in the next video. Over and out.
Bye -bye.
The Hook
The bait, then the rug-pull.
The opening shot is a Kanban board of agents mid-flight: 15 active runs, 120 million tokens, PRs sliding from verifying to merged. The promise is simple and a little tired-sounding in the best way: stop being the human who types continue after every agent step.
Frameworks
Named ideas worth stealing.
17:57list
The factory playbook
Ticket
Triage (or ask the human)
Investigate
Implement
Verify (loop back to implement on failure)
Open PR
Merge when confident, or hand over
Every job follows the same ordered stages; verify loops back to implement until checks pass, and the final merge is gated on confidence.
Steal forany agent workflow where you want predictable stages and a clear human checkpoint
02:44model
Chef and cooks
Orchestrate
Delegate
Quality control
Steer
One human chef over roughly ten agent cooks; the chef never cooks each component but nothing leaves the kitchen without them.
Steal forexplaining human-in-the-loop AI to a team or client
06:29list
Merge-when-confident gate
Agent reports it is confident
CI is green
No open Bugbot comments
Verification evidence captured
All conditions must hold for the factory to merge its own PR; any miss hands the PR to the human for review.
Steal fordeciding when any automation is allowed to act without approval
28:20list
Factory stack layers
Harness (Claude Code, Codex, Cursor, Antigravity)
T3 Code orchestrator
PStack playbooks
Factory: runner, reporter, panel
Where jobs run: local worktree or Modal sandbox
Sources: Linear, Slack
Each layer has one job, from the agent that edits code up to the source that feeds tickets in.
Steal forplanning your own agent pipeline one layer at a time
32:20model
Runner, reporter, panel
Runner: the foreman that claims, starts, watches, merges, cleans up
Reporter: the jobs radio that logs every stage, sub-agent and token
Panel: the dashboard where the human watches and steps in
The three core pieces of the factory itself, deliberately separated so the supervising process never writes code.
Steal forany long-running background job system that needs observability
39:00list
Modal cloud primitives
Worker image: pinned tools plus a warm per-repo copy
Sandboxes: one per job, T3 inside
Hibernate: freeze when idle, shut down after five minutes
How cloud jobs start fast, stay isolated and stop costing money while they wait on a human.
Steal forrunning agent jobs in remote sandboxes cheaply
CTA Breakdown
How they asked for the click.
VERBAL ASK
27:40link
“Marshall Factory is completely open source. You will find the link down below in the YouTube description... a like, a subscribe, and also a star would mean a lot to me and my heart.”
Placed right after the realtime merge demo lands, tied to the $3,000 token cost to earn the ask, and repeated briefly at the outro with an invitation to contribute PRs.
Add Modern Creator as a preferred source and Google shows you more of our breakdowns in Search, Top Stories, and AI Overviews. It only changes what you see, and you can undo it in your Google settings anytime.
Add to Preferred SourcesOpens your Google source preferences with us pre-loaded. Tick the box and you're done.
A six-hour live build of an Intercom-style support platform, from idea and PRD to a production deploy, with the workflow doing more work than the model.
A tour of real demos reverse-engineering QuickTime, TickTick, WhisperFlow, CapCut, and Loom with AI coding agents, and the ethics question none of them settle.
A stage-by-stage breakdown of Lauren Tan's open-source Claude Code and Cursor skill pack, measured against the other skill packs already on the channel.
A developer shows how an open-source tool called REA lets any coding agent reverse engineer closed-source apps into working clones, then argues the only moat left is caring enough to polish what you ship.
00:39
01:55
02:22
04:08
05:14
05:47
06:20
06:53
07:44
08:58
09:36
09:56
10:40
11:18
12:24
12:57
13:30
14:04
14:37
15:43
16:16
16:49
17:55
18:28
19:35
20:08
20:41
21:14
21:47
22:53
23:26
23:54
24:32
24:53
26:24
26:45
27:18
27:51
30:15
31:10
31:45
32:49
34:28
35:01
36:08
36:41
37:14
37:47
38:20
38:53
39:59
40:32
41:05
41:39
42:10
42:45
43:18
5:55:23
28:44
16:35
21:15
14:56
12:57