AI-Assisted Development Without Chaos

AI Accelerates Development, But Governance Determines Whether It Reaches Production

Over the last two or three years, I’ve watched AI-assisted development move through distinct phases. First, general-purpose chat assistants like ChatGPT as a thinking partner. Then AI completions embedded in the IDE. Then, toward the end of 2025, the frontier agentic coding models arrived, and agentic development took a real leap in quality: harnesses, orchestrated agents, raw velocity.

What came next is the part I care about most. Code volume exploded, and so did the number of problems riding along with it. I remember one of the strongest engineers on my team telling me, early this year, that he’d stopped reviewing lines of code. He was reviewing how the AI had reasoned. There was simply too much code to check any other way.

That convinced many of us we needed governance. It started at the code level, moved up to design, and is now moving further upstream, into specs.

AI has made software generation dramatically cheaper. In my opinion, it has not made understanding, verification, or accountability any cheaper, and that gap is where governance has to live. So governing AI-assisted development cannot mean reviewing every generated line twice or archiving every prompt. It means governing the changes AI introduces, whoever or whatever produced them. In practice, that rests on five pillars:

1. Risk-based review gates
2. Provenance and traceability
3. Automated validation
4. Security and dependency controls
5. An updated Definition of Done

1. Treat AI as a Contributor, Not an Autonomous Developer

An AI system can propose an implementation, challenge a specification, generate tests, investigate a production issue, or review a pull request. It cannot own the business outcome or accept the consequences of a bad release.

That accountability remains with the engineering team.

The useful division of labor is therefore not “AI writes, humans approve.” It is “AI performs work, while engineers own decisions.” This matters more as agents get better: a weak assistant exposes its uncertainty, but a strong one silently resolves an ambiguous requirement and hands back something that looks finished, so “looks right” quietly becomes “is right.” Governance must force important assumptions into the open before they disappear inside a diff.

A workflow that separates spec, design, and implementation into explicit artifacts lets agents produce and critique each one, while humans keep the decisions that matter.

2. Build Review Gates That Focus on Risk, Not Authorship

AI-generated changes should not automatically receive more scrutiny because of their author. Human-written code can contain security defects, copied dependencies, and misunderstood requirements too. The useful question is not “Did AI write this?” but “What could happen if this change is wrong?”

A risk-based review policy considers factors such as:

• Whether the change touches authentication, authorization, payroll, financial data, or personal information.
• Whether it modifies a public API, database schema, infrastructure boundary, or permission model.
• Whether it introduces a dependency, changes a model or prompt, or affects an irreversible workflow.
• The blast radius, rollback difficulty, observability, and quality of automated evidence.

Low-risk, well-bounded changes may be eligible for automated approval when CI, end-to-end tests, ownership rules, and agentic review all pass. High-risk changes should retain human gates even if every automated check is green.

The safe way to get there is shadow mode: let the system record the decisions it would have made, compare them against human reviews, and only then hand it authority over a narrow, well-understood class of changes. This is human-in-the-loop by exception rather than by ritual. A human is pulled in when a security alert fires, a policy boundary is crossed, or the change falls outside the approved class. None of this leaves the pull request behind; it just asks the PR to carry more than a diff: the intent and design that make it reviewable at all.

3. Preserve Provenance From Prompt to Production

Provenance is often confused with storing every conversation an engineer had with a model. That creates noise, privacy concerns, and a compliance archive that few reviewers can use.

The objective is not prompt archaeology. It is decision traceability.

For each material change, teams should be able to answer:

• Which ticket, incident, or business objective initiated it?
• Which specification and design decisions define the intended behavior?
• Which models, agents, skills, or reusable instructions materially influenced it?
• Which engineer or agent signed each gate, under which risk policy?
• Which validations ran, with what versions and results?
• Which artifact was deployed, where, and how can it be rolled back?

That lives as structured metadata on the artifacts you already have: the issue, the spec, the commits, the pull request, the deployment record. Keep raw prompts only when reproducibility or a real regulatory need demands it.

Treat reusable agent instructions, your organizational skills, rules, and domain context as version-controlled assets with owners and reviews. Otherwise, the same change will behave differently depending on someone’s undocumented personal prompt.

4. Expand Automated Validation Beyond Traditional Testing

Unit, integration, and end-to-end tests remain essential. AI does not replace them; it increases their value because the volume and velocity of change are higher.

But traditional tests only cover part of the new surface. An AI-assisted pipeline should also validate:

• Whether implementation behavior matches the approved specification and design.
• Whether generated code contains fabricated APIs, dead paths, unsafe defaults, or unnecessary complexity.
• Whether visual models, workflow definitions, prompts, and configuration are syntactically and semantically valid.
• Whether non-deterministic AI features meet evaluation thresholds on versioned datasets.
• Whether accessibility, performance, localization, migration, and rollback requirements are satisfied.
• Whether the change produces the telemetry required to detect failure after release.

The key is independence: don’t let the same context author the code, write the tests, and declare success. Combine deterministic checks, a separate review agent, black-box behavior tests, and human judgment where it counts. For runtime AI features, tie prompt and model versions to offline evaluations and production traces, so a release gate means something and failures can be attributed to a version.

5. Strengthen Dependency and Security Governance

AI-generated software must never bypass the existing security pipeline. It should pass the same static analysis, secret scanning, dependency review, and signing as any other change.

Supply chain is the clearest example. Picture the everyday case: you open the laptop your company gave you, you hand a spec to an agent, and it gets to work. To hit the objective, it reaches for abstractions and pulls down whatever packages it decides it needs. Who checks that those packages aren’t the entry point of a supply chain attack? The agent doesn’t. It has no sense of a dependency’s history, its provenance, or whether that exact capability already exists inside your company. Security in an AI environment starts right there, at the first point of attack. So new dependencies have to be justified, pinned, scanned against vulnerability and license policy, and tracked in an SBOM, not taken on faith because the agent added them.

But supply chain is almost the sophisticated worry. There are more obvious ones. Right now everyone in the organization is building software. Nobody wants to wait for the engineering department; they just want to solve their problem, automate a task, ship a small tool. The trouble is that most of these people have no way to tell whether the agent is making the right calls on authentication, authorization, or the access checks that decide who can see what. These were the bugs we used to see in junior teams. Now they show up everywhere, because everyone is generating code.

Then there is corporate governance, which in many places has quietly collapsed. We gave agents open access so we could feed them all the context they needed, and that context sometimes included security tokens, even passwords. It is the same mistake as committing credentials in plaintext, or handing a third party the keys to company data. The difference is that this used to be harder, more controlled, or at least more obviously wrong: you didn’t casually point a test SaaS at the company data lake. Today people install a plugin in their harness and wire it to anything, source code and confidential data alike, whatever is convenient. The convenience of these tools is so seductive that nothing else seems to matter, as long as something gets automated.

The fix isn’t exotic: corporate code, customer data, and credentials shouldn’t flow into unmanaged models or personal accounts in the first place, which means a managed environment, identity-based access, short-lived credentials, and agents that get the minimum permissions the task requires. And the stakes are not abstract. All of this maps directly to data breaches, with real impact on your customers and your company’s reputation. There has never been more surface to get this wrong, which means there has never been more risk.

6. Redefine "Definition of Done" for AI-Assisted Development

A traditional Definition of Done quietly assumes the developer understands the code because they wrote it. AI breaks that assumption. When an agent produced the change, “it’s merged” no longer implies “someone understands it,” so the bar has to be explicit instead of taken for granted.

It helps to separate two moments that are easy to blur. The Definition of Done applies first, on your own branch, before the change is ever proposed for integration. This is where the engineer who drove the agent confirms that its decisions are sound and that the change meets the requirements it had to meet. That does not mean rereading every line; it means having a plain, human-readable summary of how those requirements were validated and which decisions were taken along the way, clear enough that the engineer can judge whether the approach was right. That validation is the author’s job, and it does not move downstream to the merge gate. The review gates from earlier decide whether an already-validated change can be integrated, and that is the point where human attention becomes the exception rather than the rule.

That summary never stands alone. It sits on top of the usual layers of security and behavior tests, unit, integration, and end-to-end, and together they are what provide real assurance: the tests prove the change behaves, the record of decisions explains why it was built that way. When a test fails, the failure and the reasoning behind it together are what let the engineer trace the root cause and improve the spec, so the next change starts from a better place.

Not every change needs the same signer, but every change needs evidence proportionate to its risk.

7. Govern Model-Driven and AI-Assisted Delivery Together

Enterprise applications are assembled from mixed artifacts now: source code, schemas, policy rules, prompts, retrieval sources, AI-generated components. And they keep moving that way. Low-code and visual platforms already let teams assemble behavior without hand-writing much code, and AI pushes it further, tailoring policies and workflows on demand by generating custom code behind the scenes. That generated code keeps the behavior deterministic instead of leaving it to a model at runtime, but it is still code no one wrote by hand or read line by line. Governing only the code you author creates blind spots.

Picture a policy generated on demand that changes what customers can do in production, with no code review because no human opened a pull request. The behavior changed; the diff nobody read. A model upgrade can do the same to accuracy, cost, or latency while the application around it sits still.

Governance should operate at the application-change level. One change record should tie every affected artifact — a generated policy, a visual workflow, a prompt — to the same intent, risk, evidence, and approval, so it travels through the same gates as hand-written code. This is where model-driven platforms earn their place: they provide the paved road, standard formats and common gates that make governance the default instead of an afterthought.

The goal isn’t to slow teams down. It is to make the safe path the fastest path.

Conclusion

AI has already changed the economics of software creation. The teams that benefit most won’t be the ones that generate the most code, but the ones that turn that output into small, understandable, testable, and reversible changes. That takes a shift in mindset: one delivery system, not a parallel process for AI; risk classified, not authorship policed; humans escalated to by exception, not stationed in front of every low-risk change.

What makes this urgent is what AI actually amplifies. It scales the output of every team, the ones with excellent judgment and the ones whose criteria are weaker, alike. Good governance is what raises the floor: it helps the second group decide better, not just ship faster, without slowing down the first. And it has to do this without killing exploration, because the real challenge here isn’t new. It’s the same tension we’ve always lived with: innovating versus standardizing to scale with quality.

That balance is a judgment call, and it always will be. AI provides the speed. Governance provides the confidence to use it.