In early 2025, we worked with a client in the energy and defense sector to define a new proprietary versioning system for a Probabilistic Safety Assessment (PSA) product.
What made the project particularly interesting was not the technology itself, but the environment in which it was applied. Safety-critical software demands predictability, traceability, and controlled change. The challenge was never whether AI could generate code, but whether AI could become part of an engineering process where quality, auditability, and correctness are non-negotiable.
In a previous article, we explored the business perspective: how AI-DLC, combined with our Product Definition service, reduced the estimated implementation timeline from 5–6 months to roughly 3 months. This article looks at the engineering side of that story.
The project, briefly
Our client builds software used for reliability and safety analysis in nuclear environments. They needed a new model versioning system – a controlled history of safety-critical engineering models, with traceability, controlled access, and deterministic data handling. Until then, models moved between engineers manually, for example over FTP servers or USB sticks. Knowing which version was current, what had changed, and who made those changes depended largely on discipline rather than tooling.
We approached the project in two phases:
- Product Definition, where requirements, architecture, and implementation strategy were established;
- AI-assisted implementation, where those engineering artifacts became the foundation for accelerated development.
The Product Definition phase produced two complementary artifacts: a Requirements Specification covering functional and non-functional behavior, and a Technical Specification documenting architecture options and implementation variants. Together with high-fidelity prototypes, these became the direct input for the implementation phase: what needed to be built, and how it should be built.
Technical architecture: aligning with constraints, not replacing them
The system was designed as a web-based solution that integrates with the client’s existing components and workflows. To minimize migration risk and maintain compatibility with the existing environment, we deliberately built on the client’s established backend technology stack (.NET, Git, and SQL), while introducing a modern React-based frontend to improve the user experience.
The solution is fully self-hosted and can operate even in isolated, air-gapped environments. Every component, from version control to identity management, runs on the client’s own infrastructure, without relying on external cloud services.
At a high level, the architecture includes: a web application layer, backend APIs, a Git-based versioning mechanism, identity and access management via Keycloak, structured data storage using SQL, model files in JSON / CSV formats.
The implementation covered six functional areas:
- User authentication and identity management (Keycloak integration, role-based access control)
- Version history management (Git-based model versioning with full audit trail)
- Backend infrastructure and data management (API layer, SQL storage, file system handling)
- Model listing and operations (browse, filter, download, upload model files)
- Model comparison (diff between model versions, structured output)
- Deployment infrastructure and guidance (Docker-based setup, Nginx configuration)
How AI was used
AI was applied across both phases of the project. During product definition, it contributed to:
- accelerating requirement structuring from high-level inputs
- supporting prototype creation and iteration
- assisting in exploring architecture options
Before starting implementation, we ran an internal two-day hackathon, a focused session to test how far AI-assisted development could get on the critical parts of this system. The goal was not to build production-ready software, but to validate assumptions, identify limitations, and understand where AI could realistically accelerate delivery. The code was throwaway. The learning was not.
During those two days we generated approximately:
- 5,000 lines of code
- more than 350 prompts
- 20 hours of AI-assisted work to reach a partially functional system.
The outcome provided confidence in the approach and helped shape the implementation strategy that followed. Human engineers remained responsible for validating requirements, making architectural decisions, reviewing generated code and ensuring overall correctness.
A closer look: putting an engineering database under version control
Abstract claims about AI productivity are easy to make. Here is one concrete example from the project:
Take the capability at the heart of the system – keeping a complete, trustworthy history of every model. A model here is not a document or a flat file; it is a relational database. Git, the obvious choice for versioning and audit trails, is built for text: it cannot meaningfully store or diff a binary database. Two technologies the client wanted to keep – SQL Server and Git – simply do not speak to each other.
Rather than replacing either, the system bridges them. Whenever an engineer saves a version, the model database is decomposed into its tables, exported as plain-text CSV files alongside the schema, and committed to a Git repository – one commit per version, carrying the author, a title and a description. The history a user browses is, quite literally, the Git commit log. To open or compare a version, the system runs the process in reverse: it fetches the commit, rebuilds the database from the CSV and schema, and validates the reconstruction before the model is used.
Versioning could not live inside the database itself. The models are also used by an existing desktop application, so the database cannot be changed. History had to be kept around the database, not within it. And committing the database as a single binary file would have made Git blind: no readable differences, and a history that grows by the full size of the model with every saved version. Exported as plain text, Git’s delta compression stores each new version as only what changed, so even a long history stays compact and reviewable.
Two additional safeguards make this approach suitable for a regulated context. First, the export is culture-invariant. A number or date serializes identically regardless of the machine that produced it, so the same model always yields the same text, which is what makes a Git diff trustworthy. Second, every rebuilt database is validated against its source before it is trusted, so the round-trip can never silently corrupt a safety model.
The implementation is also a clean illustration of the division of labor with AI. The mechanical scaffolding (export and import routines, archive handling, caching, service wiring) is exactly the kind of code AI produces quickly and well. But the decisions that determine correctness – what “faithful reconstruction” means, where the validation gate belongs, how determinism is guaranteed – were defined and verified by engineers. AI compressed the plumbing; people owned the guarantees. Comparison is built directly on this foundation: to diff two versions the system rebuilds both and passes them to a dedicated comparison engine, returning a structured, reviewable result.
Impact
The main impact of AI on this project was not faster implementation. Instead of spending most of their time writing code, engineers spent more time defining requirements, validating assumptions, making architectural decisions, and reviewing generated output. For safety-critical software, that shift matters far more than productivity alone. It allows AI to become part of the engineering process without compromising traceability, predictability, or software quality.
AI tooling has moved fast since early 2025. The specific assistants and models we used then have already been superseded. The principles behind successful AI-assisted engineering, however, remain remarkably stable:
- invest in product definition before implementation;
- make architectural decisions before generating code;
- treat documentation as engineering input, not overhead;
- use AI to accelerate engineering not replace it
Talk to us
If you are weighing an AI-driven build in a regulated, mission-critical, or high-stakes domain, we are happy to compare notes about architecture decisions, engineering workflows and AI adoption in regulated environments.
STAY TUNED
Subscribe to our newsletter today and get regular updates on customer cases, blog posts, best practices and events.
