The Rise of DX and LinearB Points to a Bigger Engineering Question

The growth of AI coding tools has given engineering leaders another reason to examine how software work is happening. Writing more code does not necessarily mean delivering more useful software. Faster output can also move pressure into code review or testing.

This helps explain the interest in engineering intelligence platforms such as DX and LinearB.

DX brings quantitative engineering data together with feedback from developers. It helps organisations study productivity, developer experience, and the effect of AI on engineering work. LinearB focuses heavily on the delivery process, using data from development workflows to identify delays and improve how work moves towards production. Both platforms are also expanding beyond basic activity metrics. They want to help leaders understand whether engineering is becoming more effective.

This is useful progress. For a long time, many technology organisations relied on whatever was easiest to count. Tickets completed, commits made, or hours worked could create the appearance of measurement without saying much about productivity.

Better engineering data provides a more credible view. Leaders can see where work is waiting, whether developers are facing repeated friction, and how changes to tools or processes affect delivery.

Recent LinearB research offers a good example of why this matters. Its analysis found that AI-generated pull requests waited much longer to be reviewed than unassisted work. Once reviewed, they moved faster, but far fewer were eventually accepted. The code was being produced quickly, yet the wider delivery system was struggling to absorb it.

Without that information, an organisation might conclude that AI had improved productivity simply because developers were generating more code. With it, a more accurate story emerges: output went up, but so did the load on review, and the net effect on delivered value is murkier than the raw commit count suggests. That is a genuinely useful finding. But it also points to a second, quieter problem.

Say the same organisation drills further into those stalled pull requests and finds that a disproportionate number of them belong to a system tied to a regulatory deadline six weeks out. The review delay stops being a developer-experience curiosity and becomes something a portfolio owner needs to know about today. Nothing in the pull request data itself says that, though. The engineering platform can tell you that reviews are slow and where. The delivery data may not contain enough context to show that this slowdown sits on the critical path for a compliance commitment. That connection depends on what information the organisation has integrated and how consistently it is maintained.

That gap is not a criticism of the tools. DX and LinearB are doing what they are built to do, and doing it well. The issue is that delivery metrics are produced inside engineering and consumed, often unchanged, by people who are not looking at the same picture. Engineering teams understand why a number moved. Executives see the same number and interpret it against a different set of priorities. Portfolio leaders may be working from another set of reports entirely. The organisation ends up with plenty of data and no shared view of what actually needs attention.

Closing that gap is a different kind of problem from measuring delivery more precisely. It means having somewhere that engineering reality and business priorities are recorded against each other in the first place — which system belongs to which initiative, which services carry known risk, who owns what — so that a delivery signal has something to attach to before it reaches someone outside engineering.

This is where a software catalogue or developer portal can add another layer. It can maintain relationships between services, ownership, and business initiatives, giving delivery signals more organisational context. Avalia's DX Hub is one example: built on the open-source Backstage framework, it works as a catalog of services, ownership, and dependencies that engineering teams keep current, with a layer on top that ties that catalog to business initiatives and surfaces AI-generated summaries for the people who don't want to read a raw dashboard. It sits downstream of tools like GitHub, Jira or SonarQube rather than replacing them — pulling structure out of what's already there instead of asking teams to instrument anything new.

Return to the stalled pull requests. LinearB-style analysis surfaces the delay and points to where it's happening. A catalog that already knows which system those PRs touch, and which initiative and deadline that system is tied to, is what turns "reviews are slow" into "reviews are slow on the one thing the board asked about last quarter."

The metric hasn't changed. What it's connected to has.

It's worth being honest about the cost of that connection. A catalog is only as current as the teams maintaining it. Stale ownership records or an incomplete initiative map produce a portal that looks authoritative and isn't. It also isn't a drop-in SaaS tool: Avalia positions DX Hub as something implemented with their specialists rather than self-served, which is a real trade-off — more setup, but arguably a more honest one than a dashboard that claims to explain business impact out of the box.

None of this means choosing between specialised engineering tools and a broader management view. DX and LinearB provide valuable signal about developer experience and delivery. A catalog that connects services to business context doesn't compete with that signal; it gives it somewhere to land. Buying one doesn't automatically produce the other. A tool can collect data and present strong insight.

Deciding which outcomes matter, how technology work connects to them, and who should act when the signals change is still work the organisation has to do itself.

Engineering intelligence is improving quickly, and that's a good thing. Companies now have better ways to see how software gets produced and where productivity is actually being lost. The next step is connecting those findings to the decisions the business needs to make.

Knowing what changed in engineering is valuable. Knowing what that change means for the business is what makes it actionable.