DEV Community: Amit Kochman

AI Code Without Governance Is Now a Legal Liability

Amit Kochman — Mon, 13 Apr 2026 12:26:39 +0000

AI Code Without Governance Is Now a Legal Liability

Your engineering team merged 200 pull requests last week. Half of them were written or heavily assisted by AI. You have no idea which half. And as of 2026, that's not just an engineering problem. It's a legal one.

The EU AI Act is live. The Defective Products Directive now classifies standalone software and AI systems as products under strict liability. The FTC has made it clear that companies bear full responsibility for algorithmic outputs regardless of who - or what - wrote the code. Using an AI coding assistant doesn't shift legal responsibility. It concentrates it.

Governance isn't a nice-to-have anymore. It's the difference between a defensible engineering org and a liability waiting to be triggered.

The Regulatory Walls Are Closing In

Let's be specific about what changed.

The EU AI Act entered into force in August 2024, with high-risk system obligations kicking in through August 2026 and 2027. AI systems used in safety-critical infrastructure, employment decisions, essential services, and regulated products now face mandatory conformity assessments, risk management documentation, and ongoing monitoring requirements.

But here's the part most engineering leaders miss: the Act's scope isn't just about the AI tool itself. It extends to the outputs that AI produces and the systems those outputs power. If your AI coding assistant generates code that ends up in a safety-critical application, the regulatory spotlight lands on you - the deployer - not on the tool vendor.

Meanwhile in the U.S., the enforcement picture is fragmenting fast. Colorado's AI Act takes effect in June 2026 with mandatory risk management programs. California's AB 316 explicitly bans the "autonomous-harm defense" - meaning you can't blame the AI for code it generated under your direction. Multiple state attorneys general are actively investigating AI-related compliance failures.

The regulatory consensus is forming from both sides of the Atlantic: if you deploy it, you own it.

You Own Every Line Your AI Writes

This is the concept that catches engineering leaders off guard: deployer liability.

The FTC has been explicit. Companies cannot claim ignorance about the capabilities - or failures - of the AI tools they use. If the risk of harm from AI-generated outputs is reasonably foreseeable, liability follows regardless of whether you understood the underlying model. You chose to deploy it. You're responsible for what it produces.

This changes the calculus for every engineering organization using AI coding assistants. Consider what "foreseeable risk" looks like in a codebase:

An AI assistant generates a database query that's vulnerable to SQL injection. It ships to production.
An AI-written authentication module skips edge cases that a human reviewer would have caught - if they had context on your organization's security standards.
AI-generated infrastructure code drifts from your compliance requirements across 15 repositories over six months. Nobody notices until the audit.

None of these are hypothetical. Research shows that AI-generated code carries security vulnerabilities at alarming rates, with some studies showing over 50% of AI-generated code failing security assessments. The models optimize for working syntax. They don't optimize for your engineering standards, your compliance posture, or your architectural decisions.

And under the new regulatory frameworks, "the AI wrote it" is not a defense. You deployed it. You merged it. You shipped it. It's yours.

The EU Now Treats Software as a Defective Product

Here's the development that should be circled in red on every CTO's calendar.

The EU's revised Defective Products Directive (Directive 2024/2853) takes full effect in December 2026. For the first time, standalone software, SaaS platforms, cloud-based services, and AI systems are explicitly classified as "products" under strict liability rules.

What does strict liability mean? Claimants don't need to prove negligence. They need to prove a defect exists and that it caused damage. That's it. No intent required. No negligence standard to meet.

Even more significant: if an AI system breaches mandatory cybersecurity or AI compliance requirements, that non-compliance creates a presumption of defect. Your regulatory posture is now directly linked to your product liability exposure.

For engineering organizations, this means the code running in production isn't just a technical artifact. It's a product that carries legal weight. Every merged PR, every deployed service, every AI-generated function is now part of your legal surface area.

Hope Is Not a Compliance Strategy

So how are most engineering organizations handling this? Honestly? They're not.

The typical approach looks something like this:

Confluence pages that describe coding standards nobody reads after onboarding week
PR reviews where overwhelmed senior engineers rubber-stamp AI-generated code because the backlog is crushing them
Tribal knowledge about security patterns that lives in three people's heads and was never written down
Periodic audits that happen quarterly, catch problems months after they shipped, and generate reports that collect dust

This worked (barely) when humans wrote all the code. It breaks completely when AI is generating code faster than humans can review it.

