AI Adoption Without Vast Tech Debt

How do you manage AI adoption? How do you avoid AI slop? How do you take advantage of increased output without becoming swamped by tech debt?

Lighting Talk: AI Adoption Without Vast Tech Debt #

The speaker, a community member who manages to max out three separate Cursor subscriptions monthly, opened with a thesis: we are entering an era where AI agents can handle nearly everything we need without cutting corners.

According to the speaker, the primary challenge of modern AI adoption isn’t the quality of the code, but the alignment of agents toward shared goals. Left to their own devices, agents lack the tribal knowledge of our specific businesses, our technologists’ preferences, and our long-term objectives.

Moving Debt from Code to Context #

The speaker suggested that the best way to manage a fleet of agents is to centralize “skills” and point every agent to a unified context. Rather than having fragmented prompts across different teams, organizations should maintain dedicated context hubs: one for security & compliance data, and another for market and competition data.

Then by sorting these skills according to organizational structure, we can keep technical debt outside of the source code itself. The goal is to integrate requirements directly into the workflow so that the code produced is born clean.

The 10x Throughput Imbalance #

One of the most striking points of the talk was the imbalance of acceleration. If AI allows one technical system to achieve 10x throughput, how do we accelerate the surrounding elements to match that pace? This could include other tools, development processes, code review, testing, cross-team approvals, user feedback and so forth.

The speaker noted that as context windows expand to the 200k-500k token range (they visualized this as 500 pages of text on your desk), the sheer volume of content a single person can produce is staggering. Their assertion is that to stay aligned, we must reduce team sizes. Smaller teams with clearer boundaries and a service-based architecture are better equipped to handle the high-velocity output of an AI-augmented workflow.

Offloading the Burden #

While we can minimize debt in our proprietary code, the speaker was realistic: “We can’t avoid technical debt in MCP and skills” that we bring in from outside the organization. The strategy, then, is a migration of effort. We should focus our energy on our unique business logic and offload the “commodity” debt to open-source projects and specialized vendors.

One point that I believe is missing — perhaps due to the time constraint of the lightning talk — is the user’s implicit responsibility to collaborate with the projects they consume. There are myriad ways to contribute to an open source project depending on its needs, such as financial donations, technical contributions, timely feedback, or community support. This is especially relevant for dependencies with a large user base and small contributor base, or early-stage vendors with tight operational constraints.

To help the group get started with this “context-first” approach, the speaker shared two primary resources:

• mcp-use: A GitHub repository for implementing Model Context Protocol
• Sunpeak.ai: Helps users address AI integration and workflow efficiency challenges

After the lightning talk, roundtable discussion began. I’ll sort the prompts into sections below to summarize and comment on each discussion topic that was selected.

AI Workflows: How did you execute it, and what worked best? #

The conversation quickly centered on one participant’s aggressive AI-first workflow, which sparked a fascinating debate about the limits of scale and the necessity of human oversight.

The case study shared was a workflow currently generating upwards of “70k useful lines of code per day.” The room had a silent divide at that point. Some waited for the speaker to elaborate, some nodded along, and others adopted visibly skeptical postures.

The first person to jump in with a response asked, “It takes me half a day to spec 1k lines of code,” likely implying, how could you possibly achieve 70k without vast technical debt?

The Architecture of High-Velocity Code #

To support this kind of throughput without drowning in technical debt, the member utilizes a monorepo containing everything from policy documents and internal wikis to the codebase itself. Key components include:

• The Repository Index: A single file that serves as a map for the AI, preventing it from having to “search” the entire codebase for every prompt.
• Encoded SDLC: The entire Software Development Life Cycle is coded directly into Cursor rules. This includes specific patterns, thinking processes, and—crucially—audit locks for SOC2 compliance.
• Agent Personas: By using tools like Linear’s agents, they assign specific roles (Product Owner, Security, Code Reviewer) that interact within Pull Requests. As the human lead, the member only steps in to “steer” when the agent’s thinking process (visible in the PR) begins to drift.

