Short answer: At Zelifcam, AI coding agents pick up small, well-scoped development tasks from our project board. An agent writes the change, runs the tests and moves the task to QA. Then people take over. A person reviews it, the client tests it, a developer merges it and someone presses deploy. That's our version of what people are now calling a software factory.
I want to tell this one as a story, because the first month didn't go the way I drew it up.
What "software factory" means here
The phrase is everywhere right now. The idea is simple: agents do much of the building, and people set the direction and sign off at defined gates. It's an old term. Software shops were calling themselves factories decades ago. The new part is who's working the line.
Ours is small. It's one board, a handful of repos and a few strict rules. I'm not going to tell you it writes our software for us. It handles a certain size of task, and people handle everything around it.
How a task moves
Every development task lives on our project board in Odoo. The stages are plain:
- Backlog
- Approved to Start
- In Progress
- Revision Required
- Quality Assurance
- UAT, where the client tests it
- Deployed
A small background worker watches the board for tasks tagged for the agent. When it finds one in Approved to Start, it hands it off. The agent works the task, runs the tests and moves the card to Quality Assurance. If it can't figure something out, it doesn't guess. It tags the task "needs clarification" or "needs person" and stops.
The rules that make it safe
None of this works without the boring parts.
Small tasks only. A task has to be 5 points or fewer to go to the agent. If it's 8 or more, it goes back to the project manager to break up. Big, fuzzy tasks are where agents wander off.
A directions file in every repo. Each codebase has a short file that tells the agent the base branch, how to build and test, how QA works for that project and which areas are high risk. It's the same thing you'd hand a new developer on day one.
Tests have to pass. There's an automated test gate. If the tests fail, the task doesn't move forward.
People own everything after the code. A person does QA. The client does UAT. A developer merges. Someone presses deploy. The agent doesn't do any of those.
What broke
Here's the part I'd want to read if I were you.
Review couldn't keep up. The agent was faster than our people at producing changes. Pretty soon the Quality Assurance column was backing up. That's the trap with these setups. If the agent ships faster than humans can check, you either let unchecked work through or you build a pile. We weren't going to let unchecked work through. So we wrote the rule down: on some projects a separate AI tester runs QA, but a person approves every release to a live system and presses the button. Speed at the front of the line doesn't matter if the end of the line is jammed.
An agent talked to a client when it shouldn't have. At one point an agent posted internal notes as messages a client could see. Internal notes are internal. We turned off auto-posting to any channel a client can see. Now the agent writes notes where only our team reads them, and a person decides what the client hears.
Rollbacks earned their keep. When something did slip, being able to roll back cleanly is what kept it from being a bad day. If you're setting up anything like this, make sure you can undo a deploy before you make it easy to do one.
What I took from it
Every company is different. The setup that works for our dev shop wouldn't fit a dental office or a distribution company. What carries over is the rules.
- Keep the work small enough to check.
- Write directions down where the agent reads them.
- Put an automated gate in front and a human gate at the end.
- Don't let an agent talk to a customer on its own.
- Make undo easy.
That's the same thinking behind how I run the rest of the company with agents. The sales agents draft follow-ups, and I approve the exact text. The bookkeeping agents match transactions, and the bigger calls go up the chain. The dev agents write changes, and a person signs off before anything ships.
Is this a service?
Not really, and I want to be clear about that. This is how our own development team works. We're sharing it because it's a good, honest example of what an agent setup can and can't do, including the parts we had to fix.
If you want to read how the same idea works across a whole company, here's how I run Zelifcam with a team of AI agents. And if it got you thinking about one department in your own business, this is what we set up for owners.
Related: Are AI agents going to take my people's jobs?
Brandon Howard is the CEO of Zelifcam, a custom software, automation and Odoo partner in San Antonio, Texas.