Here's a paradox worth examining: GitHub's 2025 Octoverse reports that 72.6% of developers using Copilot code review found it improved their effectiveness.[^1] Yet Stack Overflow's 2025 Developer Survey reveals that only 33% of developers trust AI output accuracy—down from 43% the year before—with 46% now actively distrusting it.[^2]

Developers are using tools they trust less than they did a year ago.

This isn't cognitive dissonance—it's pragmatism. The value proposition has shifted. The conversation around AI in software development has largely focused on code generation: can AI write production-ready code?

That framing misses where AI can deliver immediate, measurable value with far less trust required.

Verification vs. Judgment

When I think about code review, I split it into two layers:

• Judgment: architecture trade-offs, product intent, domain correctness, and long-term maintainability.

• Verification: consistency and completeness against documented standards—patterns, checklists, naming rules, analytics schemas, and “did we remember the boring but important stuff?”

I don’t want AI making judgment calls for me. But I do want it relentlessly running the verification layer—because that’s the part humans agree matters, and still miss under deadline pressure.

PR review isn’t one thing. And skepticism about AI makes perfect sense when we ask it to architect systems or write business logic. But checking whether a PR follows established patterns? Whether analytics events include required parameters? Whether error handling matches conventions?

That’s verification, not creation. And verification is where the bottleneck lives.

Quality and productivity aren't separate concerns—they're linked through rework. Every analytics bug discovered three months post-release requires investigation, prioritization, a fix, another review cycle, and deployment. Fifteen seconds of AI verifying event parameters can prevent hours of future work.

My bet:

PR review verification is one of the fastest places for skeptical teams to feel AI's value—because the output is auditable, and the risk is low.

The blueprint in 30 seconds

If you're impatient, here's what this article will show you:

