Your PR Count Went Up. Your Leverage Might Not Have.

Day 4 — Leverage Isn't Speed, It's Who Absorbs the Coordination Tax

Your AI tool makes you type faster. Fine, nobody's arguing that. But ask yourself a harder question: has it changed the size of decision you can make without looping in three other people? Because that's the number that actually moves your career — and most engineers have never once tracked it.

Same decision, two timelines

Same scope, same stakes, wildly different bill. The committee path burns 9 days and three other people's calendars just to arrive at a decision. The agent-assisted path burns 3 days and one person's attention. Nobody in that second path typed a single line of code faster — the entire gap is stuff that got skipped, not stuff that got sped up.

The trap: measuring leverage in LOC/hour or PR count

Most engineers who picked up Copilot, Cursor, or Claude Code are tracking the obvious number — how much code ships per week. It went up, so the story writes itself: leverage must be up too. Except LOC/hour was never measuring leverage. It was always a proxy for a different bottleneck — how fast you could turn an already-made decision into committed code. AI tools obliterated that number because typing was never the actual constraint for anyone past their first year or two.

• ▹PR count rewards decisions somebody else already de-risked for you in a meeting you weren't even in.
• ▹LOC/hour can't tell 'I wrote 200 lines because I finally understood the problem' apart from 'I wrote 200 lines because I didn't have to ask anyone first.'
• ▹Neither metric knows about scope. On a dashboard, five small tickets and one ticket that used to need a cross-team RFC look exactly the same.

If you're still reporting your growth in tickets closed per week, you're using a pre-AI ruler on a post-AI tool.

The real bottleneck was never typing — it was waiting

Before agents, the expensive part of any nontrivial decision was never writing the code — it was assembling enough context to write the right code. Reading another team's API docs, if they even existed. Pinging the one person who remembers why that schema column is nullable for no apparent reason. Waiting a day for a Slack reply. Booking a sync because the answer needed back-and-forth instead of a single message. That waiting is the coordination tax, and it scales with org size, not with how hard the problem actually is — which is exactly why a two-line config change takes a week at a 2,000-person company and an hour at a five-person startup.

The mechanism: how an agent absorbs the coordination tax

Here's concretely what changes. Instead of pinging the other team with 'what does this endpoint return' or 'why is this field optional,' you point an agent straight at their repo, their OpenAPI spec, their migration history, their test fixtures — and let it answer the question by reading the artifacts itself.

• ▹Agent reads their service code and API contract — you skip the 'can someone walk me through your API' meeting entirely.
• ▹Agent greps their migration history and commit messages for why a field exists — you skip the hallway hunt for whoever still remembers the reasoning.
• ▹Agent cross-references your proposed change against their test suite and callers — you skip the 'will this break you' back-and-forth.
• ▹Agent hands you a summary with file/line citations you can check yourself in minutes — you skip the trust-building that usually needs a live conversation to happen.
• ▹None of this asks the other team to lift a finger — which is exactly why it's a tax removed, not a favor collected.

Notice the agent isn't making you a faster coder here — most of this involves zero new lines of code. It's making you capable of reaching, solo, the same confidence that used to require a design doc and three meetings, because it can absorb the read-everything-and-synthesize grind that used to need a human intermediary standing between you and the answer.

The line this doesn't cross

This only compresses information-gathering — it doesn't extend to decisions where the hard part is a tradeoff somebody has to own: spending money, accepting risk, navigating org politics. 'Does this API return the field I need' — an agent can nail that with certainty, straight from the code. 'Should we take on this tech debt to hit the launch date,' or 'whose team owns this on-call burden' — that's not a missing fact, that's a judgment call with real consequences for real people, and it still needs the room.

• ▹Compressible: what does their system do, will this break existing callers, what's the precedent for this pattern.
• ▹Not compressible: is this risk acceptable, who eats the cost if it's wrong, does this bump the team's roadmap priority.
• ▹The failure mode showing up right now: engineers use agent-gathered context to skip a sync that was actually a tradeoff call wearing an information-gap costume. The agent handed them facts. The meeting was never about facts.

Day 4 takeaway: the rep to practice

Next time the 'let's sync on this' reflex kicks in, stop for a second and name the actual unknown the sync is supposed to resolve. If it's a fact sitting in someone else's code, docs, or history, hand it to an agent first and see how far that gets you before you touch the calendar. If it's a tradeoff nobody else can sign off on for you, keep the meeting — it'll just be shorter, because the facts are already on the table when you walk in.

Bridge to Day 5

Get comfortable making bigger decisions solo, and a new risk shows up right behind it: making decisions solo that were never yours to make alone. Day 5 is about telling those two apart before you act — not after.

Extend your knowledge

• ▹Pull one 'let's sync on this' request from the last two weeks and reconstruct it: was the real blocker a missing fact, or a tradeoff call? Write down which one.
• ▹Next time you need to understand another team's service, point your agent (Claude Code, Cursor, whatever you've got) straight at their repo before you message anyone — time it against your usual round-trip and see the gap.
• ▹Look up 'bus factor' and 'tribal knowledge' as organizational concepts — they're just the pre-AI names for the exact tax this lesson is describing.
• ▹Watch what happens to your team's PR review time once reviewers can ask an agent to verify cross-service claims instead of making the author explain it live — same tax, just getting absorbed on the review side now.