From 15 Agents to One User

From 15 Agents to One User

November 21–24

Four days. Fifteen simultaneous AI sessions. Eight agents. A complete security epic. Frantic alpha preparation. One infrastructure crisis. And finally, one real user logging in for the first time.

This is the story of building toward a moment that matters — when all the systematic work, all the coordination, all the methodology gets tested by a single person trying to use what you’ve built.

Her name is Michelle. She’s a PM colleague, sharp and experienced. She agreed to be my first alpha tester, well aside from me ( user 0000001 in the system, username “alfrick.”) When she logged in on Monday afternoon, the user menu didn’t appear.

That bug — a simple cookie authentication issue — taught me more about what “production-ready” actually means than the entire week of preparation that preceded it.

Execution at scale

The week started with fifteen simultaneous sessions. Eight agents working across five workstreams. A security sprint that had been estimated at 2–3 weeks, executing in parallel with quick wins and infrastructure improvements.

I told my Lead Developer that morning: “Fix P0 immediately, start Phase 1 right now.” No planning meetings. No specification refinements. The security vulnerability — three methods that could expose cross-user file access — would be fixed before dinner.

By evening, the P0 was sealed. Nine database tables had owner_id foreign keys. The service layer was 68% through its security updates. Coordination had broken twice — role confusion after a context compaction, out-of-scope commits that nearly introduced breaking changes — and recovered both times within minutes.

The fifteen-agent day proved something important: systematic methodology scales. Not perfectly — coordination broke. But fast recovery meant velocity gains dominated coordination costs. Structure enabled both prevention and recovery.

But fifteen agents don’t use your software. Users do.

The epic that wasn’t

Friday morning, I expected another multi-day push on SEC-RBAC. The security sprint had Phase 1.3 (endpoint protection), Phase 1.4 (shared resource access), Phase 2 (role-based permissions), and Phase 3 (admin and testing) remaining. Conservative estimate: another week of work.

What happened instead: SEC-RBAC Phases 1–3 completed in approximately eight hours.

Nobody worked heroically. Systematic preparation had front-loaded the hard work. Phase 0’s security audit had mapped every endpoint and service method. Architecture decisions were already made (ADR-044: Lightweight RBAC via JSONB). Patterns were established. The completion matrix was explicit.

When execution day arrived, there was nothing left to figure out. Just work to do.

The breakthrough moment came mid-morning when my Code agent autonomously discovered its next prompt. I’d said “there’s a new prompt for Phase 1.4” and the agent found it via naming convention, validated prerequisites, executed the work, created a completion report. PM coordination overhead: zero minutes.

By early afternoon, role-based permissions were fully implemented. A complete permission matrix: Owner, Admin, Editor, Viewer roles with appropriate access to read, update, delete, share, and modify permissions. Twenty-four test cases validating the matrix. Forty-five percent ahead of schedule.

The other surprise: institutional memory repair. While security work progressed, a documentation agent discovered that my November 19 omnibus log was defective — 450 lines documenting one session when nine parallel sessions had actually occurred. Two hours of reconstruction recovered 95% of missing institutional memory.

Documentation can fail silently, just like code. Measurement systems can hide problems while reporting success. I’d learned that lesson with the shadow package hiding 617 tests. Now I was learning it about my own documentation practices.

Frantic preparation

Michelle was arriving Monday. The system was “architecturally ready for alpha users” according to my Chief Architect’s assessment. But architecturally ready isn’t the same as actually ready.

Saturday became a race against the clock. Frontend RBAC awareness — making the UI understand the permission system we’d built — was estimated at 6–7 hours. Navigation had fourteen known issues. Alpha documentation was outdated.

I deployed a Code agent to build the frontend, went to have coffee and do the crossword with my wife.

Fifty-four minutes later, the agent had finished.

Not 6–7 hours. Fifty-four minutes. Three new pages — Lists, Todos, Projects — with full CRUD operations and sharing UI. Permission-aware buttons. Role badges. Responsive design. Fifty-four minutes.

The pattern repeated throughout the day. Navigation fixes estimated at 340–395 minutes completed in 114 minutes. Three high-priority bugs fixed in five minutes instead of thirty-five. Investigation time investment paying off 3–7x in implementation speed.

By evening, the system was declared “production-ready for first alpha tester.” All UI features working. SEC-RBAC complete. Fourteen navigation issues fixed. Documentation current and accurate.