A concern that came to mind for me relates to data quality: security and compliance requirements are traditionally unstructured or inconsistently structured. This causes issues for LLMs. The ability to achieve security outcomes through AI is unacceptably inconsistent without system-wide integration of machine-readable artifacts (such as the approaches presented by OSCAL or Gemara).

The Scale Paradox: Quality vs. Quantity #

The discussion took a sharp turn when members began questioning the long-term sustainability of this approach. If an AI can generate hundreds of thousands of lines of code in a single sprint, at what point do we admit we didn’t actually need that much output?

Additionally, I couldn’t help but question whether we’re losing out on proven value from established traditional software development best practices — specifically the art of the code review. Many of our best designs come from reviewing each other’s contributions, refining our understanding of what is possible and what is good.

Another distinct conflict of opinion emerged regarding “Tribal Knowledge.” One member pointed out a significant risk: if the architect of such a massive, AI-driven system were to leave, would a new human hire even be able to comprehend the scope?

• The AI-First Argument: Documentation is no longer a chore because the AI generates it alongside the code. The system is “understood” because it is documented in real-time.
• The Human-First Skepticism: Massive codebases require more than documentation; they require intuition. There is a fear that we are building “black box” organizations where the speed of execution outpaces the human capacity for deep understanding.

In the end, it seems neither side shifted in their opinions. Those who referenced a background in massive organizational structures seem to believe that shifting cognitive load to machines will lead to unrecoverable technical debt, while others seem to believe that this is simply part of the process which AI can support.

Adversarial Agents and Legacy Refactoring #

The group also touched other use cases:

• Adversarial Networks: One member described building an “adversarial” system for a spiritual advisor app. They used agents to simulate difficult users and problematic interactions, then fed those conversations back into the training data to improve the model’s empathy and accuracy.
• Trimming the Fat: In a pivot back to legacy systems, we discussed a federal healthcare project that used AI to find redundancies in a five-year-old codebase. By running millions of test records to detect hallucinations and overlaps, they successfully trimmed 30% of the code, resulting in massive cost savings.

What does AI Governance look like? #

It was at this point in the discussion that I most wanted to interject. The group found itself in a common pitfall related to the use of language. Terms such as risk, policy, and governance lacked definition — causing minor deviations where each individual uses terms based on their own unique context and experience.

Nonetheless, the ensuing conversation revealed several interesting perspectives.

One of the first points of consensus was that governance must happen at two levels: the Data Level and the Agent Level. On the data side, we are still relying on traditional (though evolving) tools like OIDC, MCP, and token-based access. This ensures that proprietary data does not need to be baked into the model itself. However, agent governance is a newer, messier frontier.

The Internal vs. External Divide #

The group discussed a tiered approach to managing what one member called the “blast radius” of an agent, going on to say:

• Internal Productivity Agents: If an employee uses an agent on data they already have permission to access, the risk is low.
• Published Internal Agents: These undergo standard review and are integrated into the release pipeline with automated tests.
• Customer-Facing Agents: These require the highest level of scrutiny, including a built-in killswitch to immediately neutralize the agent if it begins to drift or cause harm.

Where Does Policy Live? #

A significant technical debate emerged regarding where “policy” should reside. If you encode your business logic into the agent, where do you put the safety rails?

One member argued that business logic and policy must be decoupled. The agent should handle the “how” (the logic), while the policy (the “what is allowed”) should exist in a separate “sidecar” or external enforcement layer. This prevents an agent from “hallucinating” its way around its own internal rules.

This fits with enterprise compliance approaches that I’ve seen, where policy is not simply a configuration, but an organizational law that is evaluated and enforced by specialists outside of the development team.

The Problem of “Non-Obvious” Failure Modes #

The most sobering part of the discussion touched back on the 70k lines of code per day. Human teams, even large ones, have predictable speeds and known failure modes. But when you move at AI scale—theoretically thousands of releases a day—we encounter a transparency problem.

As one member asked: “We talk about policy as if we know what to look for… but do we?”

