The Lane Doctrine

Here's a number that should stop you cold: 72% of customers call chatbots "a complete waste of time."¹

And yet, when executives sit down to plan their first AI initiative, the most common starting point is… a chatbot.

Let that land. The thing everyone starts with is the thing customers hate most. The question isn't whether AI is capable — it is. The question is: why do smart leaders keep pointing it at the wrong target?

Because the risk model they've trusted for twenty years told them it was safe.

The Failure Rate That Should Terrify You

The headline numbers are stark. Between 70% and 85% of generative AI projects fail². That's not a rounding error. That's a structural pattern.

RAND Corporation's analysis puts an even finer point on it: 80% of AI projects fail — twice the rate of non-AI IT projects. And the gap, critically, is "largely governance and organisational, not technical."³

The vast majority of enterprise AI pilots never reach production. They stall in pilot purgatory — technically functional, organisationally orphaned, and quietly consuming budget until someone notices.

But here's the finding nobody wants to talk about. RAND identified the most common root cause: "Misunderstandings and miscommunications about the intent and purpose of AI projects."⁴

Translation: it's not the technology. It's where you point it. The model works. The deployment context is wrong. This isn't a technology problem. It's a project-selection problem.

The Cost Beyond the Budget Line

Failed AI projects waste $50K–$300K each. That's painful. But the real cost is something harder to quantify: organisational PTSD.

After a failed AI project, the entire company develops antibodies against the next one. The CTO who championed it loses political capital. The team that built it becomes cautious. The board stops approving AI budgets. One visible failure doesn't just kill that project — it poisons every project that follows.

Research published in Nature reveals an even more insidious dynamic: when a customer-facing chatbot fails, customers don't just blame that specific bot. They generalise the failure to all AI interactions — a phenomenon called category-level attribution.⁵ "AI doesn't work" replaces "this chatbot doesn't work." One bad experience doesn't just kill one project — it creates a trust death spiral.

"AI projects don't fail because AI is bad. They fail because organisations point it at the wrong target."

The 2015 Risk Model — and Why It's Lethally Wrong for AI

For twenty years, there was a reliable heuristic for deploying new technology:

"Start small. Start customer-facing. Prove value. Then expand."

This worked brilliantly for deterministic software. CRMs, ticket systems, workflow tools — you deploy small, iterate, and scale. It worked because deterministic systems behave like well-trained appliances. They either do the thing or they throw an error. The risk surface is mostly availability, performance, and security — and those are familiar. Every executive over 40 has this muscle memory. It wasn't wrong. It was right, for twenty years.

But for AI, this heuristic inverts completely.

A chatbot isn't a small appliance. It's a probabilistic generator interacting with human psychology in real time. The harm isn't "it crashes." The harm is: it confidently says something wrong, offensive, non-compliant, or simply weird — and you pay for the screenshot forever.

The Chatbot Graveyard

The evidence trail is damning. Of customers who encounter chatbots:

Source: Forbes/UJET, "Chatbots and Automations Increase Customer Service Frustrations"⁶

The chatbot isn't resolving — it's delaying. And users have learned. Research from Johns Hopkins Carey Business School found that users actively avoid chatbots because they expect to waste time based on past failures.⁷

Why "Escalate to Human" Doesn't Save You

"Human in the loop" sounds like a parachute. In practice, it fails as a safety argument for three reasons:

The Expectation Trap

Modern chatbots are designed to feel human. Friendly language, avatars, personalities — all of which raise customer expectations. When the bot then fails to deliver human-level understanding, the disappointment isn't proportional — it's amplified.⁸ You've set up a promise you can't keep.

Chatbots "loop canned responses instead of recognising complexity and escalating. Customers get stuck in conversation dead-ends with no clear exit."⁹ The result is a trust death spiral: customers don't just blame that chatbot — they generalise the failure to all AI. "AI doesn't work" replaces "this chatbot doesn't work." One bad chatbot experience poisons every future AI initiative across the organisation.

The Real Risk Equation

Risk ≠ project size. This is the cognitive trap.

Executives think: big project = big risk. Small project = small risk. That's the appliance model. It works for ERP rollouts and CRM implementations. For AI, the risk equation is fundamentally different:

Now apply this equation to two projects:

The "big scary" batch project is objectively safer than the "small safe" chatbot. The size doesn't matter. The physics does.

