AI-Generated Flight Code Under DO-178C

Language models write plausible C and Ada quickly. DO-178C doesn't care how code was written — it cares whether every line is required, reviewed and verified. That turns out to be the right frame for using AI in airborne software.

The tool-qualification question

Under DO-178C, a tool that could insert an error into airborne software — a code generator, for example — can only replace verification activities if it is qualified under DO-330. The required Tool Qualification Level depends on the software level and on what the tool can do wrong:

SOFTWARE LEVEL	CRITERIA 1 (CAN INSERT AN ERROR)	CRITERIA 2	CRITERIA 3 (CAN ONLY FAIL TO DETECT)
A	TQL-1	TQL-4	TQL-5
B	TQL-2	TQL-4	TQL-5
C	TQL-3	TQL-5	TQL-5
D	TQL-4	TQL-5	TQL-5

A qualified code generator is a Criteria 1 tool: TQL-1 at Level A. Qualifying a tool at that level means showing it behaves deterministically against its own requirements — which a general-purpose LLM, trained on data no one can enumerate and able to give different answers to the same prompt, cannot show. EASA's proposed Issue 03 concept paper says as much, capping large off-the-shelf models at TQL-5.

The practical conclusion: treat LLM-generated code exactly as if an engineer had typed it. The model can make you faster; it cannot take credit for any verification objective.

What that code still needs

Requirements first, code second

Every line must trace to a low-level requirement. LLMs are generous — they add helper functions, defensive branches and logging nobody asked for. Untraced code is extraneous or dead code; it either gets a requirement or gets removed. Prompting from the low-level requirements, rather than from a loose description, keeps the output traceable from the start.

Reviews

Source code is reviewed against the low-level requirements and architecture, the coding standard, verifiability, traceability, and accuracy and consistency. Fluent code is harder to review, not easier — it reads as correct. Review it as you would a new team member's first submission.

Requirements-based testing

Tests come from the requirements, not from the code, and cover normal range and robustness. An LLM asked to write tests for its own code tends to test what the code does rather than what the requirement says; write or review tests against the requirement.

Structural coverage

Requirements-based tests must reach the structural coverage the level demands: statement coverage at Level C; decision coverage as well at Level B; and modified condition/decision coverage (MC/DC) at Level A. Code with many generated branches can make MC/DC far more expensive to reach, which is one more reason to strip what isn't required.

Where AI genuinely helps

Drafting code from well-formed low-level requirements, for engineers to review.
Proposing requirements-based test cases and robustness cases to consider.
Writing SPARK contracts, so proof tools — rather than the model — establish properties such as absence of runtime errors (formal methods are addressed by the DO-333 supplement).
Pre-review: flagging untraced functions, missing tests or standards deviations before a human review, as a Criteria 3–style aid that can only fail to detect.

MORPH is built on that division of labour. It produces design, interfaces, code and tests as one artefact, then checks deterministically that the artefact is complete and that every test exercises a function the code defines — flagging gaps as LIMIT lines rather than hiding them. The certification credit still comes from your process, and design authority stays with your engineers.

Published · 28 September 2026 · All technical notes

AI-generated flight code under DO-178C