Paul Iusztin, a software engineer, built his own software factory called Squid three months before writing in July 2026 so he could ship Decoding AI’s small and medium projects with minimal human intervention. He argues there is a clear boundary between “vibe coding” and using coding agents to produce clean, maintainable code, and that boundary is best described by the concept of a software factory.
What is a software factory?
Like a physical factory, a software factory automates the creation of software with minimal human input: raw work (bug reports, feature ideas, incidents) goes in, shipped software comes out. The system needs a few highly skilled people to make high-leverage decisions and defined gates that work cannot pass without them.
Factory.ai markets a "self-improving system for your Software Development Life Cycle (SDLC)." Addy Osmani frames the stack as loop, harness, factory — "the loop is the atom" and the factory is "an org chart made of loops." Warp CEO Zach Lloyd predicts "software engineering will become factory engineering."
Iusztin outlines eight stages of the factory, grouped into three buckets:
-
What to build
- Triage/intake: classifies, deduplicates, and routes incoming work
- Brainstorming: identifies high-impact features using market analysis, user data, and technical research
- Planning: the most important stage, where research becomes a polished plan; agents grill the human, and decisions are recorded in an ADR and glossary; outputs are tickets with documentation
-
Actual building and checking
- Implementing: a software-engineer and QA-agent loop that executes tickets
- Review: checks PR diffs against product, architecture, and code standards
- Review-CI: runs the test suite; failures trigger a fixing agent
- Release: handles continuous delivery to staging/production with human deployment checks
-
Self-improving
- Monitor/incident response: production signals (alerts, errors, incidents) are fed back into triage as new input, closing the loop
Running across all stages is a shared context layer: docs, user analytics, competitor analysis, transcripts and other sources. Brainstorming and planning are particularly sensitive to the quality of this layer — poor context constrains what agents can propose. A common strategy is the LLM Wiki (a term credited to Andrej Karpathy), which turns files into a structured knowledge base. Factory’s AutoWiki and LangChain’s OpenWiki are examples; Iusztin has documented workflows that convert Obsidian, Readwise, and Google Drive data into agent memory via LLM wikis.
Where humans add value
Using an end-to-end example (a shopping-assistant on an ecommerce platform): when user data shows low engagement with recommendations, agents can analyze activity, scan competitors and pull research into the knowledge base, but human judgement is needed in brainstorming to interpret the data and define a business-facing feature spec. Planning is where humans, helped by the factory, turn the spec into an implementation plan — considering feasibility, architecture, interfaces, data flow, cost and latency. The human lets the agent scan the codebase and refines the plan until it fits the existing repository; the output is tickets and an ADR.
The better the plan, the cheaper the execution. Iusztin recommends using stronger models (e.g., Fable) for brainstorming and planning since downstream execution depends on them. Well-written plans allow cheaper models (Opus, Sonnet) to execute efficiently; weak plans force more retries and raise total token costs (cost is tokens × price, not just model tier).
From implementation onward, a software-engineer agent picks ready tickets and implements them; a QA agent stress-tests to find bugs. Because agents have a positive bias toward their own outputs, splitting roles between engineer and QA agents matters — Addy Osmani notes the model that wrote the code is "way too nice grading its own homework." Agents must be able to interact with the application like a human: start the stack reproducibly, drive the UI, call APIs or data pipelines. Embedding multiple feedback loops (linting, unit, integration, end‑to‑end tests) is key; repeated loop failures usually point to missing plumbing rather than agent logic.
Review consists of three checks: product and architecture requirements (discrepancies become tickets), code quality (modularity, naming, avoiding AI slop), and CI/CD pipeline. Any failure auto-creates a task for the implement loop. The factory typically ends with a PR that a human reviews and merges; with a strong plan, that PR is often ready to ship as-is.
Iusztin’s summary: humans are indispensable during brainstorming and planning, and they return for the final review — agents execute most steps in between. OpenAI pushed this model to an extreme in its internal experiment: ~1M lines and ~1,500 merged PRs over five months with zero hand-written lines, framed as "Humans steer. Agents execute."
Don’t overbuild the factory
In his first Squid version, Iusztin chased full autonomy with complex remote workflows and parallel agents. When something went off-script he could not debug, halt, or redirect a run easily. He concluded you need two modes: granular commands that let you interrogate a plan, implement a single task, or review a specific step; and an end-to-end command that chains smaller commands into a fully autonomous graph (e.g., a /plan and /implement-review-all command). Each step can be a "loop" while the whole pipeline is the factory "graph." Planning and execution should remain separable, with planning kept as a human-driven command.
Practical observations:
- Planning often remains the bottleneck even as execution is automated.
- For solo or small-team workflows, local isolated agents (worktrees) are often sufficient; 24/7 remote agents introduce significant management overhead.
- Large teams may justify more automation, but it must be earned: start small, automate the most time-consuming bottlenecks, and add complexity gradually.
Build vs. buy
Most projects start with a prebuilt coding harness: vendor-locked options include Claude Code and Codex; open-source alternatives include OpenCode or Pi. Picking a harness is not the same as knowing how to configure it and wire it into your factory. Engineers should understand how a coding agent works under the hood: the terminal loop, differences when it runs remotely, how to evaluate it, and context-engineering strategies that keep it cheap without dumbing it down. Iusztin points readers to his open-source course and guides for building intuition even if they never build a harness themselves.
For small teams, defining a set of skills and agents that encode your process on top of a harness (i.e., your software factory) can go a long way — which is how Iusztin built Squid. Off-the-shelf skill-and-agent approaches exist (examples cited include Matt Pocock’s skills repo and the BMad method). But the factory is mostly about processes, not tools: a factory that doesn’t fit how a team already works adds friction and won’t be adopted.
You cross into the "buy" territory when engineers you don’t personally supervise run agents: observability, tracing, cost tracking and pay-per-token billing become operational responsibilities. Agent swarms integrated into Linear, Slack and CI across distributed infrastructure are a logistical burden. That’s when platforms like Factory.ai (which ships with the Droid agent) or Warp’s Oz become attractive. Conversely, you should build when platform constraints cost more than the team required to replace them — a tension illustrated by OpenAI’s Codex report.
What’s next
Labels like "loop engineering" or "graph engineering" keep emerging, but the software engineering processes that produce real code change less frequently. Iusztin echoes Zach Lloyd: pick one annoying part of your job and build the smallest loop that handles it.
Software factories are in their early phase — far from perfect and far from fully autonomous. Iusztin believes we’ll reach a point where almost the whole SDLC can be automated except brainstorming and planning, but today many teams are still figuring out the right balance. For him, planning stubbornly remains the main human bottleneck as he continues to automate the rest.
Practical prompt
Which stage of your factory still needs you the most? Iusztin recommends iterating: keep automating, but always keep the ability to step in, stop, redirect and interrupt the system while preserving an option for full autonomy.
