Deep Engineering #55: Julien Dubois on Managing a Fleet of Agents to Ship in Days
On building a production Spring Boot console in 11 days, plus why an 80% demo is not a production system.
Capacitor - Shared memory for your team’s coding agents. Searchable. Shareable. Vendor-neutral. Scored.
Capacitor records the session behind the work: what agents tried, what teammates rejected, what finally passed, and why it mattered. This gives you vendor-neutrality to move across multiple coding agents, multiplayer - collaboration on coding sessions, faster PR reviews, evals on code & more.
✍️ From the editor’s desk,
Welcome to the 55th issue of Deep Engineering!
OpenAI made its GPT-5.6 family generally available on July 9 across ChatGPT, Codex, and the API. The capability that matters here is a new ultra mode that runs concurrent subagents and synthesizes their work in a single request. This release also makes cached context far cheaper than fresh input, since cache reads keep the 90% cached-input discount. So running a fleet of agents in parallel, and paying almost nothing to reuse their context, has moved from a hand-built trick into something the platform now does by default.
That shift is why this issue matters now. When the tooling makes parallel agents this easy, the differentiator stops being model access and becomes the discipline around it, the specifications, the tests, and the review that decide whether all that speed produces software you can actually ship. Last week Julien Dubois led a workshop for us, From Coder to Manager of Agents, where he showed how he built a real open-source product this way, measured from git history rather than memory, which makes it far more useful than another benchmark thread.
Julien is Principal Manager for Developer Relations at Microsoft and GitHub, and the creator of JHipster.
Let’s get started.
Featured: Loop Engineering for AI Agents
Stop wasting tokens on endless retries. This four-hour, hands-on workshop takes you past one-off prompting to reliable agent loops that plan, execute, verify, and stop safely, built with Claude Code, Spec-Driven Development, and MCP, with the verification gates and state management that keep autonomous agents trustworthy.
Deep Engineering readers save 40% with code DEEPENG40.
Practitioner's View by Julien Dubois
223 pull requests in 11 days for the project I never had time to build
You can read this practical deep dive based on his workshop. And here are the slides from the talk.
I always wanted a real developer UI for Spring Boot. Every Spring app is a black box in development. Actuator gives you raw JSON, not a console, so what I wanted was health, metrics, security and tracing in one embedded UI.
I’d shipped a slice of this in JHipster years ago, but only for generated apps. A real console for any Spring Boot app sat on my wishlist for years. The catch is that it’s massive. Around 40 panels, each one a backend plus a frontend plus its own tests, deeply integrated across a dozen JVM subsystems. By hand, one experienced developer would need somewhere between six and a half and eight and a half months. Too big to justify, until I stopped writing the code myself.
Then I did it in 11 days. Not by typing faster. I didn’t even open my IDE. I managed a fleet of AI agents while I architected, reviewed and steered. The agents did the scaffolding, the panels and the tests. I did the judgement.
What I built, BootUI
BootUI is a production-grade Spring Boot 4 starter that adds an embedded, local-only developer console to your app. You add one starter to your pom.xml, run locally, and open the console.
It is a five-module Maven build on Spring Boot 4 and Java 17, integrated across Actuator, Spring Security, Flyway and Liquibase, Hibernate, Micrometer with OTLP, GraalVM, OSV scanning and ArchUnit, published to Maven Central with full CI. The frontend is an embedded Vue 3 single-page app, packaged inside the starter. Each panel is endpoints plus a view plus tests.
There are around 40 feature panels. Health and metrics, a security advisor, a vulnerabilities view, tracing, and more. Those panels look a lot alike, which made them the biggest source of structural repetition in the codebase. That detail matters, and I will come back to why it made the whole thing work.
Eleven days, and how I know the numbers are real
The figures here are derived from git history, PR metadata and code metrics, not from time-tracking logs. Through the tagged 1.0.0 release there were around 264 commits on main and about 223 squash-merged pull requests, landing at roughly 20 a day across 11 days. That came to about 83k total tracked source lines, close to 50k of them Java across around 461 files and 81 test classes, plus 52 Vue components, 40 panels, and 35 end-to-end specs. In all, about 116 test suites.
A cadence of 20 PRs a day with an AI agent co-authoring commits is impossible to reach by hand. The agent did the typing. I dispatched many asynchronous tasks in parallel. The evidence lines up with that. The commit clock runs from around five in the morning to midnight most days, which is consistent with parallel async tasks rather than continuous typing. “Copilot” shows up as a named commit and PR author on about 44 commits, and the repo ships a copilot-instructions.md with per-panel conventions, so the workflow was explicitly agent-oriented. Even on release day I was landing a docs site, a scanner dashboard, token charts and a Hikari fix, which is itself several days of solo work.
Where my own time went was writing prompts, reviewing and merging those 223 PRs, and resolving CI failures around Spring Boot 4, Flyway 11 and OTLP. Review and orchestrate, not write every line.
The honest by-hand comparison is the part people argue about, so I ran it carefully. One experienced Spring Boot and Vue developer, with no AI codegen, would need 6.5 to 8.5 months for the same polished 1.0.0, roughly 1,100 to 1,450 hours of hands-on effort, and the 40 panels are the dominant cost. A COCOMO organic estimate on 50k lines yields more than 100 person-months, which is too high because much of the code is repetitive scaffolding, so a domain-expert solo figure of about 7.5 months is the defensible middle ground. My actual human effort on BootUI was 80 to 110 hours, about two intense solo weeks. That is a calendar speed-up of roughly 17 to 23 times, and a human-hours speed-up of roughly 12 to 17 times.
I was the manager, not the developer
I didn’t open my IDE. I wasn’t the developer. I was the manager. Many agents ran in parallel on the panels, the integrations, the frontend, and the CI and docs, and my job was to brief, review and merge.
Your throughput is not your keyboard. It is your briefs. What blocks a single developer is typing, and what blocks a single agent is you waiting for it to finish. Running many at once removes both, because they come back one after another and there is always something to review. You don’t type faster this way. You ship what used to take months.
A day in the loop
The rhythm that produced 20 merged PRs a day is a simple daily loop, and the day is the engine. I am hands-on all day. I spec, launch, review, merge and re-task, live, and most of the day’s PRs land right there.
The evening is a hand-off. Before I step away I queue a few deep, long-running plans. The night is a bonus, not the engine. A handful of deep autonomous runs finish by morning, which is the minority of the work. Repeat that for about 11 days and you reach a tagged 1.0.0. Six ingredients make the loop work.
Ingredient one, write the specifications
The first thing I write is never code. It is the house rules. An AGENTS.md, which GitHub Copilot reads as copilot-instructions.md, and every agent reads it first. It sets the conventions once, the stack, the build, the tests and the style, with per-panel conventions so 40 panels come out consistent. Mine runs around 700 lines. That is about the right size, because a file that is too big pollutes the context, and it also costs tokens and money on every run.
The high-leverage move is writing the known failures into that file once. Most models were trained on Spring Boot 3, so they struggle with the reworked Jackson API in Spring Boot 4, and 10 agents trained on the same data hit the same wall at the same time. Rather than fix that by hand in each one, I write the fix down once. The same goes for operational traps, like giving every agent its own local Maven repository so parallel installs do not corrupt a shared one.
On top of the house rules I write one spec per task. What to build, where, what “done” looks like, and the acceptance test the agent must make pass. Small, self-contained, no hidden dependencies. The spec is the product now. The better the brief, the less you babysit.
Ingredient two, build the test harness
No agent runs without a test harness. One command compiles and runs the unit and end-to-end tests, and comes back green or red, so an agent can verify its own work before it opens a PR. No tests means you cannot trust the output.
CI is the trust layer. BootUI has about 116 test suites, 81 in Java and 35 in Playwright, and CodeQL plus the end-to-end tests gate every PR to main. The loop does the work. An agent writes code, pushes it, and GitHub Actions sends back the results. If they are red the agent reads the failure, fixes it, commits and pushes again, and the checks run once more. Dependabot keeps the dependencies current alongside all of this. A compiled, typed language like Java helps too, because a hallucinated call often fails to compile before a test ever runs, and the tests catch what the compiler misses. You cannot read every line of 223 PRs. A green build you trust is what makes the volume reviewable.
The rest of the deep dive covers the other four ingredients, the test harness and CI as the trust layer, running agents in parallel across worktrees, the overnight critic-and-vote runs, merging as the real bottleneck, and the cache math behind the roughly two thousand dollar bill, along with where the multiplier will not repeat.
Industry Perspective
So Your Demo Is Lying to You
Julien Dubois shows how a fleet of agents lets one engineer move at the pace of a team. Imran Ahmad takes up the question that speed raises, whether the software those agents produce can be trusted in production. He calls the distance between an eighty percent demo and a 99.9 percent production system the Reliability Gap, and he argues you close it with a deterministic shell around the model rather than with a better model. His piece walks the failures that make the case, from an invented refund to a deleted production database, and gives the four questions he now asks in every design review.
📣 Contribute to Deep Engineering
If you are a senior engineer with a hard-won lesson or a failure worth sharing, pitch a practical deep dive under your byline. Or if you lead a team, we would like to interview you and build an engineering leadership feature around your story.
Subscribe to Deep Engineering newsletter and message us through the chat option, or email us at saqibj @ packt.com.
🛠️ Tool of the Week
Composio’s Agent Orchestrator is an open-source take on exactly that job. It helps developers manage fleets of coding agents for parallel work, giving each one an isolated workspace and supervising them from one place.
Runs each agent in its own git worktree, so parallel work does not clobber shared files
Feeds CI failures, review comments, and merge conflicts back to the right agent automatically
Works with the terminal agents teams already use, including Claude Code, Codex, Cursor, and opencode
MIT licensed and self-hosted, run locally rather than as a hosted service
📎 Tech Briefs
Claude Code changelog - Agents must now confirm before entering a git worktree outside the project’s .claude/worktrees directory, and a new /doctor check flags checked-in CLAUDE.md content the model can derive from the codebase.
GitHub Copilot CLI changelog - Plan mode can no longer run tools that modify the workspace, and the default maximum sub-agent nesting depth drops from six to four to limit runaway recursive delegation.
Copilot for JetBrains expands BYOK capabilities - Adds local agent sandboxing, a Claude agent provider for custom agents and skills, and OpenAI-compatible custom endpoints, all in public preview.
Copilot in Visual Studio, June update - Visual Studio now checks each MCP server’s configuration and asset fingerprint against a trusted baseline at startup, and the C++ modernization agent reached general availability.
Claude Code gateway for teams - Anthropic shipped a self-hosted gateway for Claude Code, a stateless container that adds corporate SSO login, centrally enforced policy, role-based access, and per-user cost attribution across a team.
That’s all for today. Thank you for reading this issue of Deep Engineering.
We’ll be back next week with more expert-led content.
Keep building,
Saqib Jan
Editor-in-Chief, Deep Engineering
If your company wants to reach senior developers, software engineers, and technical decision-makers, speak to us about partnering with Deep Engineering.