The PR bottleneck was already crushing teams before AI assistants multiplied code volume. Now you're asking the same reviewers to catch compliance issues, security vulnerabilities, and architectural drift in AI-generated code they didn't write, using standards documented in a wiki nobody maintains.

That's not governance. That's hoping nothing goes wrong. And regulators don't accept hope as a compliance strategy.

From Unenforceable Docs to Automated Proof

The shift that regulation demands isn't more documentation. It's enforcement. Specifically, it's the ability to prove - continuously, across your entire codebase - that your engineering standards are being followed.

This is exactly what codebase governance was built to solve.

Instead of relying on static documents and manual reviews, a governance platform like Pandorian turns your engineering standards into active, enforceable rules that run across every repository and every pull request - automatically.

Here's how it works:

Extract: Pandorian's Guideline Importer pulls your existing standards from wherever they live - Confluence, Markdown files, internal docs - and converts them from static text into structured, enforceable rules.
Compile: Those rules are compiled into logic that can be applied against real code patterns across your codebase.
Score: Every guideline is scored on focus, clarity, and enforceability - so you know which standards are actually actionable and which are decorative sentences that will never catch a violation.
Enforce: Standards run continuously as CI checks on pull requests and as broader repository scans. Violations are flagged with context. Fixes are generated where applicable.

The result: every AI-generated line of code is held to the same standard as every human-written line. No exceptions. No manual gates. No hoping a reviewer catches the problem.

Governance That Regulators Can Actually Verify

Regulation doesn't just demand that you have standards. It demands that you can prove compliance. Continuously.

This is where the gap between "we have a wiki" and "we have governance" becomes a legal distinction. Consider what regulators will actually ask for:

Risk management documentation: Can you demonstrate that your AI-generated code is subject to ongoing quality and security controls? With Pandorian's codebase-wide scans, you can show enforcement history across every repository.
Conformity evidence: Can you prove your code meets your stated engineering standards? Every guideline violation - and resolution - is tracked.
Audit trails: Can you show when a standard was introduced, how it was enforced, and what changed? Pandorian's guideline versioning creates exactly this record.
Differentiated enforcement: Can you prove that different risk profiles get different controls? Team and repo-level assignments let you enforce stricter standards where regulation demands it.

This isn't about checking a compliance box. It's about building the evidentiary foundation that regulators, auditors, and legal teams will require when they ask: "How do you govern AI-generated code?"

The Compliance Clock Is Already Running

The EU AI Act's high-risk provisions apply from August 2026. The Defective Products Directive hits in December 2026. Colorado's AI Act goes live in June 2026. California's autonomous-harm defense ban is already in effect.

If your organization is shipping AI-generated code - and statistically, it almost certainly is - governance isn't a 2027 initiative. It's a right-now problem.

AI code without governance is now a legal liability. The question isn't whether you need enforceable standards. The question is whether you can prove they're enforced before the first audit, the first incident, or the first lawsuit.

The organizations that will navigate this transition aren't the ones scrambling to write compliance docs after a regulator knocks. They're the ones that turned their standards into automated enforcement today.

AI Cut Engineering Leaders Out of the coding Loop. Now They’re Becoming Governors.

Amit Kochman — Sun, 29 Mar 2026 09:39:21 +0000

When AI becomes the coding workforce, human’s role becomes governance of the codebase.

For years, engineering leadership sat at the center of how software was built. Tech leads defined standards, staff engineers shaped architecture, and directors ensured consistency across teams. Through code reviews, design discussions, and mentorship, leadership maintained alignment between intent and execution. Systems evolved with a sense of direction because there was a clear layer responsible for enforcing it.

That model is quietly breaking.

Today, engineering leaders are being cut out of the coding loop. A junior developer can open an AI agent, describe a feature, and generate code in minutes. They often do not consult a senior engineer about structure or patterns, and increasingly, they do not submit to human review at all. At the same time, code reviews themselves are being absorbed by AI tools that flag issues, suggest improvements, and approve changes faster than any team can scale.

The traditional points of control where leadership once operated inside the coding loop are disappearing, not by design, but as a consequence of speed. What remains is a growing gap between leadership intent and system reality.

At first glance, this looks like progress. Teams are moving faster, developers are more autonomous, and bottlenecks are being removed. But beneath that acceleration, something more structural is happening. The mechanisms that once ensured coherence are eroding. Architectural intent is no longer consistently enforced, patterns begin to diverge, and different parts of the system evolve in isolation, guided by local decisions rather than global understanding. No single change breaks the system, but over time, the system loses shape.

