Software factories · 28 nodes
Running a software factory
Connect requests, AI-assisted coding, tests and review. Learn how to save progress, handle failures and decide which steps still need a person.
Browse the reading orderIs this path right for me?
Nothing is tracked and nothing is locked — the map exists so you can see where an article sits.
-
STAGE 01 Understand the system
What a software factory is
See how a software factory connects planning, coding, tests and review, what AI agents do, and where a person still needs to decide.
- Request to release
- Where people decide
-
What passing tests can miss
See what passing tests can miss in an AI software factory: duplicated rules, growing review queues and changes that are difficult to undo.
- The next change
- Handling a failed release
-
12-factor agents
Learn the twelve agent-design principles through a pull request that times out: what the model proposes, what the program allows and how work resumes.
- Proposed actions
- Saved progress
-
How agents hand work over
See what one agent should leave for the next: the request, changed code, test results and unfinished work, with an example handover record.
- Plans, code and results
- Continuing later
-
Context engineering: what the agent sees
Learn how to choose an agent's instructions, code and test results, avoid stale information, and distinguish context engineering from prompting and RAG.
- Relevant files
- Facts and instructions
-
Context rot: when to restart
Recognise repeated mistakes and buried requirements in an AI coding session. Learn what context rot means, when to reset and which work to preserve.
- Repeated mistakes
- A better starting point
-
The tools and checks around an agent
See how a harness supplies tools and permissions, enforces access rules, and lets you replace a component without silently changing its meaning.
- Working test commands
- Enforced permissions
-
STAGE 02 Prepare and build
From vague request to ready ticket
Turn a vague request into a coding task by checking the existing code, asking specific questions and recording the behaviour and tests people agreed on.
- Find existing answers
- Ask what is missing
-
Keeping specifications and code aligned
Learn which specifications to maintain, how they differ from implementation plans, and what to do when the written rule, tests and running code disagree.
- Agreed behaviour
- Outdated documents
-
Research, plan, implement
Guide an agent through existing code: find the current behaviour, agree on the change, plan a testable part and pass on findings without a whole chat history.
- Small testable changes
- Useful handovers
-
An Angular software factory, one feature at a time
Follow one Angular booking feature from agreed behaviour to reusable components, server checks and tests, then reuse the parts that should stay consistent.
- UI and API boundaries
- A checked feature
-
The coding agent and its repair loop
Follow a coding agent from a ready task to a tested change, including limited repair attempts, scope changes, blocked tests and a handover to a person.
- Use actual test results
- Limit repeated attempts
-
When an agent stops and asks
Design an agent's handover to a person: ask a specific question, save progress, route it to someone who can decide and resume after checking the answer.
- A specific question
- Resume after the answer
-
The pull-request review agent
Use an AI reviewer to inspect proposed code, tests and requirements. Keep revision-specific findings separate from fixes, build results and merge approval.
- Review the right version
- Explain the finding
-
AI coding and human attention
Keep AI-generated changes understandable: decide permissions before coding, inspect code and tests, and stop starting work when reviewers cannot keep up.
- Cognitive load
- Keeping understanding
-
STAGE 03 Review and control
The human merge gate
Decide what a person must review before an agent's change is merged, how consequences affect review depth and how to prevent approval becoming a formality.
- Understand the change
- More than an approval click
-
Prompt injection in a pipeline
See how instructions hidden in tickets, code or logs can redirect an agent, why structured handovers do not remove the risk and which permissions to restrict.
- Instructions hidden in data
- Unwanted actions
-
Scoped credentials and the kill switch
Limit what each agent can read and change, stop new and active work, and test that temporary permissions expire without relying on instructions alone.
- Limit access
- Stop active workers
-
Golden sets: testing the factory
Compare agent changes on repeatable tasks with expected outcomes, turn discovered failures into regression cases and measure complete runs rather than one step.
- Repeat the same tasks
- Check expected outcomes
-
Loop engineering: retry or stop?
Design repeated agent work around actual test results, saved progress and stopping rules. Follow a repair loop and a recurring maintenance example.
- The next useful action
- Wait for review
-
Deterministic steps and AI steps
Choose scripts for explicit rules and AI for investigation. See when one model call is enough, when a workflow fits, and which checks code must enforce.
- Rules a script can check
- Questions needing judgement
-
Ephemeral environments and seed data
Give an agent a runnable test environment with isolated state and invented data. Learn what to preserve, what to clean up and which startup costs to measure.
- Isolated test runs
- Invented starting data
-
STAGE 04 Operate and improve
Orchestrator, or just a pipeline?
Decide whether an agent task fits your existing CI pipeline or needs saved workflow state for approvals, restarts and shared ownership.
- Use existing tools
- Save waiting work
-
Verifying after the deploy
Check that the intended version is serving before judging a release. Distinguish missing version information, rollout delays and failed behaviour checks.
- Identify the release
- Check permitted behaviour
-
Incidents back into the backlog
Turn repeated errors into useful follow-up work: group related events, update existing tickets and distinguish a returning defect from delayed old reports.
- Group related errors
- Update existing work
-
What a merged change costs
Calculate agent costs across complete tasks, including retries, failed runs, test environments and human review. Compare savings without weakening checks.
- Count failed attempts
- Include human effort
-
Measuring a factory honestly
Compare similar work with and without a software factory, counting review, rework and quality alongside speed. Avoid rewarding code volume over useful changes.
- Compare similar work
- Read speed with quality
-
Who owns the factory
Decide who maintains the agent tools, answers questions and handles failures. Match support hours and the manual fallback to how teams use the factory.
- Who decides and responds
- A tested manual fallback