Most engineering hours do not go into building software. They go into understanding it. Read any honest engineer's week. A few hours on the new feature. The rest spent reading old code, tracing a flow through six services, asking someone in Slack what a queue is for, opening a run-book that was last edited two years ago, and squinting at a dashboard that almost answers the question.

This work is not lazy. It is not avoidable. It is the actual job. And it is mostly invisible on a budget line.

The hidden cost is not always downtime. It is the cost of understanding.

Where the time really goes

Onboarding a new engineer into a large system takes weeks, sometimes months. Nobody calls that an outage, but the bill is real. A migration project stalls for a quarter because no one is fully sure what the legacy service depends on. A simple refactor takes three sprints because the team is afraid to remove a method that "might still be used somewhere." An incident takes four hours, and three of them are spent forming and discarding theories.

These are not edge cases. They are the median week in any large engineering organisation. The cost shows up as slower delivery, slower onboarding, longer incidents, delayed modernisation, and quiet conservatism around change. None of it appears as a single number, which is why it rarely gets fought for.

The tax compounds

Every codebase carries this tax. It compounds with every team change, every architecture revision, every service added, every engineer who leaves with context in their head. Eventually a system reaches a point where the cost of understanding it is larger than the cost of running it.

That is when teams stop deleting old code, stop modernising, stop refactoring, and start adding more services on the side. The system grows because changing it is too expensive in human attention.

The shift

The point is not that engineers should read less or document more. People have been saying that for thirty years and it has not worked. The point is that the system itself can show how it behaves, if teams stop reconstructing it from fragments and start reading it directly.

When production behaviour becomes a first-class input — which APIs are alive, which methods run, which paths carry traffic, which dependencies are real — understanding stops being archaeology. That is the layer CodeKarma is building. Not more dashboards. A way to make the system explain itself.

Production never lies. The cost of not listening to it is on every engineering invoice, just not labelled that way.