Will AI be as successful in systems engineering as it is in programming?
According to Stack Overflow, four out of five programmers use an AI tool. At the analytics firm SemiAnalysis, programming accounts for more than half of Anthropic and OpenAI’s recurring revenue. No other profession comes close to these figures, least of all systems engineering.
Is that because SE is simply lagging behind and will soon catch up? Or is programming a special case? Anyone who wants to assess what AI is capable of in SE must examine which conditions create this special case and how many of them apply in their own environment.
Four Reasons for the Special Case
The Economist has outlined these conditions broken down into four factors: (1) the availability of training data, (2) the verifiability of the output, (3) the minimal amount of human interaction, and (4) the programmers themselves.
There is a vast amount of open-source code available online, and in some models it accounts for nearly one-fifth of the training data. No other professional field has voluntarily published its work for over two decades.
Compilers, unit tests, and CI pipelines provide feedback in seconds. This catches errors early and, at the same time, provides the input used to train a model. A test result is a Reward function.
The context of a programming task is embedded in the code and can be accessed via interfaces. And programmers switch tools every few years, usually without approval. Adoption usually happened from the bottom up: developers simply did what they thought was right and chose the tools they believed were the right ones.
However, distribution is not the same as productivity. In a A study by METR from 2025 Experienced open-source developers working with AI took 19 percent longer, but estimated that they were 20 percent faster. However, METR has since released an update, which describes how that is changing right now.
The Rest of Knowledge Work
Beyond coding, AI is growing fastest in areas where work is formulaic. Harvey, Clio, and Legora have doubled their combined revenue from legal tools to about one billion dollars within a year, while Sierra reached 200 million in customer service. These are impressive growth curves starting from very low baseline figures.
In contrast, the MIT's 2025 NANDA Report In contrast, approximately 95 percent of the AI pilot projects examined did not yield any measurable results. The pattern behind this is consistent: no public corpus for client files, no automated assessment of quality, and knowledge resides in people’s minds rather than in systems.
A Comparison of Systems Engineering Approaches
When evaluated against this framework, SE performs worse than programming on three factors, while opinions are divided on the fourth.
- Training data. For The code is on GitHub. That was probably the reason why Microsoft, back then, GitHub for $7.5 billion had purchased. For requirements, there is PURE, a collection of 79 public requirements specifications containing approximately 34,000 requirements. The rest is locked behind an NDA in DOORS modules, Cameo projects, and Excel spreadsheets. Public SysML models on an industrial scale are practically nonexistent. In this regard, SE is closer to a call center than to a compiler.
- Verifiability. The question has two parts. A machine is good at checking whether a requirement is clearly formulated. The INCOSE Guide for Writing Requirements provides the rules and tools such as Jama Connect Advisor or Raiqon They have been implementing them for years. Whether a requirement is correct becomes apparent during integration testing or in the field—often years later. Executable models are the exception. Where a simulation or a model checker can make a judgment, feedback is relatively quick, and that is where software engineering most closely resembles programming.
- Human interaction. The core of the work consists of negotiations between disciplines, suppliers, and regulatory agencies. This information emerges through conversation and is rarely written down in its entirety. When it is available in digital form, it is scattered across tools that are not interoperable. Yousef Hooshmand, Lead Architect at NIO, states in the Interview for SE-Trends precisely that as the actual obstacle:
„The speed and quality of product development depend largely on whether the necessary data is complete, consistent, understandable, and available across system boundaries.“
Yousef Hooshmand, Lead Architect at NIO
- The engineers themselves. The most critical factor. In a regulated environment, a tool whose defects could find their way into the product requires a basis for trust, such as tool qualification in accordance with ISO 26262 Part 8 or in accordance with DO-330. For a non-deterministic model, this issue remains unresolved. Added to this is IP protection, since specifications cannot be stored in a public cloud. And systems engineers don’t secretly introduce tools; they change the process. That takes longer. But whatever is introduced this way is here to stay.
What's Changing Right Now
Vendors fill this data gap with synthetic data and by hiring experts who feed their knowledge into models. This works well for requirement specifications, but hardly at all for established architectural models. Transcription is already helping with interactions today and making meetings machine-readable. This allows knowledge that previously never made it into the systems to be incorporated with little effort.
Developing an interest in verifiability formal methods A comeback. The combination of a generative model and a formal verifier breathes new life into the formalization of requirements. The model generates a proposal, and the model checker evaluates it deterministically.
The fourth factor has seen the least change. While work is underway on approval pathways for generative tools in security-critical toolchains, these are still a long way from being approved. Yuchao Luo describes in the Interview for SE-Trends, ...that Chinese teams assume an accuracy rate of 70 to 80 percent for AI-generated requirements and correct the rest through review, while European teams first require proof of correctness.
Assessing Your Own Situation
Instead of asking whether AI works in systems engineering in general, you can assess how many of the four factors are met in your own company.
- Data availability. How much of the requirements, models, and verification results from the past five years are available in a machine-readable format and linked together? If the answer is essentially “PDF,” then the issue is one of data, not AI.
- Oracle. For which artifacts is there currently an automated check—whether it’s a simulation, a set of rules, or a consistency check? That’s exactly where its effective use begins.
- Proportion of human input. How much work time is spent on research, drafting, and fact-checking, and how much on negotiating with people? Only the first part can be quantified, and it’s greater than expected.
- Permission. Can someone try out a tool without first obtaining approval? If the answer is no, there will be no bottom-up adoption. In that case, the rollout requires a person in charge with a budget and an assessment of the current state. Without these, decisions will later be based on gut feelings.
Conclusion
Systems engineering will not replicate the success of AI in programming. Neither the data landscape nor the industry’s regulatory caution is changing quickly. A leap in productivity across the entire discipline therefore remains unlikely.
Productivity gains arise in niche areas where automated evaluation is possible. These include requirement quality, consistency checks across model boundaries, test case derivation from formalized requirements, follow-up on coordination meetings, and similar activities. Here, there is a risk that Local productivity gains are lost on a global scale.
The bottleneck is not AI itself, but rather the availability of one’s own data and the question of who is authorized to implement a tool. Those who resolve these two issues will benefit even if the next generation of AI models falls short of expectations.
