Most AI tooling in software engineering is still obsessed with the same narrow promise:

What if developers could write code faster?

Useful? Yes.

Big enough to reshape how engineering organizations are run? I am not convinced.

The more interesting problem starts before anyone opens an editor. By the time a developer asks an AI agent to write code, a bunch of bigger decisions have already been made: what the business wants, which roadmap item matters, which architecture is acceptable, which team owns the work, what risk we are willing to carry, and what we are choosing not to fix.

That is where companies quietly burn a lot of money.

Not because engineers type too slowly.

Because the organization does not really understand itself.

The Thing I Would Build

If I were building an AI company around software engineering today, I would not start with another “agent that creates PRs.”

I would build an engineering digital twin.

Think of it as a living model of an engineering organization. Not just the repos. Not just architecture diagrams. Not just Jira. A model that continuously connects the messy reality of how software actually gets built and operated.

It would understand the codebase, but also the pull request history, incident history, design docs, customer escalations, Slack discussions, team ownership, release history, on-call pain, technical debt, and the weird little dependency chains that everyone knows about but nobody has written down properly.

Every engineering org already has this information. The problem is that it is scattered across ten systems and a hundred people’s heads.

The staff engineer knows why the billing service is fragile.

The EM knows which team is overloaded.

The SRE knows which dependency causes the ugly incidents.

The PM knows which customers are blocked.

The senior engineer who has been around for six years knows why the migration keeps slipping.

But the organization does not have one coherent model that connects all of it.

That is the gap.

The Questions Nobody Can Answer Cleanly

Ask a typical engineering leadership team these questions:

• What is the highest ROI engineering investment we can make next month?
• Which services are most likely to cause the next Sev-1?
• Where are we creating technical debt faster than we are paying it down?
• If Alice leaves tomorrow, what breaks culturally or operationally?
• What happens to delivery if we postpone this migration by three months?
• Which customer escalations have the same architectural root cause?
• Where are two teams solving the same problem under different names?

You will rarely get a crisp answer.

You will get opinions. You will get dashboards. You will get someone saying, “Let me pull the Jira data.” You will get a planning meeting, then a follow-up meeting, then a spreadsheet that is already stale by the time everyone agrees on it.

That is not because leaders are bad at their jobs. It is because the data required to answer these questions was never designed to live together.

Git knows how the system changed.

Jira knows what people claimed they were going to do.

PagerDuty knows where the pain showed up.

Slack knows what people are worried about before it becomes official.

Design docs know why decisions were made.

Customer tickets know where the business is bleeding.

None of these systems knows the full story.

From Code Intelligence to Engineering Intelligence

The first wave of AI coding tools built context around code. Files, functions, tests, diffs, dependencies. That is a good foundation, but it is still too local.

An engineering digital twin would treat a service as more than a directory in a repo.

Take a payments service, for example. The model should know who owns it, who actually changes it most often, what systems depend on it, what incidents it has caused, which customers were affected, which roadmap items depend on it, what migrations touch it, and which design decisions explain why it looks the way it does.

Now the AI is no longer just answering:

Where is this function used?

It can start answering:

If we change this service, what organizational risk are we taking on?

That is a much more valuable question.

It moves AI from code assistance to engineering judgment.

What This Could Do in Practice

The product I have in mind would not sit around waiting for a VP to ask it a perfect question.

Every night it would look at what changed.

It would read the day’s merged PRs and notice architecture drift. It would see that two teams are building similar abstractions. It would connect a rise in customer escalations to a service that has also seen more rollbacks. It would notice that one engineer is reviewing almost every meaningful change in a critical area. It would flag that a migration is not just late, but now blocking three roadmap bets that were planned independently.

And then it would do something useful with that knowledge.

Not a 40-page report.

A short recommendation:

The identity service is becoming a delivery and reliability bottleneck. It has had three incident-linked changes in six weeks, 72 percent of meaningful reviews depend on two engineers, and two Q3 roadmap items now depend on the same migration. Recommended action: fund a four-week stabilization effort before adding new surface area.

That is the kind of thing engineering leaders need.

Not more charts.

Better judgment, with receipts.

Copilot Solves the Bottom of the Funnel

GitHub Copilot and coding agents help with the bottom of the software funnel:

Prompt
-> Code
-> PR

That flow is getting better quickly. It is also getting crowded quickly.

The bigger opportunity is higher up:

Business Goal
-> Roadmap
-> Architecture
-> Team Structure
-> Execution
-> Operations

This is where the expensive mistakes happen.

A company chooses the wrong platform abstraction and spends two years unwinding it. A migration gets delayed because it never looks urgent until it is suddenly blocking everything. A team keeps shipping features on top of a service everyone privately knows is unstable. Two teams build the same internal tooling because they use different language for the same pain. A critical system becomes dependent on one senior engineer, and leadership only realizes it after that person resigns.

None of these failures are solved by generating code faster.

In some cases, faster code generation makes them worse. It lets teams add more surface area to a system they already do not understand.

The Hard Part Is Trust

This is not a simple “connect all your tools and ask ChatGPT” product.

The hard part is trust.

If an AI says, “This team is creating too much tech debt,” people will rightly ask: based on what? PR size? incident count? delayed tickets? complexity growth? skipped tests? subjective Slack complaints?

If it says, “This migration delay will affect the roadmap,” it needs to show the dependency path. Which services? Which commitments? Which teams? Which assumptions?

If it says, “Alice is a knowledge concentration risk,” it needs to distinguish between healthy expertise and dangerous dependency.

That means the product has to be serious about evidence. It needs identity resolution across tools, permission boundaries, freshness, explainability, and a way to separate correlation from causation. Otherwise it becomes another dashboard people argue with.

The best version of this product would feel less like a chatbot and more like an analyst who has read every PR, every incident review, every design doc, and every planning thread, then gives you the shortest defensible answer.

Where the Wedge Might Be

The first version should probably not try to be “the brain of engineering.”

That is too broad and too vague.

A better wedge would be one painful use case where the existing process is obviously broken:

• Predicting incident risk from code and operational history
• Mapping knowledge concentration across critical systems
• Detecting architecture drift from PRs and design docs
• Finding duplicated platform work across teams
• Building a technical debt portfolio that is tied to business impact
• Simulating the delivery impact of delaying a migration

Any one of these could be valuable on its own. The deeper play is that each one adds more structure to the same underlying graph.

Over time, the product becomes the organization’s engineering memory.

That is much harder to copy than a better autocomplete model.

The Category

I think “AI that writes code” will matter, but it will not be the whole story. Code generation is becoming a feature inside every developer tool.

Engineering intelligence is different.

It asks a bigger question:

Can we give an engineering organization a reliable model of itself?

If the answer is yes, the product is not just helping developers move faster. It is helping leaders decide where speed is useful, where it is dangerous, and where the next dollar of engineering effort should go.

That is a much bigger prize.

The future of AI in software engineering is not only faster implementation.

It is better judgment at organizational scale.