What 1.04 Million Lines Taught Us About Parallel AI Development

We created the current PentaTrail repository on July 27, 2025. The first commit was a multi-tenant SaaS foundation using Supabase and Vercel. Since then, the same monorepo has grown to include web applications, ASM components, databases, Edge Functions, billing, audit controls, and ISMS-related work.

On August 29, 2026, we fetched the complete history and measured it again. After excluding externally sourced scanning templates and machine-produced collection data, our own codebase contained 1,040,063 lines of code, excluding blank lines and comments. The repository had 1,646 pull requests, of which 1,451 had been merged.

At this scale, whether AI can write code is no longer the main engineering question for us. The harder question is how to keep multiple AI workers operating safely on the same repository.

Code production is still accelerating

We began using pull requests as the normal unit of development around March 2026. Before that point, the repository had only 56 PRs. From March through August 29, we created 1,590 PRs and merged 1,399.

In August alone, 410 PRs had been merged by the 29th. Over the latest 30 days, 433 were merged, or 14.4 per day. The median PR added 342 lines; the 75th percentile was 1,649 lines. The count is not primarily a result of splitting trivial edits into separate PRs.

The 1.04 million lines currently present are only part of the history. Across the repository's lifetime, we added roughly 2.53 million in-house lines and deleted about 1.10 million. Product code alone saw about 835,000 lines added and 506,000 removed. AI-generated work has been repeatedly replaced and refactored rather than simply accumulated.

Table 1: Pull-request flow since March 2026

Over these six months, producing code became much faster. Running several Claude Code sessions at once, however, introduced a different kind of waiting.

Two AI workers create an ownership problem

With one AI working on one issue, the workflow still resembles conventional development: read the issue, implement it, test it, and open a PR.

With several Claude Code sessions, two sessions may select the same issue. Different issues may both modify authentication code or the same database objects. Work that has not yet become a PR is not visible in GitHub's PR list, so the collision can remain invisible until later.

A failed session creates another ambiguity. A claim may still say that work is in progress even though the process that owned it is gone. If another worker resumes the work while the original process is actually still alive, the same change can be implemented twice.

A small human team resolves many of these cases by saying, "I'm working on that." Parallel AI workers need that conversation represented explicitly.

Our Issue Loop therefore tracks run identity, issue claims, resources being held, and whether the owning run is still alive. It distinguishes the current run, another live run, and a dead run so that only abandoned work can be recovered. We are also moving collision detection earlier, before two changes become competing PRs.

For a CISO, this looks less like a question of model intelligence and more like change control. If the number of actors modifying a system increases, the ability to identify who owns each active change has to increase with it.

Claude implements; Codex provides another set of eyes

Claude Code performs implementation, and we also have Codex inspect changes. Asking the same AI to reconsider its own implementation can preserve the assumptions that caused the original error.

We have seen an independent review find an important issue after several earlier review rounds had missed it. But more review does not mean every change can proceed automatically.

Authorization, data-retention, and migration changes can leave design decisions even when CI is green. A fix can break another contract and require another pass. We still need to distinguish changes that can advance on mechanical evidence from changes that require human judgment.

This extends the approach described in our Claude and Codex dual-AI review article. What parallel development added was another requirement: review is not enough unless we also control the order in which independently produced changes return to a shared branch.

The step after six workers is not automatically 24 workers

Our current environment runs six Claude Code sessions in parallel: four on an office desktop and two on a home laptop. Memory is the main physical constraint on that worker count, so a server with substantially more RAM could raise it.

That does not guarantee a continuous supply of six independent pieces of safe work.

If one issue changes shared authentication logic while another changes the same database objects, spare workers do not make those tasks independent. Six PRs can be produced in parallel, but once one is merged into the development branch, the others are based on an older state. Some need to incorporate the change, rerun tests, and in higher-risk cases go through review again.

Implementation can be parallelized much more aggressively than integration into a shared codebase.

For that reason, the metrics we want next are not primarily CPU utilization. We want worker idle time, claim and path collisions, time from PR creation to merge, and the number of times work stops for a human decision. Adding 12 or 24 workers while those queues are blocked would mostly add more waiting workers.

The next bottleneck is creating the work itself

Once the Issue Loop becomes reliable, another human task remains: deciding what should be built, decomposing it into implementable work, and ordering the dependencies.

We currently call the layer we want above the Issue Loop the Project Loop. A person provides a product objective or problem. The Project Loop inspects the repository and existing issues, decomposes the objective into implementation units, and sends work that can safely proceed in parallel to the Issue Loop. Below that layer, Claude Code implements changes while Codex or another independent model and CI provide verification.

It is not finished.

Starting 24 Claude sessions is easier than keeping six sessions productive for weeks without running out of useful work, corrupting each other's changes, or allowing unsafe changes through. After 1.04 million lines of development, the bottleneck in AI-native software engineering is beginning to move away from code generation and toward the control system around it.

• Securing AI-written code: how we design review
• Claude and Codex dual-AI review
• Long-running AI development: context limits and memory operations
• Development articles