The Rise of AI-Native Systems Engineering: How the Tooling Landscape Is Splitting in Two
Something has quietly happened to the systems engineering tools market over the last two years. Walk the floor at any INCOSE chapter event or defense systems conference and you will hear the same conversation: every major vendor now has an AI story. IBM DOORS Next has AI-assisted authoring. Jama Connect has introduced AI features for test coverage analysis. Polarion and Codebeamer have been adding generative capabilities to their review workflows. The demos look similar. The marketing language is nearly identical.
But engineers who use these tools every day are noticing something the press releases do not capture: the tools that started with AI as a core assumption work differently — not just faster — than the tools that added AI to existing architectures. The gap is architectural, and it is widening.
This article examines what is actually happening beneath the surface of the market, which industries are moving fastest, what early adopters are reporting, and where legacy platforms still hold ground that AI-native challengers have not yet taken.
The Architectural Fork in the Road
To understand why the split matters, you have to understand what AI needs from a data model to do anything genuinely useful in systems engineering.
Requirements are not documents. They are relational objects with dependencies, derivations, verification relationships, and change histories that propagate across a system architecture. When an AI model analyzes a requirement for completeness, ambiguity, or test coverage, the quality of its output depends entirely on whether it can see that relational context — or whether it is looking at flat text in a database that was originally designed to version Word documents.
Legacy systems engineering platforms were built in the document era. IBM DOORS, released commercially in the 1990s, was a revolution for its time: structured, versioned, linkable text objects instead of uncontrolled Word files. DOORS Next and the broader IBM Engineering Lifecycle Management suite extended that foundation into a web era. Jama Connect, Polarion, and Codebeamer brought more modern web interfaces and better collaboration features, but all of them share a foundational assumption: requirements live in a module or document structure, linked together through a layer of relational associations.
Adding AI to that model is possible. Vendors have done it. But the AI operates on extracted text, batch-exported data, or API calls that reconstruct context piece by piece. It cannot traverse the live graph of your system because there is no live graph. There is a document with links.
AI-native tools start from the opposite assumption: everything is a node in a graph. Requirements, functions, components, interfaces, test cases, hazards, decisions, and their relationships exist as first-class graph objects. An AI operating on that model can traverse your entire system architecture in real time, ask “what does changing this requirement affect,” receive a live answer rather than a cached report, and surface that answer in the context of the engineer’s current task.
This is not a marginal difference in user experience. It is a categorical difference in what the AI can do.
What Retrofitted AI Can and Cannot Do
To be fair to the legacy vendors: the AI features they have shipped are not useless. They represent genuine engineering effort and provide real value in specific contexts.
AI-assisted authoring — suggesting better requirement language, flagging ambiguous words like “appropriate” or “sufficient,” auto-generating acceptance criteria from requirement text — works reasonably well even on document-based systems. The AI needs only the text of the requirement and a library of style rules. Jama’s approach to flagging incomplete requirements and Polarion’s review automation fall into this category. They work. Engineers who use them report time savings on the authoring side.
What retrofitted AI struggles with is the analytical work that requires traversing system structure:
Impact analysis at scale. When a customer changes a top-level performance requirement, a human engineer using a legacy tool must manually navigate the link tree, expand derived requirements, find affected test cases, and check for orphaned verification items. An AI running on the same tool can automate the navigation, but the underlying link structure was built by humans, is often incomplete, and was designed for audits rather than traversal. The AI surfaces what the link structure says, not what is actually true about the system.
Gap detection across requirement sets. Identifying missing requirements — things the system needs to do that no requirement currently addresses — requires semantic understanding of the entire requirements space and the system architecture simultaneously. On a graph model, this is a natural AI task. On a document model, it requires exporting everything, running analysis externally, and reconciling results back to the source. Vendors are building these pipelines. They are slow, batch-oriented, and break when the data model changes.
Automated traceability maintenance. In a graph-native model, traceability is a property of the graph that is maintained continuously. In a document-native model, traceability is a separate artifact — the requirements traceability matrix — that decays the moment anyone changes a requirement without updating the links. AI can help rebuild these links, but it is fundamentally cleaning up structural debt rather than eliminating the source of that debt.
Which Industries Are Moving Fastest
The move toward AI-native approaches is not uniform across industries. Three sectors are significantly ahead of the field.
Defense and aerospace primes. Programs at Lockheed Martin, Northrop Grumman, Raytheon, and their equivalents are dealing with system architectures of extraordinary complexity — millions of requirements, thousands of interfaces, multi-decade lifecycles, and increasing pressure from program offices to demonstrate traceability without the army of systems engineers it currently requires. The Model-Based Systems Engineering (MBSE) mandate from DoD has provided organizational cover for tool modernization that would otherwise face institutional resistance. Several program offices are explicitly requiring vendors to demonstrate AI-assisted impact analysis capabilities in source selection.
Automotive Tier 1 suppliers. The shift to software-defined vehicles has moved automotive systems engineering from mechanical tolerances and FMEA documents to complex software-hardware integration requirements that look more like avionics programs than traditional automotive development. ISO 26262 and ASPICE compliance requirements are familiar to these organizations, but the tooling they used to manage mechanical systems does not scale to software-hardware integration at the complexity of a modern ADAS system. AI-native tools that can traverse from functional safety requirements through hardware design to software verification are attracting serious evaluation budgets.
Commercial space. New space companies — launch vehicle developers, satellite constellation operators, in-orbit service providers — have neither the institutional history with DOORS nor the patience for six-month implementation programs. They are greenfield organizations staffed by engineers who are accustomed to modern development tools and who will reject tooling that requires them to work against its grain. Several commercial space programs have moved directly to AI-native requirements management without a legacy migration step.
Medical device and industrial automation sectors are watching. They have not moved as decisively, partly because regulatory submission requirements create strong incentives to stay with tooling that has existing validation packages and FDA familiarity.
What Early Adopters Are Actually Reporting
Early adopter feedback is consistent enough to be signal rather than noise, with two important caveats: most programs are not willing to be publicly identified, and the results are program-specific enough that aggregate statistics would be misleading.
The reported benefits cluster around three areas.
First, reduction in the time to assess change impact. Programs consistently report that engineering change notices that previously required a working group and multiple days of manual impact analysis can now be assessed at a preliminary level in hours. The qualification here matters: the AI-generated impact assessment is a starting point for engineering judgment, not a substitute for it. But eliminating the manual traversal work is substantial enough to change program tempo.
Second, earlier detection of requirement gaps. Multiple programs have reported that AI gap analysis on their requirements sets surfaced missing or underspecified requirements that had been present in the baseline for years without being caught. In several cases, these were gaps that would have generated formal test failures or NCRs late in integration. This is the kind of value that is hard to quantity but easy to explain to program leadership.
Third, reduced onboarding time for systems engineers. This one is underreported in the industry press. AI-native tools that can answer natural-language questions about a system architecture — “what requirements does subsystem X derive from?”, “which interfaces have no verification method assigned?” — dramatically reduce the time it takes a new engineer to become productive on a program. In a market where experienced systems engineers are scarce, this matters.
The honest caveat from early adopters: AI-native tools are not yet winning on compliance documentation. Defense programs with formal CDRLs, space programs with FMEA report requirements, and medical device programs with FDA submissions all report that legacy platforms produce the right output formats for their review and approval workflows. AI-native tools produce better analysis but sometimes require additional effort to produce the specific document artifacts that program offices or regulators expect.
Where Legacy Incumbents Still Hold Real Advantages
Intellectual honesty requires naming this plainly: legacy platforms have genuine advantages that AI-native tools have not fully addressed.
Regulatory track records. IBM DOORS has been used on FAA-certified programs for decades. DOORS Next and Jama Connect have validation documentation that FDA reviewers recognize. Codebeamer has automotive safety qualification packages. These are not marketing claims — they are real risk-reduction assets for programs where the tool itself must be validated as part of the development process.
Enterprise IT integration. Large defense primes and automotive OEMs have invested substantially in integrations between their requirements tools and ERP systems, PLM platforms, change management workflows, and supplier portals. Legacy vendors have spent years building and certifying these integrations. Switching tooling is not just an engineering team decision — it requires IT, program management, and sometimes contracting office involvement.
Organizational knowledge. A program that has been running on DOORS for eight years has accumulated requirement structures, link conventions, and workflow patterns that encode hard-won systems engineering knowledge. The tool does not just store data — it stores the organization’s way of thinking about their system. Migration is not a data import; it is a knowledge reconstruction project.
Large-scale concurrent user environments. Some of the largest programs in defense and aerospace have requirements databases with hundreds of concurrent users across multiple sites and security domains. Legacy platforms have battle-tested architectures for this scale. AI-native tools are scaling up, but programs that need to support 500 simultaneous users across a classified network have legitimate reasons to pause.
The Graph-Centric Shift and Why It Matters Architecturally
The underlying technical move is from document-centric to graph-centric data models, and understanding this explains why some AI capabilities are structurally available to one class of tool and not the other.
In a graph model, every entity — requirement, function, physical component, interface, test case, decision, assumption — is a node. Every relationship — derives from, is verified by, is allocated to, contradicts, supersedes — is a typed edge. The entire system architecture is queryable as a graph. AI models running on this structure can do graph traversal natively, which means they can answer questions about the system that require following chains of relationships without batch exports or preprocessing.
Tools like Flow Engineering are built on this model from the foundation up. Their AI capabilities — automated traceability suggestion, impact radius computation, requirement quality analysis in context — are not features bolted onto a document store. They are natural operations on the underlying graph. When Flow Engineering’s AI surfaces that a change to a derived requirement has second-order effects on five verification cases and one interface control document, it is traversing the live graph in real time. The completeness and accuracy of that traversal depends on the quality of the graph — which is an engineering discipline problem — but the capability to do it at all is architectural.
This is why the framing of “AI features” misses the point. The question is not whether a tool has AI features. The question is whether the tool’s data model allows AI to do work that is qualitatively different from what human navigation through a document tree can accomplish.
Making the Investment Decision in 2026
Programs making tooling decisions today are operating in a genuine ambiguity. AI-native tools offer capabilities that legacy platforms cannot match architecturally. Legacy platforms offer compliance track records, integrations, and organizational stability that AI-native tools have not yet fully replicated.
The honest decision framework has four dimensions:
Program maturity and phase. New programs starting SRR/PDR cycles in 2026 are better positioned to adopt AI-native tooling than programs at CDR with ten years of requirements history in DOORS. Migration risk is real. For new programs, it is nearly zero.
Regulatory environment. Programs that must produce FDA submissions, FAA-certifiable artifacts, or formal CDRL deliverables in specific formats should evaluate whether AI-native tools can produce those formats before making a commitment. Several can. Not all do so with the maturity of legacy platforms.
Complexity trajectory. If your program will grow in complexity — more subsystems, more interfaces, more derived requirements — the architectural advantage of graph-native AI compounds over time. Programs with relatively stable, bounded scopes get less differential value from the architectural advantage.
Organization’s tolerance for implementation investment. AI-native tools require teams to think in graphs, not documents. This is a mindset shift as much as a tool change. Organizations that are already practicing MBSE, using SysML or similar formalisms, and staffed with engineers who are comfortable with relational thinking will adapt faster than organizations where systems engineering means managing a DOORS module.
The Honest Assessment
The bifurcation in the systems engineering tools market is real, consequential, and accelerating. It is not a marketing story — it is an architectural divergence with practical implications for what engineering teams can accomplish.
Legacy vendors are not standing still. Their AI investments are genuine, their customer bases are loyal for legitimate reasons, and they will continue to improve. But retrofitting AI onto document-centric architectures has a ceiling, and that ceiling is lower than vendors are comfortable saying publicly.
AI-native tools have real gaps — in compliance documentation, in enterprise integration depth, in battle-tested scale. These gaps are closing, but they are not yet closed for every program type.
The programs that will be best positioned in 2028 are the ones that evaluate this honestly today: not picking the most impressive demo, not defaulting to the incumbent, but mapping their specific program constraints against the architectural trajectory of each platform and making a deliberate choice. The split is real. The decision is yours to make with open eyes.