"Risk isn't proportional to project size. Risk is proportional to exposure × irreversibility × uncertainty. A big batch project can be safer than a tiny chatbot."

The Inversion — Stated Plainly

Every instinct from traditional IT project management is backwards for AI. What looks simple — chatbots, phone triage, frontline support — is actually a boss fight: high-coupling, high-exposure, high-expectation. What looks complex — legacy replacement, nightly decision builds, parallel analysis — can be dramatically safer, provided it stays in AI's lane.

What does "in AI's lane" mean? A preview — Chapter 2 goes deep:

• ✓ Batch-friendly — latency doesn't matter
• ✓ Artefact-producing — outputs are reviewable before anyone acts on them
• ✓ Routes through existing governance — SDLC, code review, CI/CD pipelines
• ✓ Natural blast-radius limiter — nothing hits production without gates

These properties don't correlate with project size. They correlate with deployment context. The project you can't conceive — the "unthinkable" one — might be the safest bet in your portfolio. The project you approved last week — the chatbot on the website — might be the one most likely to blow up your error budget, your brand, and your appetite for AI.

What This Means for You

That's not a wish list. That's what AI can actually do today, right now, if you stop forcing it into the one place it can't perform: real-time, customer-facing, high-stakes interactions.

Chapter 1 showed you why the "safe" project fails. This chapter shows you what AI is actually good at — and it's a much bigger territory than you think.

The Lane Is Massive

"Lane keeping" sounds conservative. Limiting. Like you're saying AI can't do much. The opposite is true. The lane is enormous. It covers nearly everything except real-time customer-facing high-stakes interactions. Here's the full inventory.

The Voice Cloning Trap: Reasonable Beats Perfect

AI is superb at voice synthesis. But people stumble because they confuse fidelity with value. "Everyone thinks you have to clone your own voice for it to be useful," as Scott puts it, "but that just wrecks the whole thing."

If you're producing YouTube videos, nobody checks your real voice against the recording. Use a voice with the right country, accent, and demographics. Drop the perfection requirement from 100% to 90%, and the entire governance nightmare — consent, deepfake regulation, brand liability — disappears.

This is the Lane Doctrine in miniature: reasonable beats perfect, and reasonable is squarely in the lane.

The Meta-Rule: Don't Trade Intelligence for Speed

At the heart of every AI deployment decision sits a single tradeoff: intelligence versus speed. AI is strongest when it can think, fetch, cross-check, and revise. All of those require time. Force AI into sub-second responses and you strip away every advantage.

The meta-rule is simple: if the user can wait, let the model think. If they can't, redesign the interaction so that something else handles the rapid turn-taking while the deep work happens off the clock. This single sentence contains the entire deployment strategy.

"Thinking" in AI terms means: extended reasoning across multiple steps. Tool use — RAG retrieval, database queries, web searches, API calls. Self-critique and revision: generate, evaluate, refine. Parallel exploration: try multiple approaches, compare results. Adversarial checking: a second pass that challenges the first.

All of these compound with time. None of them work at 200 milliseconds.

The Three Constraints That Kill AI Projects

Now you know what AI is good at. Here's what kills it. Three structural constraints — each dangerous alone, lethal when combined.

The Boss-Fight Rule

"As soon as you fight more than one problem, just give up."

If a project triggers two or more constraints simultaneously — latency + governance, governance + human advantage, or all three — the risk doesn't add. It multiplies. This is the Boss-Fight Rule.

One constraint is a manageable challenge — you can engineer around it. Two constraints create a trap where the solutions conflict: fast responses (solving latency) require skipping verification (creating a governance problem). Deep reasoning (solving governance) requires time (creating a latency problem). Human-quality social interaction (solving the human advantage gap) requires both speed and depth simultaneously.

Three constraints? That's the boss fight. Walk away. There's an entire map of easier territory with better loot.

"Don't fight the boss fight today. And as AI gets better, take on those different fights. But today — stay in the lane."

The Expanding Lane

The lane isn't static. As AI models improve, latency will decrease. As governance practices mature, organisations can handle more runtime AI. As architectures evolve — such as the Fast-Slow Split pattern that separates talking from thinking — some constraints can be engineered around. Some of today's boss fights will become tomorrow's tutorial levels.

