Writing Code Before Design Controls is Not Only Legal, It’s the Future of Product Development

Regulated software teams frequently ask us whether they’re allowed to develop in agile environments or use AI to generate design controls after code is written.

The answer is yes. Nothing in the FDA’s Quality Management System Regulation (QMSR), IEC 62304, or General Principles of Software Validation (GPSV) prohibits writing code ahead of approved design controls. These frameworks govern the state of the design record when a device is transferred to production and released, not the chronological order in which engineering work happens.

With AI coding tools continuing to transform product development, it’s imperative to understand the bounds of existing regulations and guidance. Let’s start with why we’re writing this post in the first place: because many people question whether they have to move up and down the V-model in a strict sequence.

Why teams might think design controls are required before development

Most of the confusion stems from two common misconceptions that lead teams to impose an unnecessarily strict development order.

Waterfall mandate. Teams sometimes interpret governing regulations as describing a waterfall process. They explicitly do not. They describe a linear flow to make the logic easier to explain. In fact, IEC 62304 Annex B states that the standard does not prescribe the order of activities, and AAMI TIR45 exists specifically to map agile practices to medical device software development.

Conflating procedures with regulation. Many teams have QMS procedures that describe a sequence of events in their development lifecycle. Those procedures may have been written years or decades ago, often shaped by the constraints of legacy tooling that required documents before work could begin. Over time, that procedure gets treated as the regulation. It isn't. Your QMS reflects how your organization chooses to comply; it is not the compliance requirement itself. If your procedures are more restrictive than the underlying regulation, that is a process design choice you can revisit and modify.

Companies already routinely write code before design controls

Established manufacturers regularly take ownership of software developed before any design control framework is applied. They do so in several ways:

• Acquiring a startup whose quality system is less mature than the acquirer's. The code already exists, and the acquirer reconstructs the design history under their QMS afterward.
• Licensing or acquiring an asset from a university or research lab, where software was developed in an academic setting with no design controls at all.
• Incorporating SOUP and open-source components, which were never developed under the company’s design controls and are qualified retrospectively.
• Doing internal feasibility and proof-of-concept work, which sits outside the design control boundary until development is formally initiated.

In every case, regulators do not ask when the code was written. They ask, before release, whether a team has defined the inputs, verified the outputs against them, established traceability, analyzed risk, and formally reviewed the design.

What the regulations actually say

Quality Management System Regulation (QMSR): As of February 2, 2026, FDA's QMSR amended 21 CFR 820.30 and incorporates ISO 13485:2016 by reference, so design and development requirements now sit in ISO 13485 clause 7.3. This outlines in detail the procedures and evidence a company must produce during its development process. It does not dictate any sequencing of those materials. However, some companies may find that their internal procedures have defined a rigid sequence for design and development. Such a restriction should not be confused with a regulatory restriction, which does not exist.

IEC 62304. The standard accommodates software not built under its lifecycle. Clause 4.4 (added in Amendment 1, 2015) provides a route for legacy code developed before 62304 applied to be brought into conformance through risk-based gap analysis, gap closure, and documented rationale rather than recreating the full lifecycle. This notably does not require every line of design documentation to be written only after design controls exist. In fact, TIR 45 was explicitly created to help teams adhere to 62304 while working in an agile framework.

GPSV. Teams often cite this 2002 FDA guideline as the source of the "design before code" requirement. Page 19 states that a formal design review should be conducted "before moving to implement the design." Read in isolation, this sounds like a hard gate: design, review, then code.

But Section 5.2 of the same document explicitly rules out that interpretation and frames the entire lifecycle discussion. The text is "not intended to prescribe any particular software life cycle model or any particular order in which tasks are to be performed." GPSV goes on to reinforce this in practice: “Portions of the design can be approved and released incrementally for implementation.” And further: “Most software development models will be iterative. This is likely to result in several versions of both the software requirement specification and the software design specification. All approved versions should be archived and controlled.”

The document is describing the logical relationship between design and coding within an approved iteration, not a waterfall gate across the project. There is no prescribed development sequence. Exploratory or prototype code predating a formal design specification is simply upstream of the first approved iteration. The obligation is not that design review must gate code. It is that approved artifacts go under configuration management, and that the design ultimately submitted for validation has been verified, formally reviewed, and traced to requirements.

Computer Software Assurance (CSA) and GAMP 5 Second Edition. These two Guidances further promote modern, iterative development over excessive gating. The FDA’s CSA actively discourages gated documentation-for-its-own-sake and rewards risk-based, ad-hoc testing. GAMP 5 Second Edition explicitly incorporates iterative, incremental, and agile software development, and has never required waterfall.

How to create a compliant release

Teams still have a clear path to compliant releases within these regulations, regardless of the order of their design controls or code. It is permissible and possible, as long as you do the following before a production release:

• Capture design inputs (requirements) and intended use
• Verify that the design outputs, the code and its artifacts, meet those inputs
• Establish traceability among requirements, design, code, and tests
• Re-examine the risk analysis for new or changed hazards
• Place all approved versions of specifications under configuration management
• Conclude with a formal design review before implementation is finalized and transferred

Why this matters in the agentic era

AI coding tools change the economics of the exploratory phase. Teams can generate substantial working software in hours, long before requirements and design specifications are final. The frameworks permit this; what they don't permit is letting the tool decide the requirements. That judgment belongs to the people who own the product's intended use and its risk. The hard requirement here is the discipline to formalize the design record before release: documenting inputs, verifying outputs, establishing traceability, and re-examining risk.

Do that work by hand, and you erase every hour the AI saves. Do it with tooling that produces traceability and documentation as a byproduct of the work itself, and you keep the speed and arrive audit-ready. That is how we think about continuous compliance and accelerating the product development process.

‍

This article is informational and is not legal or regulatory advice. Confirm applicability with your own regulatory and quality functions.