Borrowed Discipline: Applying Regulated-Industry Guardrails to AI-Assisted Development

Once AI accelerates implementation, the bottleneck moves to judgment, evidence, and accountability. The code may appear faster now. The harder question is whether anyone can prove why it exists, who accepted it, and whether it satisfies the original intent.

The first article was about separating AI hype from engineering: faster code generation does not remove the need for human judgment. If you missed it, you could read it here.

Now the practical question becomes simple: how do we keep AI-assisted development under engineering control?

The focus here is engineering control, not compliance theatre.

In this article, “AI-assisted development” is used broadly: it includes AI-generated code, AI-assisted review, coding agents, and agentic workflows that can plan, modify, test, or prepare changes before a human accepts them.

The Product Still Has to Work

AI can draft, execute, summarize, test, and refactor. It cannot accept the result on the company’s behalf. A prompt is not a contract, and generated output is not evidence that the product does what it was supposed to do.

Customers do not buy “probably works most of the time.” Sales may talk in percentages, but declared functionality, data integrity, security, billing, and availability eventually become pass/fail questions.

If your customers are happy when you say, “we hope that probably 95% of our declared functionality might work as we expect, and we think that in your case 80% should fulfill your expectations, here is the bill, please sign,” then you are doing everything just fine.

For everyone else, faster implementation creates a control problem.

Regulated industries already have useful answers: approved requirements, named decision owners, traceability, independent verification, controlled changes, and evidence before release. A product team does not need every document, ceremony, or approval layer built around those practices. It needs the parts that stop generated work from becoming anonymous work.

That is borrowed discipline: use proven engineering practices to control AI-assisted development instead of inventing new ones just because AI entered the workflow. Scale the discipline to the product risk, not to the regulation it came from.

When AI Starts Driving the Process Without Guardrails

The main AI risk is not that the model is always wrong. It is worse than that. The model is often useful, often fast, and sometimes confidently wrong in places where the team stops looking closely.

Without engineering discipline, AI-assisted development tends to blur the line between generated output and engineering decisions. Requirements are drafted, code is generated, tests are created, documentation is written, and reviews are completed. The workflow keeps moving, but fewer people stop to ask whether the result still reflects the original intent.

The familiar problems follow:

• Requirements are drafted quickly, but nobody verifies that they still match the intended use.
• Code is generated quickly, but nobody can explain why some parts exist.
• Tests validate the generated implementation instead of the original requirement.
• Documentation describes what the code does instead of what the product is supposed to do.
• Reviews become superficial because professional-looking output is mistaken for engineering quality.

None of these failures are particularly dramatic on their own. Together they produce dead code, boilerplate, false coverage, and design decisions that nobody owns.

The Accountability Question Returns

Introduce AI into the lifecycle and an old question returns with new urgency: who is responsible?

In quality-management language, who is Responsible, and who is Accountable?

In regulated industries, the manufacturer remains accountable. In ordinary software, the same practical role is held by the company that builds, operates, and ships the product.

The model provider is a supplier with coding assistant being a tool. Accountability does not move upstream just because the tool became smarter.

The same principle applies outside regulated industries. For a medical device, the issue may be patient safety. For a booking system, it may be reliability, consistency, scalability, availability, and financial correctness. For a productivity app, it may be data integrity and user trust.

The risk profile changes. The accountability principle does not.

AI can accelerate code generation, help draft requirements, and shorten the path to working implementation. None of that proves the product is safe, reliable, reproducible, or ready to operate under real-world constraints. Humans still decide where the finish line is and whether the product has crossed it.

Borrow, Don’t Replicate Blindly

Borrowing from regulated industries does not mean replicating them wholesale. A mission-critical system needs stricter controls than an internal admin tool. A public SaaS platform needs stronger controls than a weekend prototype. A medical device has formal regulatory obligations that a consumer productivity app does not.

The discipline should match the engineering consequences of getting the product wrong. As product risk, customer impact, and data sensitivity increase, and recovery becomes more difficult, teams need stronger controls.

Not every AI-assisted activity justifies additional reviews, traceability, or documentation. That is expected. The goal is not to force AI into every workflow, but to make deliberate decisions about where additional discipline adds value and where it only adds overhead.

Every serious product team using AI should still be able to answer the same basic questions:

• What did we intend to build?
• Where did AI materially influence the output?
• Who reviewed and accepted that output?
• What evidence shows that the requirement was implemented and tested?
• What evidence shows that the code is needed at all?
• What happens when AI is wrong?

The level of formality should be proportional to the product risk. The discipline should not be optional.

The vocabulary already exists. Teams do not need to invent new names for intended use, validation, traceability, change control, evidence, or audit trails just because AI is now part of the workflow.

You do not need to replicate everything. Borrow what fits the product, adapt it to the project, and leave the rest behind.

Human Gates in the AI Lifecycle

Control has to become part of the workflow.

AI-assisted development needs human-in-the-loop and human-on-the-loop controls. People do not need to produce every artifact themselves, but they remain responsible for defining intent, approving decisions, reviewing evidence, and stopping the process when the output does not meet acceptance criteria.

The exact gates depend on the product. A prototype, an internal tool, a public SaaS feature, and a safety-critical product should not carry the same process weight, even if the gates are similar. Many gates can and should be automated, but automation does not remove human ownership of the decision.

For a non-regulated team, the adapted lifecycle can be much lighter, but the same gates still apply.

1) Requirements and Risk

AI can help draft user stories, software requirements, scenarios, and misuse cases. That saves time, but it does not validate intent.

The first gate is straightforward: does the scope still match the intended use, are the important risks visible, and are the acceptance criteria specific enough to verify?

By the end of this stage, the team should have approved requirements, initial risk controls, and the first traceability links.

2) Architecture and Data Classification

Architecture is where AI is often both useful and dangerous. Software architecture has probably generated more religious wars than technical consensus. Monoliths, microkernels, microservices, layered architectures – every generation discovers the One Correct Approach until the next one arrives. AI has simply learned to reproduce those opinions convincingly. Engineering still has to decide what actually fits the product.

Architecture still requires engineering judgment. Engineers decide whether the solution satisfies performance, availability, cybersecurity, maintainability, operating constraints, and data-classification requirements.

This stage should leave behind approved architecture decisions, interface contracts, data-flow boundaries, and mapped risk controls.

3) Design and Secure Coding

AI can draft design documents, sequence diagrams, coding checklists, secure-coding templates, and migration plans.

Engineers still have to make the decisions that shape the production system: concurrency rules, memory models, cryptographic policies, dependency constraints, and data-handling rules.

This stage should produce an approved design specification, a secure-by-design checklist, and toolchain policy.

4) Implementation

AI can generate baseline code, unit tests, migrations, scripts, and refactoring suggestions.

Implementation relies on deterministic controls. Static analysis, SAST, DAST where appropriate, dependency scanning, coding standards, coverage thresholds, and code review provide deterministic counterweights to probabilistic generation. Accepted code should remain traceable to requirements, risks, and tests.

5) Verification and Validation

AI can help generate tests, summarize results, propose edge cases, and draft defect reports.

Evidence, not generated tests, determines whether verification is complete. A generated test suite can still test the wrong thing very thoroughly. The question is not whether AI created the tests, but whether the evidence demonstrates that the intended use has been fulfilled.

This stage should produce test evidence, defect triage, residual-risk assessment, and release-readiness rationale.

6) Release and Post-Release Monitoring

AI can help summarize release notes, incident clusters, support-ticket patterns, and early root-cause analysis.

Release still requires engineering judgment. Humans decide whether residual risk is acceptable, cybersecurity posture is sufficient, documentation is complete, and the product is ready for release. AI may assist in monitoring, but humans adjudicate and act.

Discipline Is Only the Beginning

Borrowing discipline from regulated industries does not mean turning every software project into a regulated one. It means adopting engineering practices that remain valuable even when the regulations do not apply.

AI changes how software is produced. It does not change the need to define intent, review decisions, control risk, and demonstrate that the product behaves as expected. Those responsibilities still belong to the team that builds and ships the product.

The next practical question is how to prove that those controls actually worked. Once AI starts contributing requirements, code, tests, documentation, and design decisions, teams need a reliable way to connect those artifacts and explain how the final product came to exist.

That is where traceability becomes more than a compliance artifact. It becomes an engineering tool for understanding, validating, and governing AI-assisted development.

In the next article, we’ll look at how traceability changes when AI becomes part of the software lifecycle.