Requirements as Code: closing the compliance vs coding loop
When requirements, test cases, and vehicle models live in the same codebase, everything changes - for engineers, for compliance, and for AI-assisted development.

Requirements as Code: closing the compliance vs coding loop
When requirements, test cases, and vehicle models live in the same codebase, everything changes - for engineers, for compliance, and for AI-assisted development.
The 80-20% efficiency problem - coding vs requirements
At a typical automotive OEM, only about 20% of engineering time goes to writing code. The remaining 80% disappears into documentation, traceability work, and keeping artefacts in sync across siloed tools. In safety-critical development, every requirement must link to a test case, every test case must trace back to an architecture decision, and every change must be auditable against ISO 26262 and ASPICE.
The way most teams handle this today - spreadsheets, separate ALM tools, PDFs, and manual hand-offs - creates exactly the disconnect that slows development and introduces risk. Maximilian Pabinger, co-founder at useblocks, describes what that looks like in practice: "The people building the software are doers. Requirements and traceability? Someone else handles that part. You end up with siloing - and that siloing causes real problems the moment an interface changes and nobody downstream knows about it."
Requirements as code: the useblocks approach
The solutions from useblocks close the requirements gap with their open-source framework, Sphinx-Needs, which treats every requirement, test case, and specification as a typed, linkable object - stored in Git alongside source code, validated on every build. Maximilian Pabinger explains: "We want to standardise the artefacts so they live as close to the source code as possible - thereby combining system of work with system of record. Links are created and checked automatically. Documentation becomes a build output, not a separate task."
When a test case is correctly annotated in Sphinx-Needs, it appears in the documentation automatically and traceability to standards like ISO 26262 is maintained as a natural consequence. The open-source framework also connects to legacy tools like DOORS and Jira via ReqIF so that existing artefacts and processes can migrate gradually. "Few projects start in a greenfield. You always have existing systems, existing formats. The goal is bidirectional traceability - and to bring that traceability closer to where the code actually lives." Maximilian Pabinger, co-founder at useblocks.
Vehicle as code: adding an executable layer with RemotiveLabs
RemotiveLabs adds an execution layer to having the requirements and artefacts closer to the code. RemotiveTopology virtualises the E/E architecture so test cases run against a reproducible, versioned vehicle model in CI. The vehicle signal database, ECU behaviour, and test recordings are all treated as code and text files - cloneable, runnable on a laptop or in a CI pipeline.
"When you treat the vehicle topology as code, you get the same properties you expect from software - version control, reproducibility, and the ability to run anywhere. That's what makes continuous integration across the full system actually possible with our tooling" explains Jan Kronquist, engineering lead at RemotiveLabs.

The result: A foundation for writing test cases with AI
Put requirements as code and vehicle as code together, and you get asingle, linked, version-controlled system where every requirement connects to atest case, every test case runs against a real vehicle model, and every changeis traceable end to end - automatically.
Sphinx-Needs keeps requirements, test cases, and code in one version-controlled system. Jan Kronquist, RemotiveLabs, shows how that connects to RemotiveTopology - so every requirement traces to a test case that actually runs against your virtual vehicle.
This is also what makes AI useful in safety-critical development. When requirements, virtual E/E architectures, and vehicle signal data are all linked objects in a graph, an AI agent can reason about the full system not just the code in front of it. "In the area of AI, this is especially useful. Impact analysis, traceability checks - these aren't only for humans anymore. Because all the information is linked, we built ubCode on top of our open-source model to turn that structure into a machine-readable intent layer agents can run on. In safety-critical projects, that lets AI actually understand the system and that creates a major advantage," says Maximilian Pabinger, co-founder, useblocks.
Check out the latest from us
Join the automotive rebels that #getstuffdone with RemotiveLabs!

.png)

.jpg)
.jpg)




