What Is a Software Factory? From Customer Feedback to Merged Pull Requests
A software factory is a system that turns customer feedback into verified, merged code changes without a person carrying each request through triage, ticket writing, implementation and review by hand. It has four stages: collect, recommend, build, verify. A person still approves every merge. The unit of output is a merged pull request, and in Starko that is also the unit of billing.
This post explains why we built Starko around that loop, what each stage does, and what changes for a team that switches it on.
Why the loop matters: most engineering time is not spent building
Engineers spend about 16% of their week building new features, according to Chainguard's 2026 Engineering Reality Report, a survey of 1,200 engineers and technology leaders run in August 2025. In the same survey, 79% named code maintenance as a major drain and 66% said they frequently encounter technical debt ().
The rest of the week goes somewhere. Atlassian's State of Developer Experience Report 2025, based on 3,500 developers and managers in six countries, found that half of developers lose 10 or more hours a week to organizational inefficiency. The top causes were finding information, context switching and cross-team collaboration ().
A customer bug report is the clearest example of that waste. It arrives in a support inbox, gets summarized by a support agent, gets re-summarized into a ticket, waits in a backlog, is picked up by an engineer who re-reads the thread, is fixed, is reviewed and finally merged. Each hop is a hand-off where the original report gets re-summarised. The factory exists to remove the hops, not the people who make the final call.
The three assumptions behind a software factory
Three beliefs sit under the product. If you disagree with them, the rest of this post will not convince you, so here they are up front.
- Teams will ship more software than they can maintain by hand. GitHub reported an average of 43.2 million pull requests merged every month in 2025, up 23% year over year, and more than a million pull requests created by its coding agent between May and September 2025 (). Output is rising faster than the capacity to review and maintain it.
- The best roadmap signal is already in support conversations and session replays. Customers tell you what is broken and what is missing, in their own words, every day. Little of it is written down in a form an engineer can act on.
- A product should be able to fix and improve itself, with a person approving each merge. The approval is not a formality. It is the control that makes the rest safe to automate.
Stage one: collect everything in one inbox
The factory starts as a support inbox. Conversations from WhatsApp, email, Slack, Instagram and the website widget become tickets with a customer, a priority and a type. Starko AI answers what it can from the knowledge base and routes the rest to the right project.
Two things make this stage different from a normal helpdesk:
- Session replays sit next to the transcript. The widget records what a visitor did on your site before and during a conversation. Starko renders the recording into frames, reads it alongside the chat, and classifies friction such as dead ends, rage clicks, loops and abandoned forms. Each analysis becomes a verdict with evidence attached.
- Repeats are deduplicated, not duplicated. When the same problem shows up again, it is recorded as a sighting on the existing ticket rather than a new one. Once a week, the week's analyses are grouped into themes and filed as one digest ticket.
The collect stage is free. Feedback intake, understanding and AI answers from the knowledge base do not cost anything, because nothing has been built yet.
Stage two: recommendations you accept or decline
Repeated friction becomes a recommendation: a bug or an improvement, sized Small, Medium or Large, with the visitors behind it and a credit cap. You accept or decline from Home or the Improvements page. Nothing is built until you do.
The size matters more than it looks. It sets the token budget for the run, decides whether the reviewer agent is skipped for trivial changes, and is mirrored to workspace tags so you can filter and report on it. A ticket you tag yourself is treated as pre-classified, so your judgment overrides the classifier.
The credit cap is the other half. Before you accept, you see the most a run can cost. If the run goes over the cap, it stops. If the resulting pull request is closed without merging, you are not billed at all.
Stage three: a coding agent builds in a sandbox
An accepted recommendation starts a run in an isolated sandbox with your real toolchain. Claude Code, OpenAI Codex or Cursor writes the code. Starko decides what to build, writes the brief, provisions the sandbox, reviews the output and keeps the ledger.
Each project keeps a warm sandbox snapshot with dependencies installed, so a run boots in seconds and always fetches the latest commit. A research run writes a repository map that later runs read on demand instead of rediscovering the codebase every time. Ticket attachments, including files embedded in the description, are staged into the sandbox so the agent sees what the customer saw.
You are not locked out while this happens. The ticket's Starko AI workspace streams the agent's steps, its changes and a live preview. You can send it files, steer it mid-run, share a console with teammates, or stop it. If the agent needs something only you know, it mentions the ticket owner and a plain reply on the ticket resumes the run.
Stage four: verify before anyone reviews
The build stage ends with a claim. The verify stage checks it. After the agent finishes, Starko runs the project's own test command in the sandbox and records the real exit code. A reviewer agent reads the full diff and posts a risk-rated assessment. If the review asks for changes, or CI goes red, the run is re-dispatched within a per-project cap, so a fix cannot loop forever.
Every pull request then opens inside Starko with its own evidence: what was reproduced, every command the sandbox ran with its exit code, the reviewer's verdict, and the status of each check. Anything that could not be verified in CI is flagged for a human rather than hidden. You merge from the same panel, the ticket closes, and the customer who reported the problem is told.
This stage is where the trust question gets answered. In Stack Overflow's 2025 Developer Survey of 49,009 developers, 66% named "AI solutions that are almost right, but not quite" as their top frustration, and 46% said they actively distrust the accuracy of AI tools versus 33% who trust it (). An agent that ships a diff with no proof asks the reviewer to do all of that work again. An agent that ships a diff with commands, exit codes and a second opinion asks the reviewer to check the proof.
What changes for the team
Three things, in practice.
Runs happen in parallel across many tickets. A factory does not work one sprint at a time. Several recommendations can be in flight at once, each in its own sandbox, each with its own cap.
Autonomy is a per-project policy, not a global switch. Each project decides what Starko AI may do without asking: open pull requests only, auto-dispatch small fixes, or ask before every run. A sensible path is to start with "ask before every run", move to auto-dispatching Small fixes once the merge rate on them is high, and keep Medium and Large on manual.
The ledger is always visible. Merge rate, time to merge and cost per merged pull request sit next to each run's trigger, outcome and CI state. You can see what the factory produced and what it cost without exporting anything.
Where the factory lives in the product
The dashboard is organised around the loop. Home is where you talk to Starko and where it speaks first when something happened: a run finished, a pull request is ready, a reminder fired. Inbox is where conversations wait. Improvements is where recommendations wait for a decision. Projects carry their tickets on a timeline coloured by delivery state: planned, running, pull request open, merged.
Slack gets the same loop. In a project channel, Starko acts as a foreman: it posts run progress, asks when it needs more information, and a reply in the thread resumes the run. In a direct message it is a personal assistant with the same tools as the in-app chat.
If you want the detailed walkthrough of a single run, read . If you want to know what it costs, read or go straight to .
Frequently Asked Questions
What is a software factory?
A software factory is a system that turns customer feedback into verified, merged code changes through a repeatable loop: collect feedback, recommend a change with a size and cost, build it with a coding agent in a sandbox, and verify it with tests and a reviewer before a person approves the merge.
Does a software factory replace engineers?
No. It replaces the triage, ticket writing and waiting that sits between a customer and a merged change. Engineers still own the codebase and review every pull request. They review work that already has tests, commands with exit codes and a reviewer's verdict attached.
Which coding agents does Starko work with?
Claude Code, OpenAI Codex and Cursor. You bring your own credentials and model choice. Starko is the system around the model: it decides what to build, writes the brief, runs the sandbox, reviews the diff and keeps the ledger. Enterprise plans can run self-hosted models on dedicated runners.
How is a change verified before I see it?
Each run happens in a sandbox with your real toolchain. Starko runs your project's test command and records the exit code, a reviewer agent rates the risk of the diff, and CI results roll up into the pull request panel. Anything that could not be checked automatically is flagged for a human.
What does the factory cost?
Collecting feedback, AI answers from your knowledge base and recommendations are free. You pay per merged pull request, with a credit cap you see before you accept a run. A pull request that is closed without merging costs nothing.