This is not a failure of engineers. It is a failure of governance.

The underlying shift can be stated simply. When AI becomes the workforce, human’s role becomes governance. For individual contributors, this means less time writing code and more time directing it. For engineering leadership, the implication is more profound. If leadership is no longer inside the coding loop, it cannot be defined by oversight of individual decisions. It must be defined by control over the system as a whole.

To understand what that actually means in practice, consider a simple but high-stakes rule: no PII in logs.

Every organization has some version of this policy. It sounds straightforward, but in reality it is anything but. What qualifies as PII depends on context. An email address may be sensitive in one system but not another. IP addresses are considered personal data under GDPR but not always under other frameworks or regions. Healthcare identifiers fall under HIPAA. Financial data has its own constraints. Some enterprise customers introduce their own definitions that override everything else.

Now imagine enforcing this across a large codebase. Hundreds of services, thousands of developers, multiple regions, evolving compliance requirements. Logs are being written everywhere, often indirectly through shared utilities or AI-generated code. A developer prompts an agent to “add logging for debugging,” and suddenly sensitive data is being serialized into logs across multiple services.

How is this enforced today?

A guideline in a document. A note in onboarding. Maybe a lint rule for obvious patterns. Occasionally a comment in a code review.

None of these approaches scale. They rely on humans remembering context, interpreting ambiguous definitions, and catching issues locally. They do not adapt as definitions of PII evolve, and they cannot enforce the rule consistently across the entire system.

Codebase governance turns this into a system-level guardrail. Instead of hoping developers remember the rule, the system understands what constitutes PII in different contexts and enforces it everywhere logs are produced. It can detect violations across repositories, flag them immediately, and prevent them from spreading. As definitions change, enforcement updates globally. The rule is no longer advisory. It is enforced as part of how the codebase operates.

A second example is architectural boundaries.

Most organizations define some form of service ownership and boundaries. Certain services are not supposed to call others directly. Data access is meant to go through specific layers. Internal APIs are separated from external ones. These rules are critical for maintaining a clean architecture, but they are notoriously difficult to enforce.

In practice, they degrade over time. A developer under pressure bypasses an intended boundary for convenience. Another copies a pattern from an existing violation. AI-generated code reinforces what already exists, including the mistakes. Over time, the architecture becomes inconsistent, with hidden couplings and unclear ownership.

Again, enforcement today is local and reactive. A reviewer might catch a violation if they are familiar with the system. A design doc might describe the intended structure. But there is no mechanism that continuously ensures the architecture remains intact.

Codebase governance enforces these boundaries at the system level. It understands which services are allowed to interact, how data is supposed to flow, and where abstractions must be respected. Violations are not just discouraged. They are detected and corrected across the entire codebase. The architecture stops being an aspiration and becomes an enforced property of the system.

These examples highlight the core issue. Governance is not about writing rules. It is about enforcing them consistently, at scale, and in context.

Most existing tools were not designed for this.

Code reviews operate on individual changes. They depend on human attention and context, both of which are limited and inconsistent. Linters and static analysis tools operate at the level of syntax and predefined patterns. They can catch simple violations, but they lack the contextual understanding required for system-wide rules like evolving definitions of PII or cross-service architectural constraints. CI pipelines validate whether code builds and tests pass, not whether it aligns with the intended structure of the system.

Even AI code review tools, despite their sophistication, are still fundamentally local. They evaluate a change in isolation. They do not maintain a persistent understanding of the entire codebase, nor do they enforce rules across time as the system evolves.

This is why they fail at true codebase governance. They are not designed to understand the system as a whole, and without that understanding, enforcement cannot be consistent.

This is where codebase governance emerges as a necessary layer. Codebase governance is not an incremental improvement to existing tools, but a fundamentally different approach to managing software systems. It operates at the level where leadership actually needs control, which is the entire codebase rather than the individual change. It allows organizations to define system-wide standards and enforce them continuously, provides visibility into how the system evolves over time, and ensures that architectural principles are upheld even as the volume and velocity of code increase.

In effect, it restores the ability of engineering leadership to govern.

