The 10×-everything chapter

Why this is the marquee week

Weeks 1 and 2 install the substrate (context-in-the-repo, compressed planning, transcription, browser automation, git, deploy-to-prod). All of that points in one direction: engineering velocity is about to go up significantly.

Engineering velocity going up alone is the most common way AI-native adoption fails. The premise of this week:

You can’t 10× engineering velocity alone. You have to 10× the testing, 10× the QA, 10× the monitoring, 10× the DevOps. Everything has to scale together. Otherwise you bottleneck on the lowest-multiplier function and lose all the gains.

Teams that don’t do this week’s work either: (a) keep shipping at the old velocity because their support functions cap it, or (b) ship at AI-native velocity and cause incidents that revert leadership’s appetite for the practice. Both are bootcamp-failure modes.

The 10×-everything spine

For every support function around engineering, the question is the same: what does this function look like at AI-native velocity, what skills does it need to install, and what’s its integration point with the engineering team that just doubled its PR output?

Six functions to think through. You don’t fix all of them this week — the assignment is to pick one and design its 10× upgrade. But you should leave the week with a clear map of where each one sits today.

1. Testing & QA — agent-driven release verification

The shift: no manual QA team gating releases. The QA function moves from "people who click through the app before we ship" to "people (or AI) who design the test surface that gives the engineering team confidence to ship themselves."

What scales:

• Automated e2e test coverage of the critical user paths, runnable by any agent on any PR, fast enough to gate merge.
• Agent-driven browser-automated smoke tests against staging on every release (the same browser automation muscle Week 2 installed).
• Visual regression where it matters (often less than engineers think).
• Performance / load testing as part of the deploy skill, not a separate quarterly exercise.

What the human QA role becomes: test surface designer, gap-finder, the person who notices what the automation isn’t catching. High judgement, low click-through. Often becomes a smaller team that’s more valuable per head.

The trap: teams that try to keep manual QA at the same headcount while engineering velocity 5×es. QA becomes the visible bottleneck. The right move is to invest the saved QA hours in the automation that scales, not in hiring more QA.

2. CI — auto-repair as default

At 5× PR volume, CI failures are no longer occasional events. They’re a steady stream. If every CI failure requires a human to investigate, fix, and re-push, CI becomes the bottleneck.

What scales:

• An agent that watches CI for the team. When a build fails, it opens a worktree, attempts a fix, pushes, monitors until green or until it decides the failure needs human input.
• Flaky-test detection and quarantine, automatically.
• Smart re-runs for transient failures (network blip, infra glitch) without engineers needing to know they happened.
• Surface only the real failures to humans — the ones where the agent couldn’t resolve, or where the failure indicates a real product bug.

The Team Ops sweep skill from AgentHerder Course Week 4 is the canonical pattern for this kind of meta-agent. Teams at running stage can borrow the pattern even before they go fully flying.

3. Monitoring & observability — agent-readable signal

Monitoring used to be "dashboards humans look at when something feels wrong." At AI-native velocity, it’s "structured signal agents and humans both consume."

What scales:

• Logs, metrics, and traces that an agent can read, cross-reference, and reason over.
• Alert thresholds tuned to your new baseline, not the pre-AI one. (Common failure: a 5×-bigger deploy stream alerts on a 2×-higher-than-normal rate — which is now normal.)
• Post-incident review where Claude summarises the timeline from log data, cross-references PRs that touched relevant code, drafts the postmortem before the team meeting.
• Runbooks as agent-executable skills, not Confluence pages nobody reads under pressure.

4. Security & compliance — agent-augmented review

Security functions are usually the most resistant to engineering-velocity scaling, and the most consequential when they bottleneck. A security review that takes a week per PR caps any AI-native velocity gain.

What scales:

• Automated security scanning on every PR (SAST, dep scanning, secret scanning) — output that an agent triages before a human security reviewer sees it.
• Threat-modelling as a skill the engineering team invokes during design, not after — with the security team reviewing the threat-model output, not re-doing the modelling.
• Compliance evidence collection automated. The audit artefacts (deployment logs, code review records, access logs) get pulled together by an agent into the form the auditor wants.
• Security team becomes high-judgement reviewers and threat-model curators, not bottleneck approvers on every PR.

