Nuclear’s Second Act: What the Energy Renaissance Demands from Systems Engineers

The last American nuclear power plant to enter commercial operation was Vogtle Unit 4 in Georgia, which reached full output in April 2024 after years of delays and billions in cost overruns. The project was widely read as a cautionary tale. The industry read it differently: as proof that the underlying appetite for nuclear baseload power had survived intact, and that the problem was execution, not physics.

Since then, the pipeline of advanced reactor programs has not slowed. It has accelerated. Kairos Power broke ground on its Hermes demonstration reactor in Oak Ridge. X-energy is under contract with Dow Chemical to deploy an Xe-100 high-temperature gas reactor at an industrial facility in Texas. TerraPower’s Natrium reactor program in Wyoming, backed by the DOE’s Advanced Reactor Demonstration Program, is in active construction. NuScale, despite its recent financial turbulence, demonstrated that NRC design certification of a small modular reactor was achievable. The market signal is unambiguous: nuclear is back, and this time it is being engineered by organizations with Silicon Valley capital structures and aerospace-grade engineering cultures.

That combination creates a specific kind of demand. Advanced reactor programs are not hiring physicists to rethink reactor theory. They are hiring systems engineers to manage complexity — to hold the interfaces between novel fuel designs and conventional balance-of-plant systems, between functional safety requirements and physical licensing constraints, between what the design team wants to change and what the regulatory docket will allow them to change. The workforce shortage in this area is real, and the tooling infrastructure to support it is only beginning to catch up.

What Makes Nuclear Systems Engineering Different

The surface-level comparison between nuclear and aerospace systems engineering is accurate as far as it goes. Both domains operate under formal safety regimes. Both require exhaustive requirements traceability. Both involve systems that cannot fail in ways that harm the public. A systems engineer who has spent a decade on satellite programs or aircraft certification will find the vocabulary familiar.

The depth of the differences emerges quickly in practice.

Certification timelines are not compressed; they are structural. In aerospace, certification programs run long, but the underlying assumption is that test campaigns, analysis, and design iteration proceed in parallel with regulatory review. The FAA expects to see test data. The NRC, by contrast, is conducting a legal and technical licensing process that produces a document — a Combined License (COL) or Construction Permit — with specific design commitments that are extremely difficult to retract or amend once made. The NRC’s Part 52 process was designed to reduce the risk of mid-construction design changes of the kind that devastated the first generation of nuclear builds. The effect is that requirements commitments made early in the process carry forward with a rigidity that aerospace engineers find disorienting. A change that would be a routine engineering revision in an aircraft program can trigger a license amendment request that takes 18 months.

The safety case is not a document; it is a legally binding argument. In defense programs, a safety case is a structured technical argument with evidence. In nuclear licensing, that argument becomes part of the Safety Analysis Report (SAR), which is submitted to the NRC and becomes part of the public record. Every requirement that feeds into a safety function must be traceable, not just within the design organization’s internal tooling, but in a form that can be examined, challenged, and adjudicated by regulators and intervenors. The traceability chain is not internal hygiene; it is a legal artifact.

DOE and NRC obligations do not merge. Programs receiving ARDP funding operate under DOE oversight that includes milestones, reporting requirements, and cost-share accounting obligations. Those obligations exist in parallel with NRC licensing, not as a substitute for it. A systems engineer managing requirements for a TerraPower or X-energy program must maintain visibility into both regimes simultaneously — understanding which requirements derive from DOE contractual commitments, which derive from NRC licensing commitments, and which exist in both with potentially different specifications. This dual-regime structure has no clean analogue in defense acquisition, where a single government customer typically owns the program.

The operational lifetime reframes everything. A commercial nuclear reactor is designed for a 60-year licensed operating life with the prospect of license renewal to 80 or beyond. Systems engineering decisions made during initial design need to account for maintenance access, component replaceability, and design-basis documentation that will be intelligible to engineers who have not yet graduated from college. This is not a theoretical concern. It has direct implications for how requirements are written, how design rationale is captured, and what version of a requirements management tool should be trusted to still be readable in 2085.

What Aerospace and Defense Engineers Bring

The practical effect of the talent shortage is that nuclear programs are hiring heavily from aerospace and defense. Lockheed, Northrop, Raytheon, and NASA alumni are visible throughout the advanced reactor workforce. Their presence is not accidental, and the knowledge transfer is real.

Model-based systems engineering literacy. The defense and space sectors absorbed MBSE methodology through programs like the F-35, James Webb Space Telescope, and various missile defense programs over roughly two decades. That institutional knowledge — how to construct a functional architecture, how to allocate requirements to physical components, how to manage interface definitions through SysML or equivalent formalisms — is scarce in the traditional nuclear industry. Advanced reactor startups benefit from hiring engineers who can stand up an MBSE environment without needing to invent it from scratch.