1. Add instruction files to your repo (your team's actual patterns and rules)

2. Run AI review against your diff before opening the PR

3. Define severity levels so the AI doesn't flood you with noise

4. Let humans focus on judgment, let AI handle verification

5. Iterate weekly and:

   1. add what it missed,

   2. remove what it nags about.

The rest of this article explains why this works, what can go wrong, and how to measure whether it's helping.

Section 2: The Bottleneck Everyone Measures

Code review is one of the most visible bottlenecks in software delivery. In organizations that track DORA-style delivery metrics, review time shows up quickly as "time-to-merge," "time waiting for review," and "review rounds." DORA's 2025 report found that despite AI boosting PRs merged by 98%, code review time increased by 91%—a counterintuitive result suggesting AI generates more code faster than teams can absorb.[^7]

The research on code review effectiveness is sobering. A study from Cisco's programming team—often summarized in industry guidance from SmartBear—converges on what most teams learn through experience:[^3]

• 200–400 lines of code is the optimal review size for defect detection

• Review sessions longer than 60 minutes show diminishing returns as reviewer attention degrades

• Reviewers process approximately 500 lines per hour effectively; beyond that, quality drops

These aren't arbitrary guidelines. They reflect cognitive limits. A 2,000-line PR isn't just harder to review—it's fundamentally incompatible with how human attention works. Yet large PRs are common because splitting work creates coordination overhead.

The bottleneck isn't laziness or lack of process. It's that thorough code review competes with the same cognitive resources needed for feature development. When a senior engineer spends two hours reviewing a PR, those are two hours not spent on architecture decisions, mentoring, or their own deliverables.

Organizations respond predictably aand review depth decreases as deadlines approach. The checks that slip first are exactly the ones AI handles well—style consistency, documentation completeness, pattern adherence.

There's another factor I (unfortunately) rarely happen to discuss with colleagues—human reviewers aren't consistent across authors. We review some colleagues more thoroughly than others. The senior engineer's PR gets a quick approval while the new hire's PR gets line-by-line scrutiny. These biases aren’t malicious—they’re human. But they mean the same code gets different verification depending on who wrote it.

This is where AI changes the equation—not by replacing human judgment on complex architectural decisions, but by taking on the verification layer humans consistently deprioritize under pressure—and applying it uniformly regardless of author.

Section 3: The Blueprint — Structured AI Instructions (Quick Start Kit)

The difference between useful AI PR reviews and noise is structure. AI tools without context produce generic feedback—the equivalent of running a linter with default rules on a codebase with its own conventions.

This isn't speculation. GitClear's analysis of 153 million lines of code found that code churn hit 7.9% in 2024 (up from 5.5% in 2020), with copy/paste code rising to 12.3%.[^5] The code patterns resembled work from "an itinerant contributor"—someone unfamiliar with the codebase's conventions, duplicating logic that already exists elsewhere.

GitHub's research on Copilot from 2023 showed a 55% speed improvement.[^6] However, the study did not examine the effects of AI on quality. It's likely that increased speed without context led to quantity without quality. Developers probably spent time reviewing AI suggestions that went against architectural decisions, duplicated existing utilities, or introduced patterns the team had deliberately moved away from.

The lesson I learned? AI without understanding the codebase context doesn't just fail to help—it actually creates more work.

What this blueprint does NOT do

To set expectations clearly:

• No auto-merging—AI flags issues; humans decide what to do.

• No security sign-off—AI can check for obvious patterns (missing auth calls), but security review still needs human judgment.

• No reliable architecture decisions—AI might suggest using a repository pattern or how to structure your modules, but human judgment is necessary..

• No performance tuning—AI can flag obvious issues, but optimization requires context and execution AI doesn't have.

• No replacing code review—This enhances human review, it doesn't replace it.

The goal is narrower—consistent verification of documented standards, freeing humans for the judgment calls that actually need them.

Quick Start (30–60 minutes)

If you want to try this without committing your team to “AI everywhere,” here’s the smallest version that works:

1. Add a repo-wide instruction file (the rules you wish reviewers enforced consistently).

2. Add one path-specific instruction file for a high-value area (analytics is a great start).

3. Define severity levels so the AI doesn’t flood you with nits.

4. Run an AI review on your diff before opening the PR. It's not necessary, but it's good advice.

5. Iterate weekly—add what it missed, remove what it nags about.

The workflow I actually use (pre-flight, before humans)

The most effective integration I've found isn't AI reviewing PRs after they're opened—it's AI reviewing code before it reaches human reviewers at all.

1. Write the feature

2. Push changes to a branch and open a PR

3. Run an AI review on the PR, either locally or on the server. Running it on the server keeps a history for future human reviewers, which I personally prefer to always have.

4. Fix what it catches

5. Then submit the PR for human review.

This shifts AI review from "another reviewer in the queue" to a pre-flight checklist.

What the AI catches

With properly structured instructions, the AI reviewer enforces decisions the team has already made:

• Analytics completeness:

  • Every user action requires tracking.

  • The instruction file lists required parameters per event type.

  • AI verifies every event includes screenName, userSegment, and action-specific context.

  • No more discovering missing attribution data three sprints later.

• MVVM boundaries:

  • ViewModels don't import UIKit.

  • Views don't contain business logic.

  • Coordinators handle navigation.

  • These aren't suggestions—they're structural decisions.

  • AI flags violations before they become patterns.

• Protocol adoption:

  • The codebase has established patterns for REST API integration—specific protocols for request building, response parsing, error handling.

  • A new endpoint that skips APIRequestConfigurable or handles errors inline instead of through APIErrorHandler gets flagged immediately.

• Abstraction adherence:

  • When the team decided all persistence goes through repository interfaces, that decision needs enforcement.

  • AI spots shortcuts when someone, whether it's the new kid on the block or the project maverick, decides to query Core Data directly "just this once".

• The small things:

  • Debug print statements.

  • TODO comments that should be tickets.

  • Force unwraps that should be guard statements.

  • Hardcoded strings that belong in localization files.

  • The reviewer may catch these, but why waste their attention on them?

Repository instructions (example: GitHub Copilot)

GitHub Copilot supports two levels of instruction files:

Repository-wide instructions (.github/copilot-instructions.md):

# Project Instructions

This codebase follows MVVM architecture with Coordinators for navigation.

## Review split
- Verification tasks should be enforced consistently by AI.
- Judgment calls belong to humans.

## Architecture boundaries
- ViewModels should always be marked as @MainActor
- Coordinators handle navigation

## Concurrency
- All async operations use Swift Concurrency, not Combine

## Analytics
- Analytics events require both action and context parameters
- Do not ship debug logging or TODOs; convert TODOs to tickets

## Quality
- Prefer small PRs; if a PR exceeds ~400 lines, include a short review guide in the PR description

Path-specific instructions (.github/instructions/*.instructions.md):

---
applyTo: "Sources/Analytics/**"
---

# Analytics Module Instructions

## Event Naming
- Use dot-separated lowercase names (e.g., `article.read.completed`)
- Include `screen` context in all events

## Required Parameters
Every analytics event must include:
- `eventName`: The dot-separated event identifier
- `timestamp`: ISO 8601 format
- `sessionId`: Current session identifier

To show this isn’t “just analytics,” here’s a second path-specific example (choose a module where you’ve been burned before):

---
applyTo: "Sources/Networking/**"
---

# Networking Module Instructions

## Consistency
- New endpoints must use the shared request builder and response decoder
- Do not parse JSON inline inside feature code

## Error handling
- Map transport errors into the shared error type
- Do not swallow errors; return typed failures and log at the boundary

## Testing
- Add unit tests for request encoding and response decoding when adding endpoints

Severity rubric (to prevent noise)

If everything is "important," the AI becomes background noise. You can use a simple rubric like this one:

What a good AI review comment looks like (output format)

Here’s the structure I aim for (this is what I want posted as a review, or returned locally):

• Summary (2–4 bullets)

• Findings by severity (Blocker → Low, could be percentages too)

• Suggested tests / QA scenarios (derived from actual diff)

• Needs human judgment (explicitly carve out trade-offs)

Example:

## AI Pre-Flight Review

### Summary
- Adds purchase flow completion tracking
- Refactors CheckoutViewModel concurrency to async/await

### Blockers
- None

### High
- Analytics event `checkout.purchase.completed` missing `currency`

### Medium
- ViewModel is not marked with @MainActor; move formatting helper into view layer

### Suggested QA
- Complete purchase with invalid promo code and verify analytics fires with full parameter set
- Cold start into checkout deep link

### Needs human judgment
- Is the new repository abstraction worth the extra indirection for this feature?

Section 4: Failure Modes & Guardrails

AI review is powerful precisely because it’s consistent—but consistency cuts both ways. Here’s what I’ve seen go wrong, and the guardrails that keep it useful.

Failure modes

• Instruction drift—The AI enforces outdated rules that no longer apply. I find this very similar to when a team member follows outdated documentation.

• False positives → alert fatigue—People start ignoring what the bot writes.

• False negatives → false confidence—Teams assume "the bot didn't complain" means "it's correct."

• Overreach into judgment—AI tries to dictate architecture instead of just highlighting risks. (I have not seen this happen to be honest, but it's a potential risk)

• Security/privacy mistakes—Diffs may include secrets or sensitive data, and prompts might leak information. (Always be cautious about this)

• Social misuse—AI comments are used to judge engineer performance.

Guardrails

• Treat instruction files like code—assign an owner, review changes, and revisit quarterly in the least.

• Cap output—top N findings, group by severity, and link each finding to a specific rule.

• Make the split explicit!—AI verifies but humans judge.

• Audit occasionally—sample 1-2 in 10 PRs to estimate bot accuracy and tune rules.

Section 5: What AI Finds That Humans Miss (Detailed Examples)

The value of AI PR reviews isn't catching what humans would catch anyway—it's catching what humans consistently deprioritize.

Analytics implementation errors

Analytics tracking is the canonical example. A missing parameter in an analytics event doesn't break the build. It doesn't cause runtime errors. It silently produces incomplete data that nobody notices until someone runs a report months later.

Human reviewers know analytics matters. They also know it's boring to verify. Under time pressure, “analytics looks fine” becomes the default assessment.

AI doesn’t experience time pressure. Given instructions like “every purchase event must include productId, price, currency, and purchaseContext,” it verifies every event, every time.

Documentation drift

Documentation that doesn't match code is worse than no documentation—it actively misleads. But keeping documentation synchronized requires noticing when code changes invalidate docs in other files.

Humans review changed files. AI can be instructed to check whether changes to a public API have corresponding documentation updates, whether removed parameters are still referenced, and whether examples still compile.

Pattern adherence

Every codebase accumulates patterns—some documented, many implicit. New team members don’t know them; experienced team members forget to check them during reviews.

AI, given explicit patterns, checks consistently.

Access control verification

Permission checks follow predictable patterns but fail in subtle ways. A new endpoint that forgets to verify ownership. A bulk operation that checks permissions on the first item but not subsequent ones.

Human reviewers catch these when they're looking for them. AI, instructed with “every endpoint modifying user data must call verifyOwnership() before the operation,” checks every endpoint, every time.

Edge-case handling

Certain categories of bugs follow predictable patterns: off-by-one errors in pagination, timezone handling in date comparisons, null checks on optional chains.

The meta-insight: AI review doesn't replace human judgment. It enforces documented judgment that humans apply inconsistently.

Section 6: How to Measure Whether It Worked

If you want this to land with a mixed audience—ICs and leadership—you need a way to validate it beyond vibes.

Metrics that will probably move first

• Time to first human review (does pre-flight reduce back-and-forth?)

• PR open → merge time (what is the improvement on average after 3 months?)

• Review rounds (how often does a PR bounce for “checklist stuff”?)

• Verification-class defects post-merge (analytics gaps, doc mismatches, missing permission checks)

Signals for ICs (quality of the bot itself)

• Acceptance rate (what % of AI findings lead to a code change?)

• Top recurring findings (the list that should become instruction updates)

• Human checklist comments trend (are humans spending less time on nits?)

A simple approach:

1. measure two weeks of baseline,

2. enable pre-flight AI verification,

3. then compare the next 2–4 weeks.

4. You're not trying to prove a paper—you're trying to see if your team is shipping with less rework.

Section 7: The Documentation Accelerator

There's a parallel to AI's impact on code review in an unexpected domain: management consulting.

A multi-school study of consultants using GPT-4 found a 40% performance increase on tasks within AI's capability frontier—but a 19 percentage point drop when AI was applied outside its strengths.[^4] The researchers called this "jagged" value—dramatic gains in some areas, negative impact in others.

That “jagged frontier” maps cleanly onto PR review.

Senior engineers add unique value in:

• Architectural judgment (“this approach will create scaling problems”)

• Domain knowledge (“this flow doesn’t match how our users behave”)

• Teaching moments (“here’s why we don’t do it that way”)

They add less differentiated value in:

• Style consistency verification

• Checklist completion (tests present, docs updated, no debug code)

• Pattern matching against documented standards

AI handles the second category, freeing humans for the first.

The consulting comparison reveals something else—the teams that capture AI's value aren't the ones with the best tools but they're the ones with the most explicit standards. A team with "our code should be high quality" gets nothing from AI. A team with documented conventions and named patterns can offload verification almost entirely—and the documentation improves reviews even without a bot.

Section 8: Conclusion

The bottleneck in code review isn’t going away. Codebases grow. Teams scale. Cognitive limits don’t change because we wish they would.

What changes is what we ask humans to do.

The shift isn't "let AI review PRs."
It's: use AI for verification so humans can focus on judgment.

Human reviewers bring bias—we review some colleagues more thoroughly than others, we're influenced by past experiences with specific authors, we give different weight to the same patterns depending on who wrote them. AI reviewers bring different bias—they're limited to what the instructions encode. They can't catch (thought they might) what you didn't think to document. They won't recognize (thought they might) context that seems obvious to a human who's been on the team for years.

This trade-off is the point. AI bias is explicit and auditable—it's in the instruction file. Human bias is implicit and variable. For verification tasks with documented criteria, explicit bias wins. For judgment calls requiring context and nuance, human bias (with all its flaws) is still necessary.

That's also why this is a great place for skeptical teams to start. The verification layer is explicit, auditable, and low-risk—and it pays back quickly in reduced rework.

The blueprint is straightforward:

1. Document your standards explicitly → If a convention exists only in senior engineers’ heads, AI can’t enforce it—and neither can anyone else consistently.

2. Start with high-value, low-risk checks → Analytics, docs sync, access control patterns, boundary rules.

3. Integrate with existing workflow → Pre-flight is the key—catch issues before humans see the PR.

4. Iterate on instructions → Misses and noise are feedback. Update the instruction file like you update tests.

The question isn’t whether AI can help with code review. It already can—today—for verification tasks.

The question is whether your team’s knowledge is documented well enough to leverage it. And if not, whether making it explicit is worth doing anyway.

References

[^1]: GitHub. "Octoverse 2025: AI leads developer activity." GitHub Blog, 2025. https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/

[^2]: Stack Overflow. "2025 Developer Survey: AI." Stack Overflow, 2025. https://survey.stackoverflow.co/2025/ai

[^3]: SmartBear. "11 Best Practices for Peer Code Review." SmartBear Software, 2025. http://viewer.media.bitpipe.com/1253203751_753/1284482743_310/11_Best_Practices_for_Peer_Code_Review.pdf

[^4]: Dell'Acqua, F., et al. "Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality." Harvard Business School Working Paper 24-013, 2023. Summary: https://mitsloan.mit.edu/ideas-made-to-matter/how-generative-ai-can-boost-highly-skilled-workers-productivity

[^5]: GitClear. "Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality." GitClear, January 2024. https://www.gitclear.com/coding_on_copilot_data_shows_ais_downward_pressure_on_code_quality (2025 follow-up data confirms continued churn growth: https://www.gitclear.com/ai_assistant_code_quality_2025_research)

[^6]: Peng, S., Kalliamvakou, E., Cihon, P., Demirer, M. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv:2302.06590, February 2023. https://arxiv.org/abs/2302.06590

[^7]: DORA. "DORA Report 2025: AI Impact on Developer Productivity." Google Cloud, 2025. https://www.faros.ai/blog/key-takeaways-from-the-dora-report-2025

The irony wasn't lost on me:

I used an AI coding assistant to create a dashboard that excludes the assistant for tasks that can run statically on the API alone, but includes the assistant for PR reviews when necessary.

A few days, a lot of prompts, and now 255 beads issues later, I ended up with something more interesting (at least to me) than “just another AI wrapper”:

• 255 issues total

• 219 closed

• 36 open

• 16 blocked

• 20 ready to work

The twist:

The more I leaned on Claude Code to build the app, the more I wanted the app itself to NOT lean on Claude Code. Wherever possible, I wanted plain APIs, local logic, and headless workflows that would keep working even if I swapped the AI out.

The Original Pain: Too Many Tabs, Not Enough Flow

My typical morning looked like this:

• Open Issue Tracker (e.g. Jira), check tickets assigned to me or to others.

• Open Git Tracker (e.g. GitHub, GitLab), check PRs needing review.

• Open CI/CD Service (e.g. Bitrise, GitLab CI), see what’s red or green, get a build out.

• Open Messaging App (e.g. Teams, Slack), write a status update by hand ...

Each step is fine in isolation.
Together, it’s a “18 tabs open and zero real flow” situation.

The obvious advice is to just use an AI plugin/command inside Claude Code. I do. Or just use an AI plugin inside Jira. I do that too.
They’re super useful. But they’re still trapped inside each tool, or they’re incomplete and they don’t give me:

• One place to see what’s ready to work on.

• One place to see failing builds.

• One place to see PRs that need attention.

• One place where AI can help with reviews and summaries, without jumping between tabs.

So I built a small macOS cockpit for myself.

Beads: The Issue System Behind It

Before getting into the app, a quick nod to beads. I used my cockpit project as an excuse to properly test beads for git‑native issues and dependency graphs with Claude Code, and I’m genuinely happy with it.

The numbers (255 issues, etc) above in the first section of the article are from that system. The dependency graphs and “ready to work” list made it much easier to ask a simple question: “What should I do next?” and get a straight answer.

I had originally planned a bigger comparison in this article between:

• Claude Code’s built‑in /plan

• Another feature‑dev plugin by Anthropic

• beads

That deep dive can be its own article (and it will be). In this one, the important part is simpler: beads did its job well enough that I stopped thinking about my planning tool and focused on building the app.

Building With Claude, But Not Around It

Claude Code still did all of the heavy lifting:

• Wiring API clients for all git tracking, ticket tracking and CI/CD services because it knows them.

• Building the macOS UI and wiring it to those clients.

• Generating issue templates, refactors, and unit tests (512 of them so far).

But every time I hit a design decision, I tried to ask:

“Can this feature run without Claude? Can the app still be useful if I swap the AI provider or turn it off?”

That question changed how I structured things.

What the App Handles Directly

Anywhere the standard APIs were enough, the app uses them directly:

• Issue Tracker – saved queries, filters, and ticket details.

• Git Tracker – listing PRs, statuses, basic metadata.

• Build service – triggering builds where it makes sense.

• Local notifications – reminders for saved queries or conditions I care about.

None of that requires AI to function. It's simply a streamlined UI over APIs that I would otherwise use individually.

Where AI Still Adds Real Leverage

Then there are a few spots where AI really does change the experience:

1. Headless PR reviews

   • From the dashboard, I can select multiple PRs and trigger reviews.

   • Reviews run as background jobs.

   • Each one produces a structured summary with findings and checkboxes.

   • When I select what I agree with, the app posts a GitHub review from my account with the correct line‑level comments.

This feels like the “killer feature”: I can run multiple reviews in parallel and then apply judgment, instead of reading every PR from scratch.

2. Summaries for tickets and PRs

   • Short, consistent summaries for status updates or messaging app posts.

   • 

     For many cases, Apple’s local foundation models are enough (and free).

     

   • For heavier contexts or trickier summaries, I can fall back to Claude or another provider.

The design is “AI tiered by cost and capability”, not “everything through the most expensive model by default”.
So the AI is important—but it’s not the only brain. The app is built so that most of the value comes from the workflow and aggregation, not from one specific model.

Living With AI Amnesia

Of course, working with Claude Code itself wasn’t perfectly smooth. I set clear instructions like “use the beads issue tracker for planning, not todos”, and still had loops like:

Claude: Let me create a todo list to track this…
Me: Use the issue tracker, not todos.
Claude: You're right, I'll create issues instead.
[Later…]
Claude: I'll add this to the todo list…

Some of that is context limits, some is built‑in prompts leaning toward native tools. The practical takeaways for me:

• You need constant reminders about your workflow - the CLAUDE.md file has instructions for using beads but is not always respected.

• You need short, explicit prompts like “Plan this as beads issues” instead of hoping it remembers.

• You need to accept that a bit of drift and correction is normal.

Again, beads helped here - once issues existed in the repo and I reminded the bot to use them, they survived the AI’s memory lapses.

A Quick Detour: Designing the Icon (And Failing Figma’s AI)

Another fun side quest - the icon.

I’m not a designer, but I wanted something that felt at home next to Xcode, VS Code, etc. So I tried:

• Figma with its AI features and a bunch of prompts for “macOS app icon”, “ground control”, “developer cockpit”, and so on.

The results were… NOT fine. For me, Figma’s AI was useful as a brainstorming nudge, but not as “give me a final icon”. If it worked it would’ve been too easy.

• What ended up working was using believe it or not, Perplexity!

  • A few iterations on a “control stand” / tower motif and I had something I can work it.

  • Iterating on colors and lighting.

  • A final touch-up through the Icon Composer macOS App, and I was all set.

That whole process could be its own short article: “I tried to get Figma’s AI to design my app icon. It didn’t. Here’s what actually worked - Perplexity.”

For this story, it’s just another example of the same pattern:
AI can help, but the workflow and judgment still have to be yours.

Notifications, Flags, and Keeping It Yours

A few other parts that turned out surprisingly useful:

• Local notifications – for saved queries or “watchlists”; easily testable from settings so you can check your notification logic without waiting a week.

  

• Feature flags – simple switches to hide integrations I’m not using at the moment. This keeps the cockpit focused instead of becoming a cluttered control panel.

  

None of this is technically complex, but together they make the app feel like my GroundCTRL cockpit, not just a generic dashboard.

Takeaways

From this round, the main lessons for me:

• Using Claude Code to build an app is great, but the app shouldn’t depend on Claude Code to be useful.

• beads work well for multi‑session, dependency‑heavy work – good enough that I trust them as the planning backbone.

• APIs first, AI second – if Issue Tracker/Git Tracker/CI already give you the data you need, call them directly and save AI for summaries, PR reviews, and decision support.

• Headless AI PR reviews with a human in the loop feel like a real multiplier – let the model do the first pass, you decide what actually gets submitted.

• Design tools with AI are not magic – they can suggest directions, but for things like app icons you still need to drive.

The bottleneck isn’t typing anymore. It’s orchestration - picking the right mix of APIs, local logic, and AI so that your tools match how you really work.

And that’s what this little cockpit is for.

Most weeks, the work that drains the most energy is not the hard stuff. It’s the busy stuff.

• The tickets that feel satisfying to close.

• The refactors that make the code just a little cleaner.

• The tiny UI tweaks that only a handful of people will ever notice.

All of that feels like progress.
The problem is that a lot of it barely moves the product or the team forward.

The Pareto principle (the 80/20 rule) says that a small share of effort typically produces a large share of results: roughly 20% of your work drives 80% of your outcomes. If that’s true, it also means something uncomfortable: a big chunk of your time is probably going into things that look like work, but don’t really change much.

How busy work shows up for engineers

In engineering, busy work often arrives disguised as “real work”:

• Tweaking spacing, colors, or animations long before users confirm they even want the feature.

• Refactoring code that’s annoying but not blocking any roadmap item or customer.

• Building internal tools that are fun to write but remove small inconveniences instead of major pain.

On a board, these look legitimate. They’re real tasks, with estimates and assignees.
The cost isn’t that they’re totally useless. The cost is that they push more impactful work to “later”.

Busy work as a starter task

Busy work isn’t always the enemy. Sometimes it’s a useful on‑ramp. There are days when starting with a small, easy win is exactly what’s needed:

• fix a tiny bug,

• clean up a file,

• rename something that’s been bothering you.

You get a quick success, your brain switches into “doing mode”, and suddenly the bigger, scarier task feels less heavy.

The problem isn’t doing a bit of busy work.
The problem is staying there—spending most of the week in low‑impact tasks and never coming back to the 20% of work that actually drives outcomes.

Using 80/20 to avoid busy work

The 80/20 rule is useful not just as a description, but as a filter.

If roughly 20% of your effort creates 80% of the impact, then your job is to find and protect that 20% as aggressively as possible. In practice, that means asking:

• Which few features, decisions, or fixes would actually change a user’s week?

• Which conversations or decisions would unblock the most work for the team?

A simple mental graph you can imagine:

• On the X‑axis: time spent.

• On the Y‑axis: impact.

• The first fifth of the graph shoots up quickly (20% of time → 80% of impact).

• The remaining four‑fifths flatten out into a long tail—lots of effort, small gains.

The goal is to spend more of your week in that steep early part of the curve, and less in the long, flat tail where busy work lives.

The 80/20 version of tech debt

Technical debt is the same story with different branding.

Taking on debt on purpose can be the right call. You ship a rough version, learn from real users, and then decide what’s worth cleaning up. But there’s also a version of tech debt where you spend weeks polishing things that don’t justify the investment.

Viewed through the 80/20 lens:

• The first 20% of effort gives you 80% of the value: a working feature in production, feedback from users, a clearer sense of what matters.

• The last 80% of effort goes into chasing perfect abstractions, solving edge cases no one has hit yet, and rewriting code that already works “well enough”.

Here, 80/20 helps with decisions:

• If a piece of debt is blocking that high‑impact 20% of work, pay it down early.

• If it only affects the long tail of polish, log it, time‑box it, and tackle it later—if it’s still worth it.

Sometimes that last 20% is truly important (compliance, safety, scalability).
Often it’s just comfortable busy work wearing a “quality” badge.

Why busy work is so attractive

There’s a reason this pattern is hard to break - busy work is emotionally easier:

• It’s clear - you know exactly what to do and how to finish it.

• It’s controllable - no stakeholder disagreement, no product ambiguity.

• It’s rewarding - you get quick dopamine hits from closing tickets and merging PRs.

High‑impact work is messier. You need to align people, make trade‑offs, and say “no” to things. You need to pick a direction without all the data. It feels riskier, so your brain quietly drags you back to the safe zone - another refactor, another small UI tweak, another “just in case” improvement.

A simple heuristic: impact × reversibility

A practical way to avoid getting stuck in busy work is to quickly score tasks on two axes:

• Impact – If this goes well, who notices? Users, teams, the business, or just me?

• Reversibility – How hard is it to change or undo later if we get it wrong?

Then roughly prioritise:

• High impact, low reversibility → design carefully, involve others, but still aim to ship.

• High impact, high reversibility → ship fast, learn, and adjust as you go.

• Low impact, anything → busy‑work candidates; handle them later, time‑box them, or drop them entirely.

This doesn’t need to be a formal matrix. Even asking these questions in your head already filters out a lot of “because it annoys me” tasks.

How this shows up in my own work

In practice, this is what it looks like for me when working on the GroundCTRL app (and not only):

With a new feature, I often spend too much time on the final 10–20% of tasks, like deciding on the exact appearance of a button or the arrangement of multiple buttons. The core 80% of the work—the part that actually changes something for the user—is already done, but I get stuck perfecting minor details.

For example, I spent about four hours creating a solid first version of the app with the help of AI. On other days, I’ve lost almost the same amount of time debating button aesthetics and layout, which doesn’t really move the product forward.

As a manager, I can also sink hours into “perfect” documentation, trying to cover every possible scenario. A more impactful move is often a short recording or a simple checklist that unblocks the team quickly.

The pattern is the same - I drift into high‑effort, low‑impact work because it feels safer than making the next significant decision.

Tactics to stay out of busy‑work mode

A few things that help push back against this:

• Start the day/week a clear plan for 2–3 outcomes, not a giant task list. “Ship X”, “Unblock Y”, “Decide Z” beats 20 micro‑tasks.

• Use busy work intentionally - one small task to warm up, then switch to a high‑impact item as soon as you have momentum.

• Time‑box polish - only a small percentage of the feature’s total time is allowed for refactors and tweaks; after that, it ships as‑is.

• Track intentional tech debt in one place and review it regularly, instead of trying to fix everything in the moment.

• Ask once a day “If I stopped working now, what changed for someone outside the team?”. If the answer is “not much,” you’re probably in busy‑work territory.

The goal isn’t to ban busy work. It has its place as a warm‑up and as a finishing layer.
The goal is to keep most of your time in the 20% of work that actually bends the curve—and to use 80/20 as a simple lens for both avoiding busy work and deciding which tech debt really deserves your attention.

Further reading

• Pareto principle (80/20 rule) – Wikipedia https://en.wikipedia.org/wiki/Pareto_principle

• Learn the Pareto Principle (Asana) https://asana.com/resources/pareto-principle-80-20-rule

• The Pareto Principle: Reduce Your Workload with the 80/20 Rule https://openup.com/blog/pareto-principle/

• When is the Right Time to Pay Down Tech Debt? https://madeintandem.com/blog/right-time-pay-tech-debt/

• Technical Debt: The Hidden Cost Of Shipping Fast And Thinking Later https://dev.to/alexindevs/technical-debt-the-hidden-cost-of-shipping-fast-and-thinking-later-587d