The AI Coding Illusion: Speed Without Governanc
Over the last year and a half, multiple publicly documented incidents have emerged where AI-generated applications shipped with missing authentication layers, exposed APIs, or hardcoded secrets. In one case reviewed by our team, a customer support platform exposed thousands of customer records because authentication logic was never implemented. The demo had worked perfectly. The code was clean. It was only when the system reached production that the architectural failure became apparent.
The issue was not merely that the code was insecure. It was that nobody involved fully understood the assumptions the system had inherited from the AI that generated it.
This has fueled a persistent narrative: AI-generated code is inherently less secure than human-written code. But that framing misses the actual crisis. Security engineers know that humans have always written vulnerable code. Most breaches are architectural or process failures, and developers at every experience level introduce vulnerabilities constantly. AI does not create insecure development cultures — but it dramatically amplifies them.
The real enterprise-grade challenge is not that AI makes mistakes. It is that AI accelerates software production faster than most organizations can preserve architectural coherence.
The Amplification Problem
AI-assisted coding has fundamentally altered development velocity. Tools like GitHub Copilot and Claude Code allow developers to generate complex, functional code blocks in seconds — and for product teams under pressure to ship, the productivity gains are real.
But the data reveals a widening gap between generation speed and the organizational capacity to govern what is generated. A large-scale empirical study published in ACM Transactions on Software Engineering found that nearly 30% of Python snippets generated by leading AI assistants contained measurable security weaknesses.1 A separate analysis by Veracode found that 45% of AI-generated code samples failed standard security tests.2 Researchers at Stanford and NYU found that developers using AI assistants not only wrote less secure code across multiple tested scenarios, but reported feeling more confident about their code's security than developers who had written the same code by hand.3
That last finding is the most consequential. The code compiles. It passes the tests. It looks clean. Meanwhile it quietly embeds SQL injection flaws, missing server-side validation, and weak cryptographic patterns into production systems — and the developer who shipped it believes they did their job well.
When developers act as editors rather than authors, their critical thinking atrophies. AI is an accelerator of existing engineering maturity: if your review processes are weak, AI will help you ship vulnerable code faster than ever before.
The Governance Crisis: Nobody Knows Who Approved the Logic
The conversation around AI coding is rapidly shifting from technical flaws to enterprise governance. The future issue is not merely, "AI wrote insecure code." It is: "Nobody knows who approved the logic."
Consider a common scenario. A developer prompts an AI to build an authentication module. The AI generates a syntactically correct implementation that uses an insecure JSON Web Token (JWT) handling pattern — failing to verify the token signature on the server side. The code passes the automated linter. The developer, trusting the AI and under deadline, merges the pull request. The reviewer, seeing clean and functional code, approves it.
Who is accountable for that vulnerability? The developer who wrote the prompt? The reviewer who assumed the AI's output was safe? The AI vendor? The answer is unclear — and that ambiguity is the real governance crisis.
In large distributed systems, these failures often emerge months later at service boundaries — when independently generated components make incompatible assumptions about authentication state, data validation, or retry behavior. By that point, the original developer may have moved on, the prompt history is gone, and the architectural decision that caused the failure was never consciously made by anyone.
AI also accelerates dependency sprawl by recommending unfamiliar third-party packages that developers may never have independently evaluated. In some cases, AI systems hallucinate libraries entirely — suggesting packages that do not exist on npm or PyPI. In these scenarios, malicious code can enter the dependency chain without the developer intentionally introducing it.
When AI produces four times more code than a human developer, traditional line-by-line human review does not scale. If your security model depends entirely on manual review, you have an artisanal process in an industrial environment.
The Deepest Problem: The Loss of Engineering Discipline
The greatest risk of AI-assisted development is not vulnerable code. It is the erosion of engineering discipline — the loss of clear reasoning, architectural authorship, and decision accountability inside complex systems.
AI increases output faster than organizations can reason about, govern, and coherently evolve their systems. The greatest risk of AI-assisted development is not vulnerable code. It is the gradual erosion of engineering discipline — the organizational capacity to know not just what a system does, but why it behaves the way it does, and who made each consequential decision.
Software becomes dangerous the moment nobody fully understands why it behaves the way it does. Governance integrity is ultimately the discipline of preserving that reasoning at scale.
The Sticky Strategy Approach: Constraints Create Speed
At Sticky Strategy, our team has contributed to software initiatives supporting organizations including American Airlines, Nike, and McDonald's — environments where a security failure is not a technical inconvenience, it is an existential event. We use AI extensively in our development workflow. But we have learned that extracting its value requires a fundamental shift in how engineering teams govern the code they generate.
Our approach rests on two principles that are simple to state and require genuine discipline to execute.
1. Architecture First, Automated Enforcement
The most dangerous thing an AI can do is make architectural decisions. Therefore, all code — whether written by a human or generated by an AI — must conform to a pre-defined, rigorously vetted architecture before it enters our codebase.
Before a single line of AI code is generated on a project, our architecture-first development frameworks enforce clear trust boundaries, authentication flows, and approved dependency lists. We do not rely solely on human reviewers to enforce this. We use architectural policy engines: at Sticky Strategy, an AI-generated pull request cannot introduce a new external dependency without triggering a mandatory, escalated architecture review.
Security failures increasingly emerge between generated components rather than inside them. By enforcing strict integration boundaries, we ensure that even if an AI generates a flawed function, the blast radius is contained by the architecture.
2. AI Generation in Focused Bursts
We do not let AI write entire applications or dictate broad logic flows. Instead, we use AI in highly focused, tightly constrained zones of generation. An AI assistant may generate a serializer, validation function, or test harness — but it never independently defines authentication flows, authorization policies, or inter-service trust contracts. Those decisions belong to the human architect.
By limiting the AI's scope to specific, well-defined micro-tasks, we drastically reduce the surface area for hallucinations and logic flaws. The human developer remains the definitive author of the system's reasoning. The AI accelerates execution; the human retains architectural authorship
The Bottom Line
AI coding assistants represent a genuine leap in developer capability. They are exceptional at scaffolding, pattern replication, and accelerating implementation details. The organizations that dismiss them will fall behind. But the organizations that deploy them without governance will eventually face a reckoning they cannot afford.
The future of software engineering will not belong to the teams that generate the most code. It will belong to the teams that preserve intentionality while operating at AI speed.