“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”
Dr. Ian Malcolm – Jurassic Park
The Speed Illusion
Dr. Ian Malcolm’s famous warning in Jurassic Park feels remarkably prescient for the current state of software development. Today, generative AI allows us to spin up a functional application in a single weekend. But just because we can build and deploy at breakneck speed doesn’t mean we should launch it on Monday.
The industry is currently facing an explosion of what we might call “comprehension debt.” Developers and non-technical founders alike are shipping code that looks professional and functions correctly on the surface. Yet, beneath that surface, no one fully understands the architecture. According to recent analyses on AI-assisted coding, the volume of code being pushed has skyrocketed, but the quality and maintainability are trending downward.
To prevent a looming crisis of unmaintainable, insecure software, the industry must fundamentally shift how it views AI-assisted development. We have to move away from treating rapid prototypes as final products, and instead, empower a new generation of technical gatekeepers to oversee the process.
The “Prototype to Product” Trap
AI tools offer an incredible advantage for extreme rapid development – specifically in prototyping. These tools allow us to quickly see how software might function and how end-users, whether internal or external, will actually interact with it.
However, this speed creates a dangerous “illusion of correctness.” When the C-suite or an investor sees a fully functioning prototype built in a matter of days, the immediate assumption is often that the work is finished. They are thrilled by the cost and time savings, but they fail to see what is missing: the security protocols, the architectural efficiency, and the scalable foundations.
To navigate this, the “prototype versus product” conversation must occur before a project even begins. Technical leaders must ensure that business stakeholders clearly understand the limitations of a prototype. It is a necessary and highly effective step, but organizations must commit the time and budget to take that prototype, tear it down, and rebuild the work at a higher, enterprise-ready quality. Without that crucial step, technical debt compounds immediately.
To navigate this, the “prototype versus product” conversation must occur before a project even begins. Technical leaders must ensure that business stakeholders clearly understand the limitations of a prototype. It is a necessary and highly effective step, but organizations must commit the time and budget to take that prototype, tear it down, and rebuild the work at a higher, enterprise-ready quality.
Yet I have lost count of how many times I have had to make a prototype ready for release with only a few days or weeks because someone in management didn’t realize that these are two different types of designs.
(Unknowingly) Deliberately Building Tech Debt
Without that crucial step, technical debt compounds immediately. Without it, we get pushed into the messy quadrants of tech-debt, where we both have to ship immediately, and we don’t know about design patterns.
This is where understanding Martin Fowler’s Technical Debt Quadrant becomes vital for any organization leveraging AI to build software. Fowler famously categorized technical debt along two distinct axes: whether the debt is incurred Deliberately or Inadvertently, and whether the approach is Prudent or Reckless.
When an experienced technical team uses an AI tool to rapidly build a prototype to secure funding or validate a market, they are operating in the “Deliberate and Prudent” quadrant. They are making a calculated, strategic business decision: We know this AI-generated code isn’t scalable or perfectly secure, but we must ship this prototype now, and we have a budget and plan to refactor the consequences later. The debt is known, documented, and manageable.
The Underlying Danger
The danger of the generative AI era is that it violently pushes teams into the “Reckless” quadrants. When a non-technical founder uses AI to build their entire product in a weekend and pushes it live to customers, they fall squarely into the “Inadvertent and Reckless” quadrant. They don’t know what a design pattern is, they don’t understand architectural layering, and they have no idea how much invisible debt they have just incurred. They aren’t strategically choosing to take on debt; they simply don’t know any better.
Similarly, when leadership sees a working prototype and demands the engineering team ship it as the final product to save time, they force their developers into the “Deliberate and Reckless” quadrant. The team knows the code is a fragile mess, but the business prioritizes the immediate release over the structural integrity of the application.
Generative AI doesn’t just write code; it generates technical debt at an unprecedented velocity. If leadership does not recognize which quadrant their AI-generated codebase currently lives in, the inevitable “interest payments” on that unmanaged debt -manifesting as endless bugs, security breaches, and paralyzed feature development – will eventually bankrupt the project.
The New Gatekeepers: Blending Product and Engineering
Historically, the sheer time and effort required to write code acted as a natural filter for software development. Because building a new feature took weeks or months of dedicated engineering resources, teams were forced to rigorously prioritize. Ideas were scrutinized, requirements were debated, and only the most valuable concepts made it into the final codebase. That inherent friction protected applications from uncontrolled scope creep.
This is something that software engineers learn over time. We move from building, because we’re excited to build, to using prudence because we learn that some features aren’t used (and we were a wasted resource) and all become tech debt we have to manage. This is an education which can only be learned by experience, is part of what takes us from novice to experienced.
Today, generative AI has effectively removed that friction. The initial successes haven’t had to be maintained for months or even years. And since the bottleneck in software development is no longer the physical act of writing code; it is the decision of what to write in the first place. AI coding tools have empowered almost anyone to prompt a feature into existence, which sounds like a democratization of development.
However, in practice, it often leads to unchecked scope creep and massive architectural bloat. If anyone can build a feature in an afternoon, the temptation is to build everything, resulting in a chaotic, directionless product.
The Need for a Gatekeeper
Someone has to step up as the gatekeeper of product design and feature implementation. In most organizational structures, the Product Manager is the most logical place to start. They are positioned at the intersection of business strategy, user experience, and technical execution.
However, there is a distinct danger in this dynamic. If a Product Manager is too divorced from the realities of software development, and just viewed as a manager of the coders, trying to get them to add every new feature a customer or senior manager has suggest – they may inadvertently become the primary source of unnecessary new features.
When a non-technical leader sees AI as a magic wand that makes development “free” and instantaneous, they are far more likely to demand endless additions without understanding the compounding technical debt those additions create. For a Product Manager to successfully act as a gatekeeper in the AI era, they need to possess a level of technical training and architectural understanding that many currently lack.
To bridge this critical skills gap, the industry is poised for a significant structural shift. We will hopefully see a rising trend of experienced software engineers being transitioned into both Product and Project Management roles. An engineer-turned-PM brings an invaluable perspective to the table: the architectural foresight to look at a proposed feature and say “no,” not because it cannot be built, but because it shouldn’t be built. They understand the long-term maintenance costs that invisible AI-generated code will inevitably incur.
Simultaneously, existing business-minded Product Managers must aggressively upskill. As highlighted in recent industry discussions on the evolution of technical Product Managers, PMs do not necessarily need to write production code, but they must understand system architecture, data flows, and the limitations of probabilistic AI models. The best Product Managers are already doing this by closely shadowing and learning from their senior software engineers to ensure they can work seamlessly with technical teams.
Moving forward, the ideal workflow for modern software development requires a strict division of responsibilities. Non-engineers and business stakeholders should absolutely be utilized to generate ideas, define business requirements, and conceptualize user journeys. But when it comes to execution, technical professionals must be the ones doing the actual development and AI prompting. A skilled technical developer can build exponentially faster and more efficiently with AI, while still keeping the project firmly grounded in fundamental software engineering practices. They ensure that the architecture remains sound, that security protocols are followed, and that the scope of the project does not spiral out of control.
Redefining Code Bloat in the AI Era
As AI accelerates the pace of development, the industry must entirely rethink how it defines and measures software bloat. Code bloat has always been a notoriously difficult metric to quantify. For decades, some management structures attempted to measure productivity or bloat by counting “lines of code.” This was always a fundamentally flawed guideline, but in the age of generative AI, it is actively destructive. AI models can generate thousands of lines of boilerplate code in seconds. Measuring lines of code today is like measuring the quality of a novel by weighing the physical book.
Duplication of Code Blocks
Instead, in an AI-driven environment, bloat must be measured by features duplicated or features generated but never used. AI tools are infamous for their verbosity; they will happily develop extensive, complex code blocks to solve a problem, only for that code to sit dormant and unused in the final application.
The core issue is a lack of global contextual memory. Human software developers, because traditional coding takes significant time and mental energy, are highly likely to remember writing a specific utility function three weeks ago. When a similar problem arises, the human developer will instinctively locate that original function and ensure it is reused and adapted appropriately. AI coding assistants, conversely, tend to optimize for the immediate prompt. If you ask an AI to solve a problem, it is much more likely to generate an entirely new, slightly different implementation of a solution rather than scanning the entire repository to reuse an existing one.
The data backing up this trend is alarming. According to the 2025 AI Code Quality Research published by GitClear, which analyzed over 211 million lines of code, the industry has reached a dangerous milestone. In recent years, the frequency of “copy/pasted” or cloned code has skyrocketed, exceeding the amount of “moved” or refactored code for the first time in recorded history. The report noted an astounding 8-fold increase in the frequency of duplicate code blocks within AI-assisted repositories. We are rapidly building systems composed of endlessly duplicated logic.
The Challenge of Unused Features
However, measuring bloat by looking for “unused” or “rarely used” features requires careful human nuance. You cannot simply automate the deletion of code that isn’t executed frequently. Consider an enterprise software application designed to manage a business’s finances and payroll. Within that massive application, there is a specific feature dedicated to generating and printing W2s and 1099 tax forms. If you look purely at telemetry data, that feature is essentially dead code for eleven months of the year. It is rarely used. Yet, it is an absolutely critical, non-negotiable component of that software. This is precisely why human gatekeepers must remain in the loop; automated systems might flag critical but low-frequency features as bloat, completely missing the business context.
We also must look at the redesign of Microsoft Office in 2007. Microsoft realized that their tools were becoming overwhelming and burdensome not only to manage, but to use as new features have been added for years. They decided to go to their customers and see how Office was being used. While several features we seemingly almost universally used, to their surprise most office users only used about 10% of the product. However, each customer used a different 10%. This meant that you couldn’t remove unused features, because all features were used, just not by the same people. By using a large enough dataset, they were able to save the product – but it took a near complete rewrite.
I was recently building an app using AI assisted coding. I had started with a clear plan, and a good design specification. However, as a few people started using it, I saw more and more feature request. It was simple to add, and because I had designed it well in the specification, there wasn’t many issues with the code itself… until I looked at the User Interface. What had been a clean and simple design, was now much more complicated. It took more time cleaning up the user interface, than it did adding those features.
An Ounce of Prevention
So, how do we prevent this AI-generated bloat from consuming our applications? Some might argue that the AI tools themselves should be programmed with stricter architectural rules, forcing users to justify a new feature before the AI agrees to generate the code. While skills-based systems are beginning to incorporate better guardrails, I do not believe AI tools should enforce artificial friction on the user. Throttling the tool defeats the purpose of rapid generation.
Instead, this necessary friction must exist firmly at the business and architectural level. A little intentional friction during the planning and design phases can smooth out the rough edges of a product. By forcing teams to justify a feature’s existence to a Product Manager before a technical developer ever opens an AI prompt, organizations can keep their designs consistent and ensure that the final application remains lean and maintainable.
The business and performance impacts of ignoring this new era of code bloat are severe and multifaceted. As applications and web pages grow artificially larger from unchecked AI generation, the end-user experience degrades. Larger payloads take longer to download, and applications run slower because the device processor is forced to parse through mountains of inefficient, duplicated code.
Perhaps most alarmingly, with each unnecessary new function generated by an AI, security has a fresh chance of failing. Consider a standard data validation function that is required in three different areas of an application. If a human engineer writes it once and reuses it three times, a discovered security vulnerability only needs to be patched in one single location. The fix is absolute. But, if an AI tool writes three slightly different, duplicated versions of that validation logic across the codebase, a terrifying scenario emerges. A security team might find the vulnerability in the first instance and patch it, completely unaware that the AI generated two other variations of that exact same flaw elsewhere in the system. By failing to reuse code, we are silently multiplying our security vulnerabilities, leaving hidden attack vectors scattered throughout our software for malicious actors to exploit.
The Auditing Challenge: Hunting for Invisible Flaws
The manual review of generative AI code simply does not scale. When a junior developer used to write buggy code, the mistakes were usually localized, structurally obvious, and relatively easy for a senior engineer to spot during a standard pull request. AI, however, generates code that is structurally plausible but contextually flawed. It writes validation logic that looks perfectly functional but fails to account for the broader business constraints of the application.
Where a junior developer might write a couple hundred lines of code, AI might write several thousand. Pouring over each line can be difficult with the scale of the changes. Yet, that is what some companies are having their senior developers do.
The scope of this problem is no longer theoretical; it is actively measurable. According to the 2025 GenAI Code Security Report published by Veracode, AI-generated code contains 2.74 times more vulnerabilities than human-written code. Furthermore, an astonishing 45% of AI-generated code fails basic secure coding benchmarks, frequently introducing critical flaws like Cross-Site Scripting (XSS) and SQL injections that traditional reviews miss.
From an auditing perspective, the industry must aggressively develop and adopt entirely new classes of tools to find these specific types of generative issues. Traditional Static Application Security Testing (SAST) often fails on AI-generated code because the generated boilerplate looks structurally valid – even when it includes insecure defaults or bypassed authentications.
We need specialized tools designed to audit and map near-identical code duplication across sprawling repositories. If an AI tool has generated the same flawed logic in twelve different places, human reviewers will almost certainly miss eleven of them. Improving our security audits requires “reachability analysis” – platforms like Endor Labs and next-generation Checkmarx suites that look beyond the lines of code to analyze how vulnerabilities and duplicate functions actually interact within the running application.
The Reality Check for Non-Technical Founders
This brings us to a critical crossroad for leadership, particularly for non-technical business founders who are currently leveraging AI to build their entire product right out of the gate. The advice here is blunt but entirely necessary: you must understand that you have built a prototype, not a product.
Prototypes are fantastic, and they have a vital place in the business lifecycle. They are unparalleled tools for securing initial funding, testing market fit, and quickly validating user interfaces with internal and external clients. The danger arises when founders conflate the speed of prototyping with the readiness of a final product.
If your goal is to launch a secure, scalable, and maintainable product – or to transition from that initial, AI-generated prototype into an enterprise-grade application – you cannot rely on generative tools alone. You will need a technical co-founder or a dedicated team of technical professionals. You need experienced developers to bridge the gap, rewrite the fragile components, enforce architectural guardrails, and refactor the prototype into a real product. Assuming the AI can take you all the way to the finish line without human technical intervention is a massive organizational risk that will inevitably result in crushing technical debt.
Conclusion – Refining the Process
Ultimately, the rise of generative coding tools does not signal the end of the software engineer; rather, it highlights the desperate need for more architectural oversight. AI is a powerful accelerator, but raw speed without a steering wheel inevitably leads to a crash.
As with all new technologies, we are in a transitional phase where we must relentlessly refine our processes and our tools. The “Jurassic Park” era of building rapid, bloated software simply because we have the power to do so must give way to a disciplined era of building because we should.
The companies that succeed over the next decade will not be the ones that generate the most code the fastest. The winners will be the organizations that implement the right technical gatekeepers, adapt their auditing tools to catch generative duplication, and successfully harness AI’s speed without ever sacrificing their software’s integrity.
The “Jurassic Park” Era of AI Coding: Why We Need Gatekeepers for the Code We Didn’t Write was originally found on Access 2 Learn
