Large legacy codebases are where single-shot AI tools break down. Throw a million tokens at one model and it overflows its context window, conflates files it half-remembers, and starts hallucinating APIs that were never there. Nexus Factory takes a different approach: a multi-agent architecture on AWS Bedrock AgentCore that decomposes the work modularly and runs a simulated team of about ten agents in parallel, with independent review that prevents hallucination.
The core message
Instead of throwing a million tokens at one model, Nexus Factory runs a multi-agent architecture. A cloud planner and orchestrator on AWS Bedrock AgentCore decomposes the work modularly and dispatches many specialized agents in parallel, simulating a development team of roughly ten agents rather than one person driving a single coding assistant.
Three ideas make it work:
- Modular decomposition. The planner splits a legacy codebase into bounded modules (per-directory or per-subsystem). Each agent sees only its slice, so the work always fits in context.
- Independent review. A three-reviewer arena (security, correctness, and style) plus a Judge verifies each slice against the real source before anything merges.
- No hallucination. Small bounded tasks combined with multi-reviewer verification against the actual code beat one giant context window that overflows and conflates files.
System architecture
The pipeline, in one line:
Ticket → Planner (decompose) → Doc agents ×N (parallel) → Arena (3 reviewers + Judge) → Merger → PR
Everything runs in the customer’s own AWS account: Bedrock AgentCore for the agents, ECS Fargate for the orchestrator, Bedrock models, DynamoDB, S3, Cognito, and CloudFront. Code, data, and credentials never leave the environment.
The agent pipeline
Left to right, the roles are:
Reactor (orchestrator) → Planner → 3 to 4 Code/Doc agents in parallel → Review agents (a three-reviewer Task Arena that documents its findings, plus a Judge that synthesizes the verdict) → Merge agent → Reporting agent (writes the docs and checks them into GitHub).
The Judge can send a task back to the coders (“needs changes”) before anything merges, so quality gates are enforced rather than assumed. For a look at how this pipeline behaves under real production conditions, see Hardening the Factory, a devlog covering graceful deploys, per-user GitHub publishing, and the diff viewer reviewers actually use.
Why this beats a single-agent assistant
| Single agent | Nexus Factory |
|---|---|
| Loads the whole codebase into one context window → overflow → forgets and conflates files → hallucinates → grades itself → runs serially. | Splits the codebase into bounded modular tasks → each agent sees only its slice → no hallucination pressure. |
Two more advantages come for free:
- Independent verification. A panel verifies each slice against the real source, and a Judge gates the merge. Nothing is self-graded.
- Parallel team. About ten agents run in parallel, a simulated dev team instead of one person working a prompt at a time.
Example output: a legacy iOS app
To show this on a real codebase, the factory auto-documented a legacy iOS application: a Swift 2.x-era, Parse-backed app full of Objective-C-flavored APIs. It had never seen the code before, and it produced a modular doc set.
| Doc | Covers |
|---|---|
UTIL.md |
Data-access service (data access plus shared state) and a transition delegate |
APP_ENTRY.md |
Entry point, Objective-C bridging header, Info.plist, storyboards |
CONTROLLER.md |
View-controller layer plus navigation |
COMPONENT.md |
Reusable table-view cell components plus xib layouts |
DOMAIN.md |
Parse-backed model types |
OVERVIEW.md |
High-level architecture plus end-to-end data flow |
README.md |
Index linking all module docs |
Verified cadence: the six core module docs were produced in about thirteen minutes, each by a separate agent run. That is a direct demonstration of modular, parallel decomposition (one bounded task per module prevents hallucination), not one giant single-shot pass.
Sample: a factory-generated overview
A short excerpt from the auto-generated OVERVIEW.md shows the kind of output the factory produces:
A high-level overview of the app: what it does, how the source is organized, how modules fit together, the end-to-end data flow from launch through the backend into the UI, and the dependency landscape (including third-party CocoaPods). It is the top-level companion to the module docs, cross-referenced throughout.
Language/era note: Swift 2.x era. Old-style Objective-C-flavored signatures (
application(_:didFinishLaunchingWithOptions:)with[NSObject: AnyObject],UIInterfaceOrientationMask.Portrait,dispatch_async,findObjectsInBackgroundWithBlock). Everything underPods/is excluded.
From a codebase it had never seen, the factory correctly identified the app’s era, its language quirks, its dependency landscape, and its purpose. That is exactly the legacy-documentation use case these teams need.
Why AllCode and Nexus Factory
- Runs in your own AWS account. Code, data, and credentials never leave your environment.
- AWS-native. Bedrock AgentCore for agents, ECS Fargate for the orchestrator, Bedrock models (the Claude family), DynamoDB, S3, Cognito, and CloudFront.
- Auditable. Every agent decision, tool call, and file change is logged, which is friendly to regulated industries.
- Legacy-friendly. Built for large, old codebases (Swift, Objective-C, and the like) where single-shot LLMs fail.
AllCode is an AWS Advanced Consulting Partner with AI Competency and an Anthropic Claude Code partner.
Related reading
- Hardening the Factory: a week inside the Reactor, Planner, and Task Arena that run this pipeline
- AllCode Launches Nexus: enterprise governance for AI coding tools
- Nexus Factory product site and live demo
Learn more at allcode.com, see AllCode’s AI Assessment for a scoped engagement, or reach out at [email protected].