Key Takeaways

  • Raw volume metrics punish efficient developers: Dan Bender notes that strong engineers routinely delete code to refactor systems, making gross code output an inverse signal of software health.
  • Token-spend leaderboards repeat decades of measurement errors: Kirby Montgomery observed portfolio companies ranking development teams by raw LLM token usage, confusing compute consumption with actual business throughput.
  • AI project generation triggers Little's Law: Jim Milbery cautions that AI assistants make starting initiatives frictionless, which inflates work-in-progress inventory and drags down delivery cycle times.
  • Elite technical leaders speak in commercial numbers: Montgomery emphasizes that top CTOs abandon technical jargon and report progress through unit economics, cost reduction, and feature ROI.

The Volume Trap from Lines of Code to LLM Tokens

Software investors have spent forty years searching for a simple activity proxy inside engineering teams. They keep picking metrics that measure waste instead of value. Jim Milbery pointed to Bill Atkinson's famous Apple anecdote, where Atkinson reported -2,000 lines of code after optimizing QuickDraw routines. Milbery also cited the line often attributed to Bill Gates: measuring software progress by lines of code is like measuring aircraft manufacturing progress by weight.

Dan Bender was direct about why these proxies backfire during hold periods: “In the end the best code is sometimes taking or oftentimes taking code away, refactoring and making something more efficient, more effective, upgrading, maintaining code, which often times means you delete lines of code. So if you look at the metric of lines of code, that's just a BS metric.” Rewarding lines of code creates bloated, fragile architectures that demand higher maintenance capital down the road.

Generative AI has refreshed this error under modern branding. Instead of tracking line counts or velocity points, management teams recently began tracking compute burn. Montgomery watched this exact misstep take root inside tech organizations: “Isn't it hilarious that only a couple months ago people had actual token spent leaderboards?” Tracking token volume rewards teams for throwing massive, unfiltered context windows at simple programming tasks. It celebrates infrastructure expense rather than shipped enterprise functionality.

Little's Law and the Work-in-Progress Explosion

When writing code becomes cheap, companies start too many projects at once. Milbery highlighted Little's Law, the operational theorem establishing that average cycle time equals work-in-progress divided by average throughput. When generative tools eliminate the friction of kicking off prototypes, backlogs explode with half-finished experiments.

This creates a specific risk during hold periods. Engineering organizations appear hyperactive on paper because initial commit counts rise. Yet overall release velocity slows to a crawl because the organization lacks the discipline to review, test, and integrate the surge of machine-generated code. Teams end up drowning in verification queues and merge conflicts, tying up senior engineering capacity without generating customer value.

Translating Engineering into Financial Returns

Sponsors cannot manage software assets through engineering jargon like story points or token consumption. Montgomery argued that the best operators drop the technical abstractions entirely when communicating with their boards: “The best tech leaders are the ones who have given up trying to explain how tech works. They've done a code switch and they speak in terms of, say for example, their financial counterpart.”

High-performing engineering chiefs frame their output around commercial accountability. Instead of debating developer velocity tools, they track how specific engineering investments alter the income statement. They quantify how platform stability reduces customer churn, how architectural cleanups lower hosting bills, and how specific product releases drive net expansion revenue. When technology leaders treat engineering as a capital allocation function rather than a cost center, sponsor alignment follows.

Why It Matters

Sponsors buying software companies often misjudge technical efficiency by relying on activity proxies supplied by engineering leadership. In an environment where AI tools commoditize raw code generation, valuation multiples depend heavily on engineering capital efficiency rather than sheer developer headcount. Funds that evaluate R&D through unit economics, delivery lead times, and gross margin expansion will price software risk accurately, while those relying on code production metrics will overcapitalize stagnant engineering shops.