This is often the hardest function to renegotiate inside an org. Security teams often have headcount-justified processes; changing those processes affects budgets. Plan for this to be a months-long conversation, not a Week 3 conversation. But start the conversation.

5. DevOps / SRE — infra as skills, not tickets

The traditional DevOps interface: engineers file a ticket, DevOps does the work, eventually. At AI-native velocity, this loop is far too slow.

What scales:

• Self-service infra via skills: the engineer needs a new staging environment, a new database, a new feature flag — they invoke a skill that does it. DevOps owns the skill, not the ticket queue.
• Deploy-to-prod as a single skill (Week 2’s work).
• Rollback as a skill, used regularly, not heroically.
• Cost monitoring as continuous, agent-summarised. The DevOps team gets a weekly "what changed in our spend" narrative, not a quarterly surprise.

DevOps team identity shifts from "the people who keep the lights on" to "the people whose skills the rest of engineering invokes." More leverage, less reactive.

6. On-call & incident response

The function most often forgotten in 10×-everything planning. If incidents 10× and on-call rotation stays the same size, your on-call engineers burn out and quit.

What scales:

• Agent triage as the first responder. When the page fires, an agent does the initial diagnosis — cross-references recent deploys, scans logs, narrows the candidate causes, proposes mitigation. The human on-call wakes up to a summary, not a cold incident.
• Runbooks executable by agents, so a 3 AM page that matches a known pattern can be mitigated by the agent before the human even joins the call.
• Post-incident review automated as in §3 above.
• On-call rotation potentially smaller, with the agent carrying the first-touch load.

The framing — you remain essential

Engineers feel threatened by AI for a real reason. They’ve watched their craft be re-described as "the part the AI now does." It’s the right question to be asking. The answer that’s honest, not platitude:

We’re not here to replace ourselves with agents. The value-add is YOU — your domain expertise, your ability to see where the agent should be, the guiding of the agent. You are the QA gap finder, the framework applier, the audit runner, the one who pushes back when AI does something silly. Use frameworks. Use checklists. Use audits. Be harsh when AI delivers something ridiculous: "no, that’s way too low quality, let’s rethink the approach."

The role changes shape. It does not disappear. An engineer who can’t recognise low-quality AI output is replaceable. An engineer who can spot the gap the AI didn’t cover, apply the framework that the AI didn’t know about, audit the assumptions the AI made silently, push back when the AI is taking a shortcut that’s going to cost later — that engineer is more valuable than ever, because the AI amplifies what they catch.

This is the chapter where the bootcamp earns trust with engineers who’ve been quietly worried. Don’t skip the conversation. If you’re running this course with a team, the manifesto reflex from Week 1 should surface here — what specifically do you catch that AI doesn’t?

The assignment — one function, fully scoped

The reason it’s only one function: a thorough, shippable upgrade plan for one is more valuable than shallow plans for all six. The other five can follow once you’ve walked through one in depth.

Self-check — did this week land?

• Can you articulate the “10×-everything-or-bottleneck” principle in your own words to a teammate or manager without reading from a script?
• Do you have a clear-eyed map of which of the six support functions around your team are closest to bottlenecking, and which are healthy?
• Have you written the 10× upgrade plan for one function and committed it to the repo?
• Have you had at least one conversation about the plan with someone who owns or is affected by that function?
• Has the “the role changes shape” framing landed with you personally? If you’re an engineer who used to feel threatened by AI, has Week 3’s framing shifted that — or do you still feel threatened and want to talk about it? Both answers are OK; only the second one is a problem if it goes unspoken.
• Friday demo + weekly planning still running. By Week 3 this should be reflexive, not deliberate.

Why we don’t fix all six this week

The realistic ambition for a 6-week course is to install the way of thinking about support-function scaling, plus one fully-scoped upgrade plan. Actually shipping all six 10× upgrades in a team is a multi-quarter program of work; many teams take 6–12 months to get there.

What Weeks 4 and 5 add: the team-leverage work (ultra-fast iteration, cross-discipline expansion) and the political layer (the conversations with adjacent teams and management about processes that assume hand-crafted code). The 10× upgrade plan from this week becomes input to those conversations.