This shift also forces a redefinition of what leadership means in engineering. In the past, leadership was expressed through proximity to decisions. Senior engineers reviewed code, approved designs, and guided implementation directly. In the emerging model, that proximity disappears. Leadership is no longer about being involved in every decision, but about defining the rules by which decisions are made and ensuring those rules are enforced at scale. The measure of effectiveness is no longer how many decisions a leader personally influences, but how well the system maintains integrity without their direct involvement.

What is emerging is not just a change in responsibility, but a new category. Codebase governance addresses a problem that did not exist at this scale before. When code was written slowly and reviewed manually, informal processes were sufficient to maintain alignment. As code generation accelerates, that is no longer true. The only way to preserve coherence is through system-level enforcement, and that is precisely what defines codebase governance as a distinct layer. It sits above code review and static analysis, focusing not on whether code works, but whether it belongs.

The real risk in this transition is not that AI will produce bad code. It is that it will produce good code that does not fit. Code that works locally but violates system boundaries, introduces subtle inconsistencies, and accelerates short-term progress while undermining long-term integrity. These issues do not surface immediately. They accumulate, and by the time they are visible, they are expensive to unwind.

Engineering leadership is not becoming obsolete, but its traditional form is. If leadership is defined by reviewing code and guiding individual engineers, it will continue to be bypassed. If it is redefined as governance of the codebase itself, it becomes more important than ever. The question is no longer how to stay inside the coding loop, but how to maintain control over a system that no longer depends on it.

That is the role codebase governance is beginning to play, and it is where engineering leadership must evolve next.

How To Enforce Your Engineering Standards Across Your Codebase

Amit Kochman — Sun, 25 Jan 2026 10:21:14 +0000

You have spent years building a culture of excellence. You have written the playbooks, the Confluence pages, and the “Best Practices” READMEs.

But here is the hard truth: In the high-velocity era, your engineering standards are effectively invisible.

Traditional governance is failing because it relies on human memory to bridge the gap between a static document and a moving codebase. As your team ships faster – aided by AI that doesn’t know your specific rules – that gap becomes a silent generator of technical debt.

To maintain quality at scale, your standards must move from the wiki into the build.

Your Documentation is Where Guidelines Die

Most engineering standards follow a predictable, tragic lifecycle. They are born in a high-stakes meeting, documented in a sprawling wiki, and then promptly forgotten.

We call these “decorative sentences.” They sound noble – “Applications should store data securely” – but they do nothing to shape behavior at the keyboard. When a guideline is hidden in a tab that no one has open, it does not exist. It relies on a senior reviewer catching a violation in a 1,000-line PR, which is a losing battle against modern dev velocity

Your Standards Are Now Part of the Build

To scale, you have to stop treating standards like literature and start treating them like code. Pandorian can convert your existing documentation into live, enforceable guardrails that govern every commit.

We score your rules for focus, clarity, and enforceability, ensuring that “tribal knowledge” is transformed into active logic. This moves your engineering culture from a passive archive to a functional part of your development lifecycle.

Guardrails That Scale as Fast as Your Team

Pandorian operates as an immune system for your codebase, identifying architectural drift before it becomes permanent debt. Instead of waiting for a manual review to catch a sub-optimal pattern, the system automatically flags violations the moment they are introduced. This provides immediate feedback to the developer, ensuring that consistency is maintained without a single meeting.

This shift removes the “quality tax” usually paid by your senior leads. You are no longer hoping that a busy reviewer spots every deviation; you are building a platform that guarantees every line of code reflects your best engineering culture. It ensures your standards survive the “velocity era,” protecting your stack even when the pressure to ship is at its highest.

Stop documenting your expectations and start enforcing your reality.

Related Resources

The Platform: Explore how Pandorian transforms engineering culture into automated governance.

The Library: Access 200+ pre-built, AI-enforceable best practices in our Configuration Guidelines Library.

The Workflow: Learn how the Guideline Importer converts static documentation into active signals.

Best Practices: Read our deep dive into The Art & Science of Writing Great Engineering Guidelines.

Governance Strategy: Why high-growth R&D organizations are Versioning Guidelines Like Code.

Warning: Vibe Coding Is A Technical Debt Nightmare (And How To Stop It)

Amit Kochman — Tue, 20 Jan 2026 13:05:10 +0000

Your velocity charts are lying to you.

You enabled Copilot. You bought the Cursor licenses. On paper, your team is shipping faster than ever. But if you look closely at those Pull Requests, the illusion collapses. You aren’t seeing better code. You are just seeing more code.

