Article 007: How to allocate attention at scale
Key Message: Tools scale faster than human attention. The challenge is deciding where to look.
Series: B — Reframing the work (Part 2 of 6) Publish Date: Monday 2026-03-02
Story Outline
Opening: This isn’t new
The realization:
- Reviewing output you didn’t write at scale isn’t novel
- Senior developers and tech leads already do this daily
- You don’t read every line your team writes
- You’ve learned where to look, who needs close review, what changes are risky
- The skill already exists in tech leadership
What’s actually new:
- Timeline compression: team-of-10 output arrives overnight, not across a sprint
- Source difference: AI instead of human developers
- Volume amplification: reviewing magnitudes more code than before
- But the fundamental practice? Already familiar
The frame:
- Not learning a completely new skill
- Adapting existing tech leadership practice to new scale and source
- Your experience reviewing human output transfers
- Different heuristics, same core capability
What transfers from reviewing human teams
You already know:
- Not everyone’s code needs equal scrutiny (junior vs senior patterns)
- Some changes are inherently higher risk (authentication, data handling)
- Pattern deviation signals problems
- Comprehensive review isn’t possible at scale
- Trust builds over time through calibration
The heuristics you’ve developed:
- Who tends to over-engineer vs under-think edge cases
- What kinds of changes this person handles well
- When to dig deep vs when to trust and move on
- How to spot red flags without reading every line
What adapts for AI review:
- “Who wrote this” becomes “which model/agent/prompt”
- Patterns of human developer styles → patterns of AI generation styles
- Trust isn’t about individual capability, it’s about task-model fit
- Different models have different blind spots
- Calibration still matters, just different calibration target
The practical framework: Where to actually look
High-risk signals (deserve deep attention):
- Critical paths: authentication, payment, data persistence, security boundaries
- Abstraction changes that other code depends on
- User-facing behavior changes
- Error handling and edge cases
- Cross-module dependencies
- New patterns introduced to the codebase
- Concurrency or timing-sensitive code
Low-risk signals (can skim or delegate):
- Internal refactoring preserving interfaces
- Follows established patterns exactly
- Changes well-covered by comprehensive tests
- Purely mechanical transformations
- Documentation updates
- Formatting/cosmetic changes
Pattern recognition for risk:
- Diff size mismatched to stated goal
- Inconsistency with existing conventions
- Missing or vague explanations
- Test coverage gaps
- Unusual dependency changes
- Comments that explain “how” but not “why”
The bet:
- Every review is attention allocation bet
- Over-scrutinize: waste time on low-risk changes
- Under-scrutinize: ship bugs from high-risk missed issues
- Experience = better calibration
AI-assisted peer review: Scaling first-pass review
The insight:
- “Peer review” doesn’t have to be human anymore
- Use AI to review AI output
- Different models catch different issues
- Cheaper than your attention for first-pass
Multi-model review approach:
- Generate with Model A (Claude, GPT-4, Gemini)
- Review with Model B for different perspective
- Flag discrepancies and disagreements
- You review what the models disagree on
Specialized review agents:
- Security agent: Scan for common vulnerabilities (injection, XSS, auth bypass)
- Performance agent: Flag algorithmic complexity issues, memory leaks
- Pattern agent: Check consistency with codebase conventions
- Test agent: Evaluate test quality (brittleness, coverage, meaningfulness)
- Each focuses on specific risk dimension
Automated risk scoring:
- Agent analyzes entire change
- Scores each file/section by risk
- Flags high-risk areas for your attention
- You review flagged + sample the rest
The allocation strategy:
- Let AI reviewers do first pass at scale
- They flag disagreements, risks, pattern violations
- You review what’s flagged
- Sample remainder for calibration
- Your attention focuses on genuine judgment calls
Learning what to delegate to AI review:
- Security scanning: highly delegatable
- Pattern consistency: mostly delegatable
- Architectural fit: requires human judgment
- Business context alignment: requires human judgment
Developing the allocation skill
Track your misses:
- What broke in production that you reviewed?
- Where in the change was the bug?
- Did you look at that area? Why not?
- What signal would have directed attention there?
- Update your heuristics
Track your over-scrutiny:
- What did you deep-review that was actually fine?
- What low-risk signals did you ignore?
- Where did you waste attention?
- How can you trust more appropriately?
Calibrate to your context:
- Different codebases have different risk patterns
- Different domains have different critical paths
- Your heuristics adapt to what you’re reviewing
- Gets better with experience in this specific system
Build on tech leadership experience:
- You already know how to review at scale
- You already know how to allocate attention
- You already know how to trust appropriately
- Apply those skills, adjust for AI source and compressed timeline
Close: Familiar practice, new scale, new tools
The core skill hasn’t changed:
- Reviewing output you didn’t write
- Allocating finite attention across large changes
- Knowing where to look
- Building trust through calibration
What’s different:
- Scale: more code, faster
- Source: AI instead of human team
- Tools: AI-assisted review available
- Timeline: compressed from weeks to overnight
The advantage:
- You already have this skill from tech leadership
- Not learning from scratch, adapting existing practice
- AI reviewers can scale first-pass review
- Your attention focuses where judgment matters
The question isn’t new:
- “Did I look at the right things?”
- Same question tech leads ask about team review
- Same calibration process
- Different scale, same skill
Notes
[Add notes as you develop the article]
Threads from earlier articles
| From | Theme | Pick up here |
|---|---|---|
| 003 | Abstraction alignment | Which level to attend to? Cost of attending wrong level. Human directs at intent, AI works at implementation — where do you look? |
| 003 | Review: sampling or comprehensive? | Does attention budget force sampling? Or can you still review fully, just differently? |
| 003 | Context window mismatch | You can’t attend to everything — AI context exceeds yours. Attention allocation becomes the skill. |
Potential angles
- Attention as finite budget vs infinite AI output
- The skill of “knowing where to look”
- Tool design: what should surface vs what should stay buried?
- The cost of attending to the wrong abstraction level
- False confidence from partial attention