Builder's playbook
GitHub Copilot
Real software · real metrics
223 Pull Requests
in 11 Days
The recipe for building real software with AI agents.
Drive a fleet of agents by day, a few deep plans by night. Merge the wins over coffee. ☕
Julien Dubois · github.com/jdubois · julien-dubois.com
GitHub
Microsoft
👋 Who am I?
- Principal Manager, Java Developer Relations @ Microsoft / GitHub
- Creator of JHipster · 22,000+ ⭐
- 200+ international talks (Devoxx, SpringOne, MS Build…)
- Today: shipping real projects by managing fleets of AI agents
💭 The project I never had time to build
I always wanted a real developer UI for Spring Boot.
🔭 The itch
- Every Spring app is a black box in development
- Actuator gives you raw JSON, not a console
- I wanted health, metrics, security and tracing in one embedded UI
🧱 The catch: it's massive
- ~40 panels, each = backend + frontend + tests
- Deep integration across a dozen JVM subsystems
- By hand, one experienced dev: 6.5–8.5 months
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. Too big to justify, until I stopped writing the code myself.
⚡ Then I did it in 11 days
223
pull requests merged
11
calendar days · v1 in < 2 weeks
~20
PRs merged per day
83k
lines of code shipped
The agents did the scaffolding, the panels and the tests. I did the judgement.
🖥️ What I built: BootUI
A production-grade Spring Boot 4 starter that adds an embedded, local-only developer console to your app.
🧩 Multi-module & deeply integrated
- 5-module Maven build · Spring Boot 4 / Java 17
- Actuator, Spring Security, Flyway/Liquibase, Hibernate
- Micrometer/OTLP, GraalVM, OSV scanning, ArchUnit
- Maven Central publishing · full CI
🎛️ ~40 feature panels
- An embedded Vue 3 SPA, packaged in the starter
- Each panel = endpoints + view + tests
- Health, metrics, security advisor, vulnerabilities, tracing…
- The biggest source of structural repetition
📐 The measured facts · v1.0.0
Derived from git history, PR metadata and code metrics, not time-tracking logs.
~264
commits on main
~223
squash-merged PRs (to #239)
~50k
Java lines · ~461 files · ~81 test classes
~52
Vue components · ~40 panels · ~35 e2e specs
~83k
total tracked source lines
~116
test suites (~81 Java + ~35 Playwright)
~5,800
doc lines + a VuePress site
5
Maven modules · 1.0.0 released
👥 One human driver + the Copilot agent (~44 commits), with dependabot, github-actions & one collaborator.
Part 01 · The proof
01
Does it really count?
11 days of agents vs. the honest by-hand estimate.
✅ With AI: the bottom line
Built through a tagged 1.0.0 release by one developer driving the GitHub Copilot coding agent.
~11 days
calendar time, to 1.0.0
~80–110 h
actual human hands-on effort · ≈ 2 intense solo weeks
~20 / day
merged PRs · ~223 in ~11 days
🔍 With AI: the evidence
📈 Velocity
- ~223 merged PRs / ~10.8 days (~264 commits)
- Commit clock runs ~05:00 → midnight most days
- Consistent with parallel async tasks, not continuous typing
🤖 Authorship pattern
- "Copilot" is a named commit / PR author (~44 commits)
- Repo ships copilot-instructions.md + per-panel conventions
- The workflow was explicitly agent-oriented
🚢 Even on release day
- VuePress docs site + Overview scanner dashboard
- Token charts, a proxied-Hikari fix, a docs refactor
- Polish that is itself several days of solo work
🧭 Where the human time went
- Writing prompts, reviewing & merging ~223 PRs
- Resolving CI failures (Spring Boot 4, Flyway 11, OTLP)
- Review-and-orchestrate, not write-every-line
🛠️ Without AI: the honest estimate
One experienced Spring Boot + Vue developer, no AI codegen, through the same polished 1.0.0.
6.5–8.5
months of full-time work · ~28–36 weeks
~1,100–1,450
hours of hands-on effort
~40
feature panels = the dominant cost
🗂️ Without AI: where ~7 months goes
| Phase & work (single senior developer) | Est. time |
|---|---|
| Project setup & architecture: 5-module Maven, auto-config skeleton, panel framework, access filter | 1–1.5 wk |
| Frontend foundation: Vue 3 + Vite SPA, app shell, routing, packaged into the starter | 1.5–2 wk |
| Core "easy" panels (~15): Health, Metrics, Beans, Mappings, Loggers, Caches… (Actuator-backed) | 5–6 wk |
| Complex deep-integration panels (~20): Security chains, Pentesting, OSV, Hibernate/Flyway, GraalVM, OTLP, ArchUnit | 12–16 wk |
| Safety & security model: local-only enforcement, action gating, secret masking | 1–1.5 wk |
| Testing: ~81 Java test classes + ~35 Playwright e2e specs, by hand | 3–4 wk |
| CI/CD & release: build/CodeQL/release workflows, GPG signing, Maven Central | 1–1.5 wk |
| Documentation: ~5,800 lines + a published VuePress site | 2.5–3.5 wk |
| Integration, polish, Spring Boot 4 migration, 1.0.0 hardening & buffer | 2–3 wk |
| Total | ~28–36 wk ≈ 6.5–8.5 mo |
⚖️ The verdict: with vs. without AI
| Aspect | With AI (actual) | Without AI (estimated) |
|---|---|---|
| Calendar | ~11 days (to 1.0.0) | ~6.5–8.5 months |
| Human effort | ~80–110 hours | ~1,100–1,450 hours |
| Throughput | ~20 PRs/day, parallel | A few features/week, serial |
| Human's role | Architect + reviewer | Author of every line |
| 40 panels | Near-free to replicate | Repetitive, the biggest cost |
🧑✈️ The mindset shift
I didn't open my IDE. I wasn't the developer. I was the manager.
🧑✈️ You · the manager
🎛️ Panels
clone the ~40 feature panels
🔌 Integrations
the deep JVM subsystems
🎨 Frontend
the embedded Vue SPA
🏗️ CI & docs
release, tests, VuePress
Many agents in parallel. You brief, review, merge.
You don't type faster. You ship what used to take months.
Part 02 · The recipe
02
How to run it yourself
Six ingredients and one daily loop.
🗓️ The daily loop
⚡ most of the work: you, driving the fleet
9am11am2pm5pm7pm↻
☕ MergeLand last night's deep plans
Spec & launchBrief tasks, fan out the fleet
DriveReview, merge, re-task, live
DriveMost PRs land by evening
🌙 QueueA few deep plans for the night
↻ Repeat×~11 days → v1.0.0
Day: the engine
Hands-on all day: spec, launch, review, merge, re-task. Most of the ~20 PRs a day land right here.
Evening: hand off
Queue a few deep, long-running plans before you step away.
Night: the bonus
A handful of deep autonomous runs finish by morning. The minority, not the engine.
1
Ingredient
Write the specifications
📜 The house rules · AGENTS.md
- Set the conventions once: stack, build, test, style
- A copilot-instructions.md every agent reads first
- Per-panel conventions so 40 panels come out consistent
🎯 A spec per task
- What to build, where, what "done" looks like
- 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.
2
Ingredient
Build the test harness
✅ A build + test they can run
- One command runs compile, unit and e2e: green or red
- Agents verify their own work before opening a PR
- No tests = you can't trust the output
🛡️ CI is the trust layer
- ~116 test suites · ~81 Java + ~35 Playwright
- CodeQL + e2e gate every PR to main
- This is what lets you merge ~20 PRs/day safely
📏 The harness, in numbers
Ingredients 1 and 2, measured. Everything an agent reads, runs and has to satisfy before its code reaches main.
63
lines of always-on house rules copilot-instructions.md
6
path-scoped rule files 156 lines, glob-attached
2,083
lines of CI 8 workflows · 121 steps
641
test files 536 Java · 105 Playwright
📋 Keep the always-on file short
- Static — 63 lines sent on every call. You pay for it every time, so it stays short
- Dynamic — 6 rule files attach only when their glob matches. Quarkus rules never load for a Vue change
📐 Put the detail in the spec
- 2,670 lines in SPECIFICATION.md — the behaviour contract
- ~13,700 doc lines total, reviewed in PRs exactly like code
~220 lines of instructions steer 2,083 lines of CI and 641 test files. Context is a budget, not a document.
3
Ingredient
Split the work, run agents in parallel
🧩 Make it parallel-ready
- ~40 near-identical panels = perfect to fan out
- One task per agent: small scope, clear goal
- One branch / worktree each, no collisions
🚀 A fleet, not one chat
- GitHub Copilot App: many agents live on one machine
- Mobile app: agents in Docker containers, on the go
- Your throughput isn't your keyboard. It's your briefs.
The whole point is parallelism. Don't babysit one agent. Run ten.
5
Ingredient
Merge the results over coffee
☕ First thing, over coffee
- Triage the few deep overnight PRs
- Merge the green ones fast
- Drop or re-task what didn't land
- Cherry-pick the good parts of the rest
- Then start driving the day's fleet
🔎 Review is the real bottleneck
It's not the typing anymore. It's the merging. Make review a fast, trusted ritual you run all day, not a line-by-line slog.
6
Ingredient
Pick the right model for the task
🧠 Workhorse
GPT-5.5 Extra-High reasoning handles most of the work, ~90% of tokens served from cache.
🎯 The tricky parts
Claude Opus 4.8 and Gemini 3.1 Pro. Three strong models, cross-checking each other to find the best fix.
⚡ The easy stuff
A smaller model or "Auto" mode for simple, mechanical tasks. Fast and cheap.
💰 The whole bill
~2.7B
total tokens
~95%
served from cache
120M
fresh input · 15M output
~$2,000
total cost
🐙 You don't have to build this loop
Every ingredient above is something the platform already does. The agent is one step in a chain it never leaves — so nothing gets glued together by hand.
🎫 The brief lives with the code
- Issues and a board carry the spec, labels and acceptance criteria
- Assign one to an agent — no copy-paste into a chat window
⚙️ The gate runs itself
- 11 checks per PR: build, tests, CodeQL, cross-platform, JDK matrix
- Agent code is judged by the same gates as mine
☁️ The laptop is optional
- Assign an issue from the mobile app, get a PR back
- It provisions its own environment, works on a branch, opens the PR
🧨 Why the multiplier was so large
This codebase is unusually well-suited to AI, for three reasons. Not every project gets 17–23×.
🔁 Massive repetition
~40 structurally similar panels an agent clones cheaply. By hand, that's the most expensive part.
🔌 Broad-but-shallow
Many Spring subsystems, each shallow. By hand, the cost is mostly looking things up, exactly what the agent absorbs.
🛡️ Strong guardrails
Multi-module CI, CodeQL, e2e and explicit instructions let the human safely accept high throughput.
⚠️ Watch out for
Scope creep
"Build the whole thing" makes an agent wander.
Fix: one tight goal per task.
Fix: one tight goal per task.
No tests, no trust
You can't read every line of 223 PRs.
Fix: harness first, green build before merge.
Fix: harness first, green build before merge.
Giant PRs & review fatigue
A 2,000-line PR is impossible to review well.
Fix: small, reviewable chunks; pace yourself.
Fix: small, reviewable chunks; pace yourself.
Wrong model
A weak model fails the hard tasks; a strong one is slow and costly.
Fix: match the model to the job.
Fix: match the model to the job.
Most failed runs aren't the agent's fault. They're a briefing problem.
📋 The one-page recipe
1Write the specifications (AGENTS.md + a spec per task) before you start a single agent.
2No agent without a test harness: a build + test it can run and pass itself.
3One task per agent. Small scope, clear goal, its own branch.
4Run them in parallel and drive a fleet you steer all day, not one chat window.
5Let a few deep plans run overnight. The bonus shift, not the engine.
6Merge as you go: triage fast, merge wins, drop or re-task the rest.
7Pick the right model per task; save what works as reusable instructions.
If there's one slide to screenshot, this is it.
💰 Pay now or pay later
~$2,000 of tokens across the sprint — about $9 per merged PR. That's the cheap part. The real question is when you pay for the code.
🎲 Vibe coding — low up front
- No specs, no harness: you start shipping immediately
- You pay in retry loops, and again six months later reverse-engineering code nobody understands
- That's the maintenance tax — invisible on day one
🏗️ Agentic engineering — pay first
- Specs, tests and CI cost you real days before the first agent runs
- They're what makes the tokens land first time, not on the fourth attempt
- The harness is cheap to write and expensive to skip
One more thing…
BootUI isn't just my case study
The recipe was the point, but it left behind a real tool. If you write Java, you should be running it: one dependency, zero configuration, then open /bootui.
🔎 See inside your app
- ~67 panels: HTTP routes, beans, config, caches, JPA & SQL trace, Kafka/JMS, tracing
- Everything Actuator exposes, but as a UI you'd actually want to look at
🩺 Advisors that tell you what's wrong
- Security, performance, Hibernate, REST, architecture, pentest, GraalVM & CRaC readiness
- Live CVE checks against the OSV feed for your actual dependency tree
🤖 And it makes your agents smarter
- A local MCP server: Copilot can read your app's real runtime state while fixing it
- Spring Boot (MVC & WebFlux) and Quarkus · local-only, never in production
<!-- that's the whole install -->
<dependency>
<groupId>com.julien-dubois.bootui</groupId>
<artifactId>bootui-spring-boot-starter</artifactId>
<version>1.14.1</version>
</dependency>
That's the recipe.
Now go build. 🚀
Drive by day · a few deep plans by night · merge as you go.
Write the specs, give them tests, run them wide, and ship what used to take months.
🌐 julien-dubois.com · 𝕏 @juliendubois · 🐙 github.com/jdubois · 📦 github.com/jdubois/boot-ui