If a system is evolving that rapidly, a human might not see a vulnerability or a logic flaw until it has already scaled across the entire enterprise. A proposed solution was to use “Observer Agents”—separate AI entities whose only job is to perform QA and watch the primary agents for deviations.

The Accountability Loop #

Ultimately, the room landed on a fundamental truth: The user is responsible for the agent. AI is a “product multiplier” for a person, not a replacement for their judgment. Whether you are a vibe coder or a leader in a complex organization, the consensus was that if you take humans out of the accountability loop, the system will eventually run away from you.

As the first commenter on this topic noted, app stores are already full of vulnerabilities created by humans; AI just gives us the ability to create them faster if we aren’t careful. The goal is to keep the scope of any given AI implementation comprehensible. If a human can’t understand the system’s boundaries, the governance has already failed.

Here are some resources I can personally recommend to help improve your security posture while adopting AI solutions:

• OWASP GenAI Security Project — Maintains the AI Top Ten, LLM Top Ten, and others
• FINOS AI Governance Framework — a catalog of AI failure modes and mitigations
• Sonatype Guide — a freemium tool with MCP server to ensure agents use secure dependencies

How can we use AI to clean up AI slop? #

To close out the evening, the conversation turned to a meta-problem: if AI generates “slop,” can we simply use more AI to clean it up? Though the group again avoided strict definitions of terms, I interpreted slop to mean low-quality, redundant, or insecure code.

This sparked a philosophical debate on whether the very nature of “technical debt” has changed in 2026.

The consensus among the more optimistic members was that an “AI immune system” is now a requirement. Tools like SonarQube, CodeRabbit, and BugBot are being used to provide a second layer of mechanical oversight on agent-generated output.

One particularly effective stack mentioned was combining OWASP Dependency Check with SonarQube to act as a “known-bad” filter, catching deprecated, vulnerable, or malicious libraries when they are recommended by an agent—a common pitfall for even the latest LLMs.

If you’d like to explore more on the topic of bad dependencies in the age of AI, you might check out a publication I recently contributed to: the 2026 State of the Software Supply Chain Report.

The Rise of Ephemeral Code #

The most controversial take of the night was the suggestion that we are redefining technical debt into extinction. The logic follows a few key points:

• Code as a Disposable Asset: If a block of functionality can be generated, tested, and deployed in minutes, it becomes ephemeral. We no longer need to “improve” bad code; we simply throw it away and generate a new version when requirements change.
• The Black Box & The Contract: If the API contracts are strictly adhered to and the tests pass, does it matter if the logic inside the “black box” is messy? Some argued that for short-lived services or prototypes, the “slop” is irrelevant if the service performs its function.
• The Speed-to-Cost Tradeoff: In the past, debt was expensive because it was slow to fix. If AI allows us to refactor an entire service in an afternoon, the “cost” of that debt drops significantly.

The Macro-Service Warning #

Not everyone was sold on the “disposable code” future. A few veterans in the room offered a reality check: Micro-services have a habit of gaining a “macro-service” life of their own. Even if you intend for code to be ephemeral, once it has a thousand downstream dependencies, you can’t just “throw it away.” The “slop” might be easy to generate, but the architectural debt of a sprawling, AI-managed system could eventually become a “macro” problem that no single agent can resolve. As one member put it: “AI doesn’t stop your microservice from growing into a legacy monster.”

Conclusion #

I found it quite compelling to say that we are redefining technical debt into extinction… perhaps from an antithetical perspective. It’s not that the debt is gone, it’s that we’ve relabelled it as an investment.

We have begun tolerating far more than we did in the past. Software engineers of the past (and maybe even future engineers) would balk at the number of best practices we have disregarded and the amount that we have allowed our technical skills to atrophy in the name of temporary acceleration. The greatest technical debt we are assuming in this decade is a loss of future engineers.

Still, I came away from this conversation inspired to try new things with my own AI tools. As my team is building out tools to optimize security and compliance data for the world’s largest highly regulated organizations, there is immense value in rapid prototyping cycles. I’ll definitely benefit from learning the different approaches folks are taking to optimize their use of AI.

Eddie Knight is the founder and CEO at Revanite.