But some constraints are fundamental. Human turn-taking at ~200ms is biological — it's not going away. Governance requirements are increasing, not decreasing, as regulation tightens globally. Human social and emotional advantage in relationship contexts isn't closing soon.

The strategic implication: start in the wide-open lane today — batch, coding, internal tools. Build your governance muscle, observability, and error budgets. As your muscles strengthen and AI improves, graduate to narrower lanes. Don't advance autonomy faster than your governance muscles can support.

We've written about this as the Cognition Ladder — three rungs of AI value from "Don't Compete" (real-time, 70–85% failure) to "Augment" (batch, $3.70–$10.30 ROI per dollar) to "Transcend" (overnight, work that was structurally impossible before). Most organisations fail on Rung 1. The opportunity lives on Rungs 2 and 3 — and both are squarely in the lane.

What This Changes

The lane is massive: coding, batch analysis, overnight synthesis, document intelligence, parallel research, adversarial checking, RAG/semantic search, voice synthesis, UI building, web research, and more. The exciting projects — the ones that transform businesses — live in the lane. The boring projects — the ones that sound safe — live in the boss fight.

"Go where no man has gone before, and then find the value. Don't fight the boss fight today."

GPT-3.5 with agentic workflows scores 95% on HumanEval. GPT-4 alone scores 48%.¹⁰

A weaker model in the right architectural pattern beats a stronger model in a constrained one. Almost 2× the performance. Same family of technology. Radically different deployment context.

This means the question "which AI model should we use?" is the wrong question. The right question: "Are we deploying AI in a context where it can actually use its strengths?"

The Lane Test makes that judgment in five minutes.

Why a Test, Not Just Principles

Chapter 1 showed the inversion: "safe" is actually dangerous. Chapter 2 showed the physics: superpowers and constraints. But principles alone don't change decisions. Executives need a tool. Something they can score. Something falsifiable. Something they can apply in the room when someone pitches the next chatbot project.

The Lane Test is designed to be:

The Lane Doctrine says: deploy where physics is on your side. The Lane Test operationalises that into seven yes/no questions. Score NO on Q1–Q2, and YES on at least 3 of Q3–Q7. If you pass, you're in the lane. If you fail, you're heading for a boss fight.

The Seven Questions

The Scoring Rule

Three Projects Scored

Let's walk through three common AI projects and score each against the Lane Test. Same AI. Same models. Radically different deployment contexts.

When the Test Says "Fail" — Your Three Options

And sometimes, the right answer is to walk away. Some deployment contexts are structurally wrong for AI. If Q1 and Q2 are YES, and Q3–Q7 are mostly NO, this may not be an AI problem at all. Walking away from a bad deployment context is the highest-ROI decision you can make.

The Doctrine in One Sentence

"The single best thing AI is good at right now is coding. It's astronomically off the planet. It keeps up with the best elite programmers on the planet. And then you can parallelise it, and meta-manage it. It's off the charts capable."

OpenAI's Agent Builder was developed in under six weeks. Codex wrote 80% of the pull requests.¹⁶ That's not a toy demo. That's a production system built primarily by AI, reviewed by humans, shipped through standard SDLC.

This chapter explains why coding works so well — and it's not just "AI is smart." It's deployment physics.

The Evidence Case

The productivity evidence is extraordinary. Developers complete tasks 55–82% faster with AI assistance¹⁷, with McKinsey's controlled study confirming a 56% speedup¹⁸. 90% of developers report feeling more productive with AI tools¹⁹. Among leading developers, 90% of personal code is now AI-generated²⁹.

This isn't the 10–15% efficiency bump that comes with bolting a copilot onto an existing process. This is 55–82% faster — a fundamental shift in how software gets built. At OpenAI's internal experience of 80% AI-generated PRs, the economics of software development have inverted.

But the numbers tell only half the story. The deeper change is qualitative: AI doesn't just type faster. It changes what the developer does. The old model was 80% execution (writing code line by line) and 20% thinking. The new model is 10% execution (reviewing AI output) and 90% thinking (specification, architecture, judgment). AI is an intention compiler — it can only compile what you specify.

Why Coding Passes Every Lane Test Question

Chapter 3 introduced the Lane Test. Here's the flagship demonstration — all seven questions, applied to AI-assisted coding.

Governance Arbitrage — The Deep Insight

