> ## Content Index > Fetch the complete content index at: https://johnjanek.com/llms.txt > Use this file to discover other available public pages before exploring further. # Ten Things High-Performing AI Teams Actually Do - URL: https://johnjanek.com/ten-plays-for-ai-teams/ - Published: 2026-09-22T02:06:29.000Z - Updated: 2026-09-22T02:06:29.000Z - Description: The best study we have says AI made experienced developers slower — and they couldn't feel it. Speed was never the leverage. Here's what the teams winning with AI actually do differently. - Author: John Janek - Tags: AI, Software Development, Workflow, Organizational Change The most rigorous study we have on AI-assisted development found that experienced developers, working on their own repositories, were 19% *slower* with AI tools. They expected to be 24% faster. Afterward, they believed they had been about 20% faster. They were wrong in both directions, and they couldn't feel it ([METR, 2025](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)). Sit with that. The tool made them slower, and their own judgment told them the opposite. The productivity story we're all telling each other is, at least some of the time, a hallucination we're having about ourselves. The bill arrives downstream. GitClear's analysis of 211 million lines of code found refactored code collapsed from around 25% in 2021 to under 10% in 2025, while copy-pasted code climbed from roughly 8% to 18% ([GitClear, 2025](https://gitclear-public.s3.us-west-2.amazonaws.com/GitClear-AI-Copilot-Code-Quality-2025.pdf)). DORA has measured a decline in delivery stability two years running as AI adoption climbs ([DORA, 2024](https://dora.dev/dora-report-2024); [Google Cloud, 2025](https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report)). More code, faster, churning harder. So here is the reframe that changes how you use these tools. Speed is not the leverage. Effectiveness is. METR is careful to say there are almost certainly more effective ways to use AI than what their subjects did. DORA is blunter: the return comes not from the tools but from the quality of your platforms, the clarity of your workflows, and the alignment of your teams. Both studies point at the same door. The teams winning with AI aren't the ones with better models. They're the ones with better method. Here are ten things those teams do. Not ten features. Ten disciplines, grouped into the three questions that actually govern outcomes: what conditions did you set, how do you run the loop, and can you stay in control when the machine moves faster than you do. ## Set the Conditions AI amplifies what you bring to it. Strong teams get stronger; weak teams get worse faster. So decide what you're bringing before you scale. **Make your practices explicit in code.** Discovery standards, engineering conventions, architectural decisions — externalize all of it, so both the team and the tools know what "good" looks like. What lives in the AI's field of view is what it builds toward. **Publish your AI stance and wire the tools into your real context.** Say plainly what's sanctioned, what's permitted with guardrails, and what's prohibited. Then connect the tools to your docs, your architecture, your decision records, so the AI stops being a generic assistant and becomes one that knows your system. DORA found the *content* of the stance matters less than its clarity; what kills you is ambiguity, not strictness. **Fix the foundation first.** Version control discipline, automated tests, small batches, loosely coupled architecture. If those are weak, more AI just accelerates you toward the wrong place. This isn't a nice-to-have. It's the precondition for any of the rest to pay off. ## Run the Loop This is where effectiveness beats speed, and where most teams quietly lose. **Practice rigorous curiosity.** Everyone has the same tools; the gap is approach. Decompose the work until each piece is small enough to test, know precisely what changed so you can attribute the result, and treat a pile of new questions at the end as proof the loop is working. Curiosity without rigor is a stack of interesting questions and nothing shipped. Rigor without curiosity is speed in a straight line toward the wrong wall. **Invert the planning-to-execution ratio.** When writing code gets cheap, deciding what to write becomes the expensive part. Spend the majority of your time on design and validation, then let the tools handle the execution burst. And be honest about what "more planning" means: more time with the people whose problem you're solving, not more requirements committees. **Commit to daily features.** If you're not shipping something real each day, ask why. On a great day, dissect what made it great — the conditions, not the luck. The point isn't the cadence as a metric to weaponize. It's the forcing function. If you're not rethinking how you work, you're just doing the old work faster. ## Stay in Control The machine moves at a speed your old coordination habits were never built for. **Automate everything, but stay in the lead.** Your job is to communicate, coordinate, and orchestrate, not to perform the work by hand. Still reviewing every line yourself? Shift your effort toward guiding the AI toward effective review. Manage the tools; don't compete with them. **Guard stability as your canary metric.** Make Change Failure Rate the number the team watches. DORA measured delivery stability falling as AI adoption rose, and found that teams which treat rollback as a first-class move — not an admission of failure — are the ones AI actually helps. **Coordinate before you decompose.** Two teammates' AI tools will each build internally consistent, mutually incompatible versions of the same thing, because neither existed when the other was written. At machine speed you can diverge catastrophically between coffee and lunch. Agree on contracts and interface seams *before* the parallel work begins. "It'll sort itself out" was an assumption built for human-speed development. **Leave it better than you found it.** Close every session one layer up. You delivered the feature. You optimized the loop — what you'd change next time. You improved the shared system — a steering rule, a reusable spec, a pattern the next person inherits. This is the flywheel; every loop deposits something reusable. ## The Number That Ties It Together If your only signal is "this feels faster," that's the METR illusion talking. Pair every velocity claim with a stability, churn, or rework read. Effectiveness is validated decisions per unit time. Not tokens produced. Not lines written. Not acceptance rate. The tools are fast. That was never the question. The question is whether your method is good enough to point that speed at something worth building.