Article 007: Social Media
URL: https://thelongrun.work/articles/007-how-to-allocate-attention-at-scale
Medium
Tags (5 max)
- Technology
- Software Engineering
- Leadership
- Future Of Work
- Artificial Intelligence
Subtitle
“Tools scale faster than human attention. The challenge is deciding where to look.”
LinkedIn Posts
Post 1: Publish-day (2026-03-02)
Hook: You already know how to do this
Woke up to a PR: 70 files, 2,847 lines changed.
Agent worked overnight. I have an hour to review.
Can’t read it all. Won’t read it all. So where do I look?
Authentication changes? Deep review. Test coverage? Check the diffs. Documentation updates? Skim. Refactoring that preserves interfaces? Trust the tests.
This isn’t new. I’ve been doing this for years with human teams. A team of five developers produces more code in a day than I can comprehensively review. A team of ten makes it impossible even to pretend.
The skill is the same: knowing where to look. Recognizing high-risk patterns. Calibrating trust over time.
What changed: timeline compression. Team-of-ten output arrives overnight instead of across a sprint.
The skill you already have just became more important.
New article: How to allocate attention at scale https://thelongrun.work/articles/007-how-to-allocate-attention-at-scale
How do you decide what deserves deep review?
Visual idea: Split screen showing a massive PR diff on one side, highlighted sections (auth, data persistence, error handling) on the other. The contrast between “can’t review everything” and “know where to look.”
Post 2: Insight (2026-03-09)
I picked up a CI/CD tooling recommendation yesterday. Our original POC had identified issues, so a colleague’s agent worked up several new approaches. Colleague selected one and approved it.
When I reviewed it, I found problems. Nuances in the context and decision-making process were missing. The recommendation looked solid on technical merit but missed critical operational constraints we’d documented from the POC.
Wrong recommendation. Already approved.
Every review is a bet. You’re betting what you examined deeply was actually critical, and what you skimmed was actually safe.
“The more we learn, the more we realize how little we know.”
That’s the supervision problem. The more work scales, the more I realize how much judgment architectural review requires. Not just technical evaluation, but understanding the decision context, the constraints from prior work, the organizational reality that doesn’t live in documentation.
The skill isn’t avoiding misses. You can’t catch everything when work happens at scale. The skill is calibrating: tracking what gets missed, adjusting which questions you ask first.
I now check explicitly for context from prior POCs before approving tooling changes. Updated my review checklist.
What have you learned from your misses?
https://thelongrun.work/articles/007-how-to-allocate-attention-at-scale
Visual: Tooling comparison doc with colleague’s approval, POC findings doc showing missed constraints. The gap between what was reviewed and what mattered.
Post 3: Reflection (2026-03-23)
Hook: AI reviewing AI
Trying something new: generate with Claude, review with GPT-4.
The models disagree on interesting things. Claude chose a functional approach, GPT-4 flagged it as inconsistent with the rest of the codebase (which is OOP). Claude optimized for clarity, GPT-4 caught a subtle performance issue.
What they disagree on becomes a signal for where my attention actually matters.
Not sure yet if this scales or just adds overhead. Early experiments suggest specialized review agents (security scanning, pattern checking) might be more tractable than general review.
The weird part: I’m learning to delegate first-pass review to AI, reserving my attention for architectural fit and business context — things the automated reviewers can’t evaluate.
It feels like tech leadership again. You don’t review every line your team writes. You trust the process, check the high-risk areas, make judgment calls on tradeoffs.
Except the “team” is models, and they generate at 10x speed.
Open question I’m sitting with: how reliable does AI review need to be before it’s worth the overhead of managing it?
Visual idea: Side-by-side code review comments from two different AI models, showing where they agree (✓) and disagree (?). The disagreements highlighted as “human attention needed here.”