Claude makes every engineer look like a 10x engineer. That's the problem.

The dashboards are lying to you. Not on purpose - they're just measuring the wrong thing.

Since Claude Code and the other coding agents landed inside mainstream engineering workflows, every commit graph looks aggressive, every PR description reads sharp, and every Friday demo lands. If you are a VP of Engineering or Head of AI staring at the same telemetry you stared at in 2023, you would swear your team got three times better overnight. They didn't. The tooling did.

That gap - between "your team looks productive" and "your team is productive" - is now the most expensive blind spot in software leadership. And the people exploiting it aren't your underperformers. They are the calm, confident, perfectly-on-time engineers who have figured out something you haven't: in an AI-leveled world, looking like a 10x engineer is no longer evidence of being one.

When AI lifts the floor, the ceiling stops telling you anything

For most of the last two decades, engineering management worked because of variance. You could see who was carrying the load because the load showed up in their output. The top of the distribution was visible. The bottom of the distribution was visible. The middle was, roughly, the middle.

Claude Code collapsed the distribution. The bottom now ships PRs that pass review. The middle ships PRs that look senior. The top ships PRs that look the same as the middle. Velocity charts no longer separate strong engineers from weak ones - they separate engineers who lean on AI from engineers who don't.

This is not a hypothetical. Gergely Orosz's now-cited piece on the 10x overemployed engineer walks through exactly how one person, with the help of AI tooling, can credibly hold multiple full-time engineering jobs at once. Fortune's reporting on the same phenomenon described workers pulling six-figure salaries across five jobs simultaneously, with online communities organizing the playbook openly.

The uncomfortable truth: the same tooling that boosts your strongest engineer's output is what lets your worst hire convincingly hold three other jobs on the side. From the outside - from a velocity chart, a commit count, a sprint burndown - those two engineers look identical. Both ship. Both stand up well in standup. Both nod through retros.

This is why "are they being productive?" is now the wrong question. The right question is: productive on what, and for whom?

Engineer AI productivity is a measurement problem, not a tooling problem

Most engineering orgs are still trying to measure AI productivity with pre-AI metrics. They count commits. They count PRs. They count story points. Then they wrap it in a Notion doc called "AI ROI" and present it to the CFO with a straight face.

It doesn't work. Every one of those metrics is now downstream of how much the engineer prompted Claude that day, not how much value they shipped. The metrics measure LLM volume, not engineer judgment.

Real AI productivity measurement looks different. It starts at the prompt layer and works up:

• Prompts sent against the company codebase, not abstract or unfamiliar paths
• Tokens spent on repositories that exist in your org's git history
• Lines of code accepted into branches that map to active sprint work
• Time-in-Claude-Code on tickets that exist in your project tracker
• Model selection patterns - are engineers reaching for Opus when Haiku would do, and is that on company work or someone else's?

None of that is in your billing dashboard. Anthropic's seat-level reporting tells you who is using their seat. It does not tell you what the seat is being used for. Your IT SSO logs are even thinner - they tell you somebody authenticated. That is the floor of useful information, not the ceiling.

This is the part that surprises engineering leaders the most: AI productivity measurement is not a Claude problem or an Anthropic problem. It is a leadership problem. The vendors are not going to build the tooling that lets you grade their seats. That has to come from somewhere else, and it has to live close enough to the prompt layer to actually see the signal.

Attribution-first management for the Claude Code productivity era

The next generation of engineering management is not output-first. It is attribution-first.

Here is the shift, plainly: instead of asking "did this engineer ship a lot?", you ask "did the work this engineer's AI did connect to a project I am paying them to work on?" The first question can be gamed by any engineer with a Claude seat and a side project. The second question, asked honestly with the right telemetry, cannot.

A practical checklist for VPs of Engineering and Heads of AI auditing their own visibility right now:

• Can you tell, for any given seat in the last 30 days, what percentage of prompts referenced files or symbols that exist in your codebase?
• Can you see token spend split by repository, not just by user?
• Can you tell which model each engineer reached for on each task, and whether the choice was right-sized? (If your team is paying Opus prices for binary classification tasks, that is a separate fire.)
• Can you see the time-of-day pattern of usage and flag the seats where 60% of activity happens outside business hours, on weekends, or in suspicious bursts?
• If an engineer left tomorrow, could you reconstruct what their seat was actually used for over the last quarter?

If the answer to any of those is "no" or "I'd have to ask IT," the seat is effectively unmonitored. Not because anyone is being negligent, but because the visibility was never built into the tooling. Anthropic ships a coding agent. You are expected to ship the governance layer yourself.

This is the gap Tommbo was built to close. The product does three things, and all three matter here. It detects misuse of company LLM seats for personal or side work, including moonlighting. It measures actual engineer AI productivity at the prompt, token, and code-line level on real company repositories. And it helps right-size model selection so simple tasks stop running on the most expensive model in the catalog.

Claude makes everyone seem productive. Tommbo tells you who actually is productive. That is the entire pitch, and in the AI-leveled engineering org of 2026, it is the only pitch that survives contact with reality.

What this looks like in practice

Picture two engineers at a mid-size SaaS company. Both have Claude Code seats on the Team Premium plan, both ship roughly the same number of PRs per sprint, both get strong peer review feedback.

Engineer A's prompt history is dense with references to your billing service, your customer onboarding flow, the auth library you wrote in-house. Their tokens skew heavily toward business hours. Their model selection is mostly Sonnet, with Opus reserved for harder architectural questions. Their lines of code accepted map cleanly to sprint tickets.

Engineer B's prompt history is full of references to React Native patterns, Stripe webhooks, and a domain-specific term that doesn't appear anywhere in your codebase. Their heavy token days are Saturdays. Their model is always Opus, even for trivial refactors. Their commits to your repos are roughly half what Engineer A's are, but their seat usage is higher.

Both look productive on the velocity chart. Only one of them is being productive for you. Without attribution-level telemetry, you have no way to distinguish them. With it, the distinction takes about five minutes.

This is the actual job of engineering leadership in the AI era. Not chasing higher velocity. Not buying more seats. Not running another "are we using Claude enough?" survey. The job is making sure the seats you already pay for are pointed at the company's work, and that the engineers using them are getting better at the company's problems, not someone else's.

The good news: the data is already there. Every prompt sent, every token spent, every model chosen, every line accepted - it all exists. It just isn't sitting on the right dashboard yet.

The bad news, if you ignore it: your highest-paid engineer this year might be the one shipping the least of your roadmap. You won't know until they quit.

The dashboards aren't broken. They're just pointed at the wrong layer.

Start for free - no credit card required. Find out which of your engineers' Claude seats are actually working on your codebase, and which ones aren't.