Software engineering has no shortage of metrics.
We measure:
These metrics tell us how software behaves.
Very few tell us how engineering thinking behaves.
As AI accelerates software development, I think that's about to become one of the biggest blind spots in engineering.
Imagine two engineering organizations.
Both deploy hundreds of times per day.
Both maintain excellent uptime.
Both have mature CI/CD pipelines.
On paper, they look nearly identical.
Then a major architectural decision arrives.
One team quickly aligns, identifies the important risks, documents assumptions, proposes rollback strategies, and executes smoothly.
The other spends weeks debating, rediscovers previous discussions, repeats old mistakes, and eventually ships something no one fully understands.
Our dashboards rarely capture that difference.
But anyone who's worked inside those organizations can feel it.
The biggest cost in engineering isn't always writing code.
It's reconstructing understanding.
Think about how often engineers ask questions like:
Every one of those questions represents engineering effort that has already been spent once.
We're paying for the same reasoning multiple times.
Imagine a new family of engineering metrics.
Not code metrics.
Reasoning metrics.
For example:
How many active architectural assumptions have been validated within the last twelve months?
How often do significant engineering changes produce the outcomes the team expected?
How long does it take a new engineer to understand why a critical architectural decision was made?
How often are major engineering decisions intentionally revisited as assumptions change?
How many decisions depend on information that exists only inside one engineer's head?
None of these exist in most engineering dashboards today.
I think they eventually will.
Large language models can generate implementations astonishingly quickly.
That means implementation itself becomes less interesting as a management metric.
Instead, organizations will increasingly ask:
Those are fundamentally different questions.
One of the most overlooked characteristics of elite engineering organizations is that they don't simply build software.
They improve the quality of future engineering decisions.
Every incident.
Every migration.
Every deployment.
Every outage.
Leaves the organization slightly more capable than before.
That capability is difficult to observe today.
But that doesn't mean it isn't measurable.
Imagine opening your engineering dashboard and seeing:
That dashboard tells me something very different.
It doesn't just tell me how my systems are performing.
It tells me how my engineering organization is evolving.
For decades we've optimized software delivery.
That's been the right focus.
But as implementation becomes increasingly automated, the next competitive advantage won't be shipping more code.
It will be building organizations that learn faster than everyone else.
That requires measuring something we've largely ignored.
Not software quality.
Not operational quality.
Reasoning quality.
The organizations that figure out how to observe, preserve, and improve engineering judgment will have a durable advantage long after code generation becomes a commodity.
I don't think the most important engineering metric exists yet.
But I think we'll know it when it measures not what our software did, but how much smarter our organization became because we built it.