Beyond Tokenmaxxing
Measure coding time in engineering hours, then separate what gets pushed from what lands.
Everybody’s talking about tokenmaxxing. And sure, every company is going to measure tokens — they’re one of the most important new resources of the decade, and you should know what you’re spending. But maximizing tokens is foolish in the same way maximizing lines of code was always foolish. It optimizes an input and calls it progress.
What you should actually care about is outcomemaxxing — outcomes tied to the business results you care about. In some contexts, like Sierra's outcome-based pricing for AI customer service, this is tractable: a resolved issue, a contained conversation, a satisfied customer. Engineering is harder. Measuring engineering work against quantified outcomes in a general-purpose, company-level way is still an open problem. While we aspire to develop better outcome metrics, we propose a useful proxy for engineering productivity in the agent era: coding time — the estimated human-equivalent time represented by code changes.
Engineering Hours
Coding time is measured in engineering hours because it’s a unit every leader has a baseline for: you know what a full week of a productive engineer buys you. More importantly, it’s a stable reference point for measuring leverage. As tools, models, and agents improve, the benchmark remains the same: a productive engineer working a forty-hour week. Measuring coding time in engineering hours lets you see exactly how much AI is amplifying each engineer, and how much work autonomous agents are contributing relative to a human baseline. If an engineer is regularly landing four hundred engineering hours of coding time in a forty-hour week, they’re operating at 10x leverage—or what we affectionately call a 10.0 Clickety Clack in Macroscope. As AI-native engineers become more effective and autonomous agents work continuously, those multipliers will only grow.
Pushed vs. Landed
One increasingly important distinction is whether coding time was merely pushed or actually landed. Pushed coding time is all coding time authored and pushed to git in a given period. Landed coding time is the portion that merged to your default branch in that period.
This distinction matters because coding agents have made authoring and pushing code a much noisier signal. Generating code is nearly effortless now and accessible to everybody in an organization. Landing code is a narrower filter. It is where meaningful judgment still happens — whether a change is correct, passes peer review, is worth shipping, and can hold up against everything else in the codebase. Landed coding time measures the work that survives that gate.
Across our customer base, coding time has increased dramatically over the last six months, coinciding with the rapid adoption of AI coding tools.
Pushed vs Landed Coding Time
Coding Time per developer per active day
- Across all engineers, pushed coding time normalized per developer-day increased ~1.5x since January, while landed coding time increased ~1.4x. However, landed share declined from ~51% to ~41%, suggesting that pushed coding time is growing faster than landed coding time.
- This trend is even more pronounced among the highest-coding-time engineers. The top 5% increased pushed coding time by ~2.6x over the same period while maintaining a stable landed share of roughly 55%.
The data suggests that AI coding tools are acting more as a force multiplier than an equalizer. The largest gains in coding time are accruing to engineers who already have the highest coding time, widening the gap between top contributors and the broader engineering population.
Macroscope customers can now see these metrics for their engineering organization on their dashboard, or via the Macroscope Agent.
In Macroscope
Macroscope automatically analyzes every commit across your engineering organization, estimates its coding time in engineering hours, and attributes that coding time to the engineers and agents responsible for it. You can track pushed coding time, landed coding time, and landed share, with rollups at the organization, team, engineer, and agent level. These metrics are now available to all Macroscope customers with Status enabled.
Contributors
M | 108h | 441h | 24% | 11.0 | 68 | 18 |
S | 212h | 386h | 55% | 9.7 | 52 | 17 |
J | 214h | 328h | 65% | 8.2 | 45 | 14 |
A | 223h | 279h | 80% | 7.0 | 39 | 12 |
N | 168h | 236h | 71% | 5.9 | 31 | 11 |
T | 121h | 191h | 63% | 4.8 | 27 | 9 |
No single metric can capture the full value of engineering work. A week spent deleting code, fixing bugs, or simplifying a system can be more valuable than a week spent shipping new features.
But as AI continues to transform engineering and product development, understanding leverage becomes increasingly important. Engineering hours provide a common yardstick for measuring that leverage for your team.