I went to bed nervous anyway.

The infrastructure crisis

4:42 AM. I couldn’t sleep. Might as well start production deployment.

The deployment revealed an API compatibility bug — LLM client wasn’t passing system parameters correctly. Fixed in minutes, but the kind of thing that makes you wonder what else is lurking.

Then my Special Assignments agent ran the weekly doc sweep and notied we an infrastructure quality issue. The trigger was web/app.py crossing 1,000 lines. The investigation revealed the real problem: it was up to 1,405 lines now, sure, but a third of that was one 518-line function.

Five hundred eighteen lines. In one function. The lifespan() function that handles application startup. Impossible to test. Fragile. Violating every principle of good architecture.

My Chief Architect’s assessment: “CRITICAL — Refactor before adding features.”

This was Sunday morning. Michelle was arriving Monday afternoon.

The smart thing might have been to defer. Ship what we had. Fix the architecture later. But “later” has a way of becoming “never,” and technical debt has a way of compounding exactly when you can least afford it.

I approved the refactoring. An hour later: 1,405 lines reduced to 263 lines. Eighty-one percent reduction. The 518-line function became 28 lines. Seven new well-organized modules. Testable architecture throughout.

By mid-morning, I had a significantly better codebase and a dentist appointment. Human life continues during software crises.

Michelle arrives

5:30 PM Monday. Michelle’s onboarding session begins. Hilarity ensues. Seriously, I was pretty nervous. This was the moment of truth. Michelle was great: patient, cheerful, totally game.

Account creation: works. Email verification: works. Login: works.

User menu: doesn’t appear.

She’s logged in. The system knows who she is. But the UI doesn’t show her user menu because… the authentication middleware doesn’t read cookies.

The login endpoint correctly sets a JWT in an httpOnly cookie. The middleware correctly validates JWTs. But the middleware only looks for tokens in the Authorization header and query parameters. Not cookies. So the UI routes — which authenticate via cookie — couldn’t identify the user.

All that preparation. Fifteen agents. Eight hours of security work. Eighty-one percent infrastructure reduction. And the bug that blocked my first alpha user was: we forgot to read cookies.

Thirty minutes later, the fix was deployed. Cookie extraction added to the middleware. I sent Michelle an email asking her to pull the production branch and try logging in again. We’ll pick this up in our next session.

For the want of a cookie

The cookie bug was humbling in the best way.

We’d built sophisticated security architecture. Role-based permissions with viewer, editor, admin roles. Cross-user access controls. Defense-in-depth validation. Twenty-four test cases for the permission matrix.

The bug that actually blocked our first user had nothing to do with any of that. It was a simple oversight in how we extracted authentication tokens. Not a complex architectural issue. Not a subtle security flaw. Just: we didn’t read cookies.

This is why real users matter more than any amount of systematic preparation. Not because systematic preparation is wrong — without it, we’d have had dozens of bugs instead of one. But because systematic preparation is necessary, not sufficient. Real users find the gaps that systematic thinking misses.

I created Issue #396: “Michelle Onboarding Session — Bug Fixes & UX Improvements.” Seven bugs discovered. Three improvements identified. The first real external feedback, captured systematically, ready for action.

The ratio that matters

Here’s what the four days taught me about systematic building:

Preparation compounds. The SEC-RBAC epic took 8 hours instead of 2–3 weeks because Phase 0 had already done the hard thinking. Frontend work that estimated 6–7 hours took 54 minutes because patterns were established and the agent had full context. Investigation time pays off 3–7x in implementation speed.

Coordination enables scale. Fifteen sessions coordinated through structure, not heroics. When coordination broke, recovery protocols fixed it. The 26% velocity improvement across 45 days came from coordinating better, not working harder.

Real users reveal truth. All the systematic work created a foundation. Michelle’s cookie bug revealed what was actually missing. Both matter. Neither alone is sufficient.

Structure scales; heroics don’t. We didn’t finish the security epic through brilliance or late nights. We finished it by having explicit completion criteria, established patterns, and clear scope boundaries. Methodology enables execution to match ambition.

The journey from fifteen agents to one user isn’t about the agents or the user. It’s about building systems that can handle both — the scale of parallel execution and the specificity of individual human needs.

Michelle get set up and logged in. User 0000002. Authentication still buggy but she can see Piper.

That’s what production-ready actually means: ready for real people to find what you missed.