# AI Software Factory

> AI software factory from Boltcliq: a repeatable, governed system in which AI coding agents plan, build, test and release software under human-set specifications, review gates, security controls and cost limits.

Canonical URL: https://www.boltcliq.com/solutions/ai-software-factory
Part of: https://www.boltcliq.com/llms.txt

A governed line where AI agents build, test and ship software and your engineers steer.
- An AI software factory is a system, not a tool. Agents do much of the building, and people keep control of what is asked for, what is allowed and what ships.
- Spec first: Intent is written down before agents write code
- Gated: Tests, security checks and named approvers on every change
- Sandboxed: Agents work in isolated environments with scoped access
- Metered: Agent spend and delivery results tracked together
### What we do
- Coding assistants made individual developers faster. They did not, on their own, make organizations faster. Public research on AI-assisted development, including the DORA programme, finds that AI acts as an amplifier: teams with strong practices gain, while weak review, testing and release habits are exposed. When code arrives faster than it can be reviewed, tested and operated, the bottleneck moves and quality can slip.
- An AI software factory is the answer to that shift. It is the full loop from a request to running software, with agents doing the planning, coding, testing and revising, and with the controls that keep the output safe: written specifications, shared context, isolated build environments, automated checks, human approval at the right points, and monitoring that feeds back into the next piece of work. Coding agents are parts of the factory. The factory is the line around them.
- We design and stand up that line with your engineering organization. We start with the software you need to produce and the rules it must meet, then build the context, pipelines, guardrails and operating model to match. Your engineers move from writing every change to setting intent, tuning the system and reviewing evidence. We do not promise that agents replace engineers. We help you decide how much autonomy each kind of work has earned.
### Not the same as an AI factory
- The terms sound alike and mean different things. An AI factory, in the sense used on our AI Factories page, is the compute, data and process that build and ship models and agents. An AI software factory uses agents to build ordinary software: applications, services, integrations and internal tools.
- The idea itself is old. Software factories were proposed in the 1960s and revisited in the 2000s as a way to build software from repeatable patterns. What is new is that agents can now do a large share of the work inside the line. Many organizations need both: a factory for intelligence and a factory for the software around it.
- AI factory: builds and serves models and agents
- AI software factory: agents build and ship software
- Shared foundations in data, compute and governance
### Capabilities
**Intake and specifications**
- We set up how work enters the line: requests are triaged, turned into written specifications with acceptance criteria, and linked to the business outcome they serve. Specifications are readable by people and by agents, and they become the contract that tests and reviews check against.
- Request triage and prioritisation
- Specifications with acceptance criteria
- Traceability from request to release
- Agents build what they are told, so the instruction is the product.
**Context and standards**
- Agents are only as good as what they know. We organise your repositories, architecture decisions, coding standards, domain definitions and runbooks into context agents can use, with permissions that limit what each agent can see. Standards are written as checks, not only as documents.
- Curated code and knowledge context
- Standards expressed as automated checks
- Per-agent and per-project permissions
- Good context is the difference between plausible code and correct code.
**Agent orchestration**
- We design the roles and hand-offs: planners, builders, testers, reviewers and release agents, each with a narrow task, clear inputs and a defined output. Work runs in parallel where it is independent and stops where a person must decide. We select models and tools by task and cost, and keep them swappable.
- Role-based agents with narrow tasks
- Parallel work with explicit stop points
- Model and tool choice by task and cost
- A defined process turns agent output from craft into production.
**Sandboxes and access control**
- Agents with credentials and network access are a security surface. We run agents in isolated environments with scoped, short-lived credentials, restricted network egress and logged tool use. Secrets never live in prompts or agent definitions, and access follows the same identity rules as people.
- Isolated build and test environments
- Scoped, short-lived credentials
- Controlled network egress
- An agent should never hold more access than the task needs.
**Quality and release gates**
- Every change meets automated tests, static analysis, dependency and secret scanning, and review before it can merge. We tier review by risk: automated gates for routine changes, named human approval for sensitive paths such as payments, identity and data access. Releases roll out in stages and can be rolled back.
- Tests, scanning and policy checks in CI
- Risk-tiered human review
- Staged rollout and rollback
- Review capacity, not typing speed, limits safe throughput.
**Observability and cost control**
- We measure the line itself: lead time, change failure rate, time to recover, review wait, defects that escaped and the cost of agent usage per change. Budgets and alerts stop runaway spend, and operational reviews on a fixed cadence decide where agents have earned more autonomy and where they have not.
- Delivery and quality metrics
- Agent spend per change and per team
- Regular reviews of autonomy levels
- Speed that is not measured against stability is a guess.
### Where it applies
- Banks and insurers
- A group has a long backlog of integrations and internal tools, and strict change control that makes every release slow.
- A factory produces changes with specifications, tests and evidence attached, so change boards review proof rather than start from scratch.
- Engineering and risk leaders set which change classes agents may prepare and who approves each class.
- Government and public sector
- Agencies need citizen-facing services and keep rebuilding similar forms, workflows and integrations.
- A shared factory builds services from common patterns and standards, inside the jurisdiction and under common security rules.
- Programme owners and counsel decide on data use, hosting and which services to build.
- Telecommunications
- An operator maintains many internal systems and customer apps, with a large engineering team stretched across them.
- Agents handle upgrades, test creation, documentation and routine fixes, with engineers reviewing the exceptions.
- Platform owners decide priorities and approve changes to network-facing systems.
- Startups and AI native companies
- A small founding team needs to ship a product quickly without piling up unmaintainable code.
- A lightweight factory gives the team specifications, tests, review and deployment from the first week, so speed does not erase quality.
- Founders decide what to build, what to buy and which risks to accept.
### Built on
**Argus**
- Provides isolated environments, sandboxes, storage and secrets for agents and pipelines, portable across providers.
- Boltcliq product
- A safe place for agents to work.
**Monolith**
- Governs agent context, memory and permissions, and holds the standards and approval rules that changes must meet.
- Boltcliq product
- Governance is part of the line.
**Cyclopes**
- Tracks delivery, quality, incidents and agent cost across every team and release.
- Boltcliq product
- Leaders see what the factory delivers.
### What we do and do not do
- Design the factory, its stages, roles and controls
- Set up specifications, context and sandboxes with your team
- Build test, security and release gates
- Measure delivery quality and agent cost
- Train and support the engineers who run it
- Promise that agents replace your engineers
- Merge or release code without the gates you set
- Give agents standing access to production data
- Lock you into one model or coding tool
- Own your code or run the factory for you indefinitely
### Questions we hear
- What is an AI software factory?
- It is a repeatable system in which AI agents plan, write, test and prepare software for release, while people set the intent, the rules and the approvals. Coding agents are components inside it. The factory is the whole loop and its controls.
- How is this different from AI Factories?
- AI Factories is about the compute, data and process that build and ship models and agents. An AI software factory is about using agents to build software. Many organizations need both, and they share data, platform and governance foundations.
- Will it replace our engineers?
- No. The work shifts. Engineers spend less time on routine changes and more on specifications, architecture, review and tuning the system. How far that goes depends on your risk, your codebase and your team.
- How do you keep quality and security under control?
- Through written specifications, automated tests and scanning, risk-tiered human review, isolated environments and scoped credentials. Research on AI-assisted development points to stability as the main risk, so we measure it from the start.
- Which models and tools do you use?
- We choose by task, cost and your constraints, and keep them swappable. Which options are available inside your country or cloud varies, so we confirm this early.