"Design-time AI produces reviewable, testable, versionable artefacts. Runtime AI requires inventing governance from scratch."

This is the deepest insight in the Lane Doctrine, and coding illustrates it perfectly. When AI produces code — an artefact — you review it through the same process you use for human-written code. PR review is governance. CI/CD is quality control. Tests are verification. You're routing AI value through governance pipes you already have.

The Specification Paradox

The honest counterpoint: AI coding isn't magic. A study by METR found that experienced developers were 19% slower with AI when they skipped specification work²⁰. There's even a perception gap: developers perceived a 20% speedup but actually experienced a 19% slowdown²¹.

The difference between 55–82% faster and 19% slower? Specification quality. AI doesn't remove work — it moves work. From execution to thinking. From typing to specification. The developer's old workload was 80% execution, 20% thinking. The new workload is 10% execution, 90% thinking. Total effort may be similar, but the type shifts dramatically.

For the Lane Doctrine, this means the specification is the durable asset, not the code. Specifications survive model upgrades — each new model produces better code from the same spec. The code is ephemeral. The thinking is permanent. Invest there.

A Day in the Life: Before and After

Same hours. 4× the output. The developer's role shifted from coder to creative director. The developer who writes the best specifications gets the best AI output. The one who says "just make it work" gets chaos.

What Coding Proves About the Lane Doctrine

Coding isn't special because AI is smart. It's special because the deployment context is perfect:

• ✓No latency pressure → full intelligence utilised
• ✓No public exposure → errors are cheap and contained
• ✓Artefact-producing → governance for free through existing SDLC
• ✓Batch-friendly → time buys quality
• ✓Parallel → broader exploration of solution space
• ✓Compounding → specifications and tests persist and improve
• ✓Cageable → sandboxed, reviewed, rollback-ready

Any deployment context that shares these properties will succeed. Coding proves the doctrine. The next chapters show other contexts that share the physics: batch processing (Chapter 5), the Cognitive Exoskeleton (Chapter 6), and real-time mitigation when business demands it (Chapter 7).

A real-time system processing one million requests daily requires 100 GPU instances running 24/7, costing roughly $150,000 per month. A batch system processes the same volume with 20 GPU instances running 7 hours per day during off-peak pricing: $40,000 per month.²²

Same work. Same AI. Same volume. Different physics. $110,000 per month difference.

But cost isn't even the biggest win. The biggest win is intelligence.

The Economics of Patience

Real-time systems are expensive because they must overprovision for peak load — paying for capacity used 10% of the time. GPU instances idle during off-peak hours but still cost money. Redundancy requirements (failover, load balancing) multiply costs further. Latency requirements force expensive low-latency networking and proximity hosting.

Batch flips all of this: time-shift computation to off-peak hours, right-size for average load, process sequentially without latency pressure. If a batch run fails, restart it. The AI provider literally gives you a 50% discount for waiting.

The meta-point: batch processing provides 40–60% cost reduction versus real-time with improved depth of analysis²⁴. Cheaper and smarter. There's no tradeoff here.

Lane Test: Batch Processing

What "Batch the Brain" Looks Like in Practice

The Five Artefacts Per Overnight Run

The most valuable artefact isn't what the AI recommended — it's what it didn't recommend and why. Showing rejected alternatives proves the system actually deliberated, not just fired one-shot. It enables humans to challenge the reasoning, not just the conclusion.

Why Batch Unlocks Deeper Intelligence

The Model Drift Problem — and Why Batch Solves It

AI systems don't fail with error screens. They fail silently. No crashed service. No broken button. Just quietly degrading quality until someone notices the outcomes have gone wrong. Research shows that 91% of ML models degrade over time²⁵, with error rates jumping 35% after six months without updates²⁶.

Three types of drift: data drift (input distribution changes), concept drift (what "good" looks like evolves), and performance degradation (raw accuracy declines). All are silent. All are expected.

Batch processing provides natural drift detection through the CI/CD mapping: regression tests (replay frozen inputs, compare outputs), diff reports (what changed?), quality gates (automated checks before deployment), error budgets (quantified acceptable failure rates), and canary releases (test on 5% before full rollout). Standard software engineering practices, applied to AI decision systems.

The Governance Advantage of Batch

