AI Code Auditor — Multi-Agent Engineering System
A design for a multi-agent system that analyses a repository the way a careful reviewer would: one agent maps the codebase, specialist agents assess quality, security and architecture, and an orchestrator merges their findings into a single report.
Problem statement
Problem statement
Thorough code audits are slow and depend on who is available. Static analysers find rule violations but do not explain architectural risk; a single LLM prompt cannot hold a whole repository or check its own claims.
Business challenge
Business challenge
Splitting the work across agents introduces its own problems: duplicated findings, contradictory conclusions, runaway cost, and claims that are not grounded in the actual code. The architecture has to control all four.
Solution architecture
- 01
An orchestrator plans the audit and assigns scoped tasks to specialist agents, each with a narrow role and limited tools.
- 02
A repository-mapping step builds a shared index (structure, dependencies, entry points) so agents work from the same facts.
- 03
Specialist agents must cite file paths and line ranges for every finding; uncited findings are discarded.
- 04
A synthesis step de-duplicates, ranks by severity and produces a report with a clear list of recommended changes.
01Input
Repository
Git URL or local checkout
02Shared context
Repo mapper
Structure, dependencies, entry points
Code index
Searchable files & symbols
03Orchestration
Orchestrator agent
Plans, assigns, enforces budgets
04Specialist agents
Quality agent
Complexity, duplication, tests
Security agent
Vulnerabilities, secrets, dependencies
Architecture agent
Boundaries, coupling, design risks
05Output
Synthesis
De-duplicate, verify citations, rank
Audit report
Findings + recommended changes
Workflow
- 1
Map
The repository is scanned and indexed so every agent shares the same picture of the code.
- 2
Plan
The orchestrator breaks the audit into scoped tasks with a token and time budget each.
- 3
Analyse
Specialist agents work in parallel, using search and static-analysis tools.
- 4
Ground
Each finding must reference real files and lines; unverifiable claims are dropped.
- 5
Synthesize
Findings are merged, de-duplicated and ranked by severity and effort.
- 6
Report
A structured report is produced, with developer-facing feedback per finding.
Technology stack
- Python
- LLM tool calling
- Agent orchestration
- AST / static analysis tools
- Git
- Markdown reporting
Implementation details
- Agents are given narrow roles and only the tools they need — a security agent has no reason to edit files.
- Deterministic tools (linters, dependency scanners, AST queries) do what they are good at; the LLM interprets and prioritizes.
- Budgets per agent keep cost bounded and prevent loops.
- The report format is designed for developers: what, where, why it matters, and what to change.
Engineering challenges
Grounding
LLMs will describe problems that are not in the code. Mandatory citations with verification is the main defence.
Context limits
A repository does not fit in a prompt. The shared index and scoped tasks let agents pull only what they need.
Signal over noise
An audit with 300 findings is useless. Ranking and de-duplication matter as much as detection.
Designed vs. proposed
Nothing here is presented as a shipped product. 'Designed' means the architecture and agent contracts are worked out in this case study; 'Proposed' means identified as a later phase. Implementation status will be updated when a public repository is available.
- Repository analysis and shared code index
- Agent orchestration with scoped tasks and budgets
- Code quality analysis agent
- Citation-based grounding of findings
- Automated report generation
- Security vulnerability detection with dependency scanning
- Architecture assessment across services
- Inline developer feedback on pull requests
- Evaluation harness against repositories with known issues
Business value and results
Business value
- A repeatable first-pass audit before a human review.
- Consistent coverage across quality, security and architecture.
- Findings that point at specific code instead of general advice.
Measured results
This is an architecture case study. No performance figures are claimed.
Screenshots, code and demo
Screenshots
Will be added as the implementation progresses.
Source code
Repository not yet public.
Live demo
No public demo. Ask for a walkthrough.
Have an AI or Data Engineering challenge? Let's turn it into a working product.
Taking on a limited number of AI and data engineering projects. Typical reply within 2 business days.