Hazard analysis depth. MIL-STD-882 and the broader defense safety literature on system safety analysis — FMEAs, fault trees, hazard tracking — maps reasonably well onto what the NRC expects in a Probabilistic Risk Assessment and a Failure Mode and Effects Analysis. Engineers with genuine depth in system safety (not just familiarity with the acronyms) are valuable in nuclear development because the underlying analytical approach is transferable.

Configuration management discipline. Nuclear programs require configuration management regimes that would not be out of place in a Class 1 medical device program or a space launch system. Aerospace engineers who have lived through a configuration audit on a flight program understand what that discipline demands operationally, including the organizational resistance it generates.

Where the Adaptation Is Hard

The aerospace-to-nuclear transition is not frictionless. The failure modes are predictable and worth naming directly.

Agile assumptions break at the safety-system boundary. Many aerospace software and systems organizations have adopted hybrid development models where iterative sprints coexist with formal requirements management. This works in contexts where the interface between the iterated component and the safety-critical system is stable and contractually defined. In nuclear programs, the safety classification of a given system is itself sometimes a live engineering question early in the program. Applying sprint-based development to a component before its safety classification is resolved creates downstream licensing risk that experienced nuclear engineers will flag immediately. The discipline of knowing where iteration is safe and where it is not is something aerospace engineers often need to rebuild.

Verification by analysis is not always sufficient. In space programs, much of the verification record is analysis-based because the operational environment cannot be fully reproduced on the ground. The NRC accepts analysis-based verification, but the evidentiary standards for those analyses — the qualification of codes, the documentation of assumptions, the treatment of uncertainties — are governed by Regulatory Guides and Standard Review Plans that have no equivalent in the aerospace world. An engineer who arrives confident in CFD or thermal-hydraulic modeling will need to understand which NRC-accepted codes apply to their analysis and why deviating from them carries licensing risk.

The change management reflex needs recalibration. Good systems engineers develop an instinct for when a design change is worth making. In nuclear programs, that cost-benefit calculation includes regulatory exposure in a way that has no direct analogue in aerospace certification. A change that is clearly better engineering may be inadvisable because it creates a divergence from a committed licensing basis that costs more to resolve than the engineering improvement is worth. This does not mean nuclear programs optimize for regulatory convenience over safety — it means the cost structure of the program treats regulatory stability as a tangible asset to be spent carefully.

The Tooling Gap Is Real

The requirements management infrastructure that nuclear programs inherited from the 1980s and 1990s — paper-based SAR sections, DOORS databases built to capture documents rather than models, spreadsheet-based RTMs — is not adequate for programs that need to maintain live traceability across a 20-year development timeline while interfacing with a regulatory process that expects auditability on demand.

The mismatch is not subtle. Programs that need to demonstrate, at any point in their NRC licensing interaction, that a specific design requirement is fulfilled by a specific design feature, which is verified by a specific analysis, which references a specific NRC-accepted code, need tooling that treats traceability as a first-class data model — not a report generated from a document set.

This is where newer tooling approaches are beginning to matter. Tools like Flow Engineering, which model requirements as nodes in a connected graph rather than as rows in a document, allow programs to query traceability relationships rather than manually assemble them. For a nuclear program preparing a response to an NRC Request for Additional Information, the ability to pull a complete traceability chain for a specific safety function — from high-level safety objective down through system requirements, design commitments, and verification evidence — in minutes rather than days is not a convenience. It is a competitive differentiator in a process where response deadlines are fixed and incomplete answers trigger additional review cycles.

The deeper advantage of graph-based requirements models in nuclear programs is longevity. A model that captures why a requirement exists — what safety function it serves, what regulatory commitment it satisfies, what design alternatives were considered — is a fundamentally different artifact than a spreadsheet row with a shall statement and a verification method. The former survives the departure of the engineer who wrote it. The latter requires that engineer to still be reachable in 2040.

The Honest Assessment

Nuclear’s second act is real, but it is not fast. The companies doing the most interesting technical work — Kairos, X-energy, TerraPower, Oklo, Terrestrial Energy — are building programs that will take a decade or more to reach commercial operation at scale. Systems engineers entering this space should expect long program horizons, regulatory interactions that test patience more than technical knowledge, and organizational cultures that are in the process of being invented rather than inherited.

The workforce demand is genuine and growing. Engineers who combine MBSE depth with the discipline to understand where formal sequential processes are non-negotiable — and who are willing to rebuild their assumptions about what “iteration” means in a safety-critical regulatory environment — will find sustained work and technically interesting problems.

The tooling situation is improving but uneven. Programs that invest early in traceability infrastructure designed for live regulatory interaction will carry that investment forward across the entire licensing timeline. Programs that defer tooling decisions until the first NRC interaction will spend the intervening years building technical debt that is expensive to resolve when it matters most.

Nuclear systems engineering is not aerospace with different physics. It is a discipline with its own regulatory epistemology, its own failure modes, and its own standards for what it means to have gotten something right. The engineers who do best in it are the ones who arrive with rigorous habits and genuine curiosity about where those habits need to change.