Every nightly run produces a record. Records can be analysed for patterns: which recommendations were overridden? Which were wrong? Which were brilliant? This feedback loop improves both the AI system and human judgment. Over time, the organisation develops an empirical understanding of where AI is strong and where it needs human oversight — building the governance muscle to eventually graduate to higher-stakes deployments.

Chapter 1 established the problem: customer-facing AI is a boss fight. Chapter 5 showed how batch processing keeps AI in the back office. But organisations still need customer-facing value from AI. The Cognitive Exoskeleton resolves the tension: AI creates the value, the human delivers it.

Customer-facing impact without customer-facing risk.

The Pattern: AI Prepares, Human Delivers

The Cognitive Exoskeleton is a deployment pattern, not a product. AI saturates all the pre-work and side-work. The human owns judgment and relationships. AI does the exhaustive preparation — research, analysis, drafting, options generation, evidence gathering. The human makes the judgment call in the moment: what to say, when to escalate, how to handle nuance.

Accountability and relationships stay with the human. Always.

This pattern exists because Chapters 1 and 2 established a hard truth: putting AI directly in the customer lane stacks latency, governance, and human-advantage constraints simultaneously. That's the boss fight. But the business need for AI-improved customer experience is real. The Cognitive Exoskeleton resolves the contradiction by keeping AI where it's strong (behind the glass, producing artefacts) while keeping humans where they're strong (in the conversation, making judgment calls).

Lane Test: The Cognitive Exoskeleton

The Exoskeleton Across Industries

The pattern is domain-agnostic. The only requirement: a human makes the final delivery while AI handles the preparation. Here's how it works in four common contexts.

Customer-Facing Value Without Customer-Facing Risk

Revisit the risk equation from Chapter 1. Risk = exposure × irreversibility × uncertainty.

What the customer experiences: faster responses (the agent didn't spend 60% of their time on context gathering), more personalised service (AI researched their specific situation), better-prepared staff (the agent has evidence, not guesses), and first-contact resolution (because AI pre-identified the likely solution). They never know AI was involved. They just know the service was excellent.

What the organisation experiences: no brand risk (AI never speaks to customers), no governance novelty (artefacts reviewed through existing quality processes), no error budget pressure (human catches AI mistakes before delivery), compounding improvement (each resolution improves the knowledge base), and measurable impact (before/after metrics on resolution time, satisfaction, first-contact rate).

The “Silent AI” Experience

“AI doesn't talk to your customers. It makes every employee who does talk to them dramatically better.”

There are two kinds of AI customer experience. Loud AI: chatbots, voice agents, AI-generated emails — customers know they're talking to AI. Silent AI: AI works behind the scenes, the human delivers the result. Customers notice the quality, not the AI.

Silent AI doesn't have this problem. The human writes — or approves — the email. In their voice. With their judgment. The AI's contribution is invisible: it researched the issue, identified the precedent, drafted the response. But the human made it theirs before sending.

Every AI-generated customer communication is a brand risk. Even well-prompted AI occasionally produces tone-deaf, repetitive, or awkwardly formal responses. The Cognitive Exoskeleton eliminates this entirely: human voice, human judgment, human relationships — with AI-quality preparation underneath.

From Record Navigation to Decision Navigation

The Cognitive Exoskeleton implies a fundamental shift in user interface design. Traditional interfaces ask: “Here's the data. What do you want to see?” AI-enhanced interfaces ask: “Here's what we think you should do. Do you agree?” The shift from presenting data to proposing decisions.

“We need customer-facing AI. Our competitors have it. Make it happen.”

If you've read this far, your instinct is to push back. Chapters 1 through 6 have made the case: customer-facing AI stacks constraints. It's the boss fight. The smart money stays behind the glass.

But the Lane Doctrine doesn't say “never.” It says “not without preparation.” There's a difference between walking away from a boss fight and preparing properly before you enter one. This chapter is the graduation guide: how to earn your way to higher-stakes deployments — without getting killed by the constraint stack.

What the Lane Test Is Actually Saying When It Flags “Danger”

A YES on Q1 or Q2 is a warning, not a death sentence. Q1 (sub-second required) means you're paying a tax — AI will be constrained, and you need to architect around it. Q2 (public/regulated/irreversible) means the governance burden is high — you need infrastructure in place before deployment, not after.

Both together? That's the boss fight. Not impossible, but it requires battle-tested preparation.

Five Options When the Lane Test Flags Danger

The Fast-Slow Split — The Escape Hatch for Real-Time

“The part that talks doesn't need to think, and the part that thinks doesn't need to talk fast.”

We've written extensively about this pattern elsewhere³⁴. The core insight: separate the talker from the thinker. Two agents running in parallel, inspired by Kahneman's System 1 and System 2 — implemented as two cooperating AI systems, not one overworked model.

The fast lane meets the 200ms turn-taking requirement from Chapter 2. The slow lane does the deep work without latency pressure. The customer gets an immediate conversational response and deep intelligence — just slightly delayed. The latency constraint is managed by architectural separation, not by sacrificing intelligence.

The Graduation Path: Earning Your Way to Higher Stakes

Don't advance autonomy faster than your governance muscles can support³⁵. Every higher-stakes deployment builds on organisational capability earned at lower stakes. This isn't conservatism. It's engineering discipline. You don't test a bridge with traffic before you test it with load.

Each phase builds on the last. Phase 1 builds observability — Phase 2 uses it for human-in-loop patterns. Phase 2 builds feedback loops — Phase 3 uses them for automated quality. Phase 3 builds evaluation harnesses — Phase 4 uses them for exoskeleton quality. Phase 4 proves the AI's judgment — Phase 5 deploys that judgment with containment. Skip a phase and you have gaps in your governance muscle.

The Governance Gap — Why Rushing Kills Projects

The governance gap is stark. 85% of organisations plan to deploy agentic AI. Only 21% have governance infrastructure to support it¹⁴. That's a 4:1 ambition-to-readiness ratio. 74% plan to deploy within two years.

Gartner predicts that 40% of AI agent projects will be cancelled by the end of 2027²⁸. That's a direct consequence of the governance gap. Most organisations will attempt high-autonomy deployments without the infrastructure to support them. One visible mistake kills the project.

Governance can't be retroactive. You can't build the parachute after you've jumped. Monitoring, error budgets, rollback capability, and incident response must be in place before deployment — not built under the pressure of a live system after a visible failure. The graduation path builds governance incrementally, so it's ready when you need it.

Error Budgets: The Gateway to Real-Time

Without error budgets, the first visible mistake kills the project. With error budgets, the first visible mistake is expected, categorised, and manageable³⁶. The difference between “AI failed!” and “AI is performing within expected parameters.”

The pre-negotiation is critical. Error budgets must be agreed before deployment, not after the first error. Multi-stakeholder sign-off: executive, technical, legal/compliance. Based on human baseline data — capture 2–4 weeks of human error rates pre-deployment. The AI target: match or beat the human baseline. Without a baseline, you can't demonstrate that AI is actually performing well.

Error budgets do more than measure quality. They force you to define “good enough” in advance. They create a quantified framework for learning and improvement. They prevent the political dynamics that kill projects (“AI made a mistake!” becomes “Was it within budget?”). They build organisational comfort with probabilistic systems. This is the governance muscle that enables graduation from Phase 4 to Phase 5.

The Lane Test as a Living Tool

The Lane Test isn't a one-time exercise. It's a decision discipline. Re-score your project portfolio every quarter. The conditions change:

Projects that failed the Lane Test six months ago may now be viable — improved models, better governance, more organisational experience. Projects that passed six months ago should be re-validated — have conditions changed? Has the model drifted? Deferral is not abandonment. It's “not yet.”

The Lane Doctrine — Summarised

AI projects succeed when routed through AI's structural superpowers — slow cognition, parallelism, batch processing, and reviewable artefacts. They fail when forced into constraint-stacking environments — latency + governance + human home-field advantage. The 7-question Lane Test makes this judgment systematic and repeatable.

“You’re not avoiding hard problems. You’re avoiding badly-posed problems.”

The Lane Doctrine isn't conservative. It opens up massive projects that would terrify a 2015 risk model: legacy system replacement through observed behaviour and nightly builds. Parallel analysis of 50 strategy branches overnight. AI-powered coding at scale where specifications are the durable asset and code regenerates with every model upgrade. Nightly decision builds that give your team an intelligence briefing every morning.

The “scary” projects — the ones that transform businesses — live in the lane. The “safe” projects — the ones that sound easy — live in the boss fight.

Swap your 2015 risk model for a 2026 one. Score your projects. Stay in the lane. And go build something that matters.