As a Platform Lead, you are living through the “Vibe Coding” hangover. AI tools are incredible at generating logic that compiles, passes unit tests, and generally “vibes” with the problem. But they are terrible at adhering to the specific, rigid architectural standards that keep your platform from collapsing.

The problem isn’t just volume. It is misalignment. Your codebase is being flooded with logic that works in isolation but is fundamentally completely wrong for your organization.

Generative Speed, Architectural Blindness

Treat your AI coding assistants like the most enthusiastic, fastest junior developers you have ever hired.

They have read the entire internet, but they have zero context about your reality.

They don’t know that you strictly deprecated java.util.Random in favor of SecureRandom.

They don’t know that your fintech application requires fixed-point arithmetic for all monetary calculations.

They don’t know that you have a dedicated internal library for currency conversion and that external ones are banned.

So they hallucinate a solution that looks perfect but introduces a massive architectural violation.

If you rely on manual reviews to catch these specific nuances, you are fighting a losing battle. You are burning your limited political capital nitpicking “working” code because it violates a rule that only exists in a stale Confluence page or in your head.

To bridge this context gap, we’ve pre-built an extensive Configuration Guidelines Library featuring 200+ AI-enforceable best practices.

Quality Is Not a Linter Rule

The “Old Way” of ensuring quality was simple: run a linter for syntax, run a scanner for vulnerabilities, and trust senior engineers to catch the rest.

But “vibe coding” bypasses that safety net. It generates code that is syntactically correct but structurally flawed.

Standard tools can’t see the difference. They operate in isolation. A linter sees a valid SQL query; it doesn’t know that your organization mandates parameterized statements for every query to prevent injection. A scanner sees a standard HTTP client; it doesn’t know you require a specific internal wrapper to handle auth tokens correctly.

The quality drop isn’t noisy – it’s silent. It accumulates as “shadow debt” that you won’t find until it causes an incident.

Turn Your Standards into Signals

The solution isn’t to stop the AI. It’s to teach the AI your rules.

You need to take those “tribal knowledge” guidelines – the ones you find yourself typing into PR comments over and over – and turn them into active signals.

This is where Pandorian changes the game. Using our Guideline Importer, you can extract your specific engineering culture from static docs and turn it into an automated enforcement layer.

Pandorian doesn’t just check for generic errors; it enforces your specific engineering culture. It bridges the gap between a generic AI model and your specific codebase context.

Codify the Intent: Transform a vague feeling (“don’t use bad encryption”) into a precise, enforceable rule: “All cryptographic operations must use AES-256”.
Enforce Context: Signal immediately if a developer bypasses your internal Data Access Layer to hit the DB directly.

Reclaim Your Peace of Mind

When you automate this level of governance, you aren’t just speeding up the process – you are raising the floor of quality.

You ensure that the code hitting your production environment isn’t just “vibes” – it’s compliant, secure, and aligned with the standards you spent years building.

Let the AI write the boilerplate. Let Pandorian ensure it’s actually good.

Stop merging technical debt.

Book a Demo

[Book a Demo: See Enforced Coding Standards in Action])

Related Resources

The Library: Explore our full Guidelines Catalog to see 17 categories of engineering excellence.
The Shift: Read why we are moving from rules to reason in the age of AI.
Best Practices: Learn the art and science of writing guidelines that AI can actually follow.

DEV Community: Amit Kochman

AI Code Without Governance Is Now a Legal Liability

AI Code Without Governance Is Now a Legal Liability

The Regulatory Walls Are Closing In

You Own Every Line Your AI Writes

The EU Now Treats Software as a Defective Product

Hope Is Not a Compliance Strategy

From Unenforceable Docs to Automated Proof

Governance That Regulators Can Actually Verify

The Compliance Clock Is Already Running

Related Reading

AI Cut Engineering Leaders Out of the coding Loop. Now They’re Becoming Governors.

How To Enforce Your Engineering Standards Across Your Codebase

Your Documentation is Where Guidelines Die

Your Standards Are Now Part of the Build

Guardrails That Scale as Fast as Your Team

Warning: Vibe Coding Is A Technical Debt Nightmare (And How To Stop It)

Your velocity charts are lying to you.

Generative Speed, Architectural Blindness

Quality Is Not a Linter Rule

Turn Your Standards into Signals

Reclaim Your Peace of Mind

Book a Demo

Related Resources