That’s the warning from Info-Tech Research Group, which has published new research urging organizations to put stronger governance around AI-assisted software development as adoption accelerates.
AI-generated code can make developers faster. It can also make software teams very efficient at creating problems they won’t discover until much later.
The firm’s blueprint, Defend Against Defects and Technical Debt in Your AI-Generated Code, argues that organizations are increasingly introducing AI-generated code into development workflows without establishing consistent review standards, quality controls or accountability.
The concern isn’t that AI coding tools are inherently unreliable. It’s that their output can look remarkably polished even when it contains architectural, security or operational problems that are difficult to spot during a conventional code review.
That’s a dangerous combination for software teams under pressure to ship faster.
AI can reduce the time required to write code. It can also reduce the time available to ask whether that code should have been written in the first place.
The productivity paradox of AI coding
The business case for AI-assisted development is straightforward.
Developers can use AI to generate boilerplate, explain unfamiliar code, write tests, refactor functions, create documentation and produce entire application components from natural-language instructions.
For organizations facing hiring constraints and pressure to deliver software faster, the appeal is obvious.
The problem starts when productivity becomes the primary metric.
If an AI assistant helps a developer complete a task 30% faster, that sounds like a win. But if the resulting code introduces a subtle dependency, duplicates an existing pattern or creates future maintenance work, some of those productivity gains are effectively borrowed from the future.
That’s technical debt.
And AI-generated code can potentially accumulate it at a much higher rate because the technology makes producing code cheap.
Info-Tech’s research focuses on that imbalance: the cost of generating code is falling faster than the cost of validating its quality.
“AI-generated code introduces different kinds of mistakes than humans do because the technology lacks full comprehension of business context and long-term operational impact,” said Ari Glaizel, associate vice president of research development at Info-Tech Research Group.
His point gets to the heart of the issue.
An AI model can generate syntactically valid, technically plausible code without understanding why a particular architectural decision matters to the business.
That’s not necessarily a bug in the model.
It’s a limitation of the assignment.
AI doesn’t understand the business the way developers do
A developer working on an established application typically carries context that isn’t fully captured in a prompt.
They may know why a particular database cannot be queried directly, why an apparently redundant validation step exists, why a legacy service cannot tolerate certain traffic patterns or why a seemingly simple change could affect a downstream system.
An AI coding assistant may not know any of that.
Give it a narrow task and it can produce an impressively competent answer.
The trouble is that software engineering is rarely a collection of narrow tasks.
Architecture, security, performance, reliability and business requirements intersect.
AI-generated code can therefore be technically correct while being operationally wrong.
That’s one of the central risks Info-Tech identifies.
Weak prompting and insufficient business context can cause models to produce code that satisfies the literal request while missing the underlying requirement.
The result may pass a unit test and still be a bad production decision.
The polished-code problem
One reason AI-generated defects may be particularly difficult to manage is presentation.
Modern AI coding tools are good at producing code that looks finished.
Variables are named sensibly. Functions are formatted correctly. Comments may be included. Tests may appear alongside the implementation.
To a reviewer scanning a pull request, the output can look reassuringly professional.
That creates what could be called the polished-code problem.
Human developers are accustomed to reviewing code written by other humans, where mistakes often leave recognizable clues: inconsistent naming, incomplete logic, obvious duplication or awkward structure.
AI can produce something much more uniform.
That does not make it correct.
It can simply make incorrect code harder to distrust.
Info-Tech warns that organizations may inadvertently weaken verification processes when teams begin treating AI-generated output as inherently reliable.
If developers assume the machine has already done the difficult thinking, code review can gradually become a rubber stamp.
That’s where the productivity story starts to unravel.
Technical debt can scale faster than the codebase
Technical debt isn’t necessarily bad.
Sometimes teams deliberately accept a temporary shortcut to meet a deadline, with the expectation that they will clean it up later.
The problem is unmanaged debt.
AI-assisted development could make that problem more difficult because it dramatically lowers the barrier to producing additional code.
A developer can ask an AI tool to generate another integration, another abstraction layer or another workaround in seconds.
If the underlying architecture is already complicated, those additions can compound the problem.
Multiply that across hundreds of developers and repositories, and small inconsistencies can become systemic.
Different teams may prompt AI differently. Different models may produce different coding patterns. Developers may use different tools with different assumptions about testing, dependencies and security.
The organization ends up with code that works—but doesn’t necessarily look or behave like it came from the same engineering organization.
That creates a long-term maintainability problem.
Consistency becomes harder when everyone has an AI pair programmer
One of the less obvious effects of AI coding assistants is that they can increase individual developer autonomy.
That’s usually a good thing.
But at organizational scale, it can create a standards problem.
Without clear rules, one developer’s AI assistant may generate one approach to error handling while another produces something completely different.
One team might require comprehensive tests. Another might accept minimal coverage.
One repository might have strict security controls. Another might contain generated dependencies that nobody has fully reviewed.
Humans already introduce inconsistency into large engineering organizations.
AI can amplify it.
That’s why Info-Tech recommends establishing guardrails rather than relying on developers to figure out appropriate AI usage independently.
The goal isn’t to stop developers from using AI.
It’s to make sure the organization knows where AI is being used, what it is allowed to do and what humans are expected to verify.
Info-Tech’s three-step framework
Info-Tech’s blueprint proposes a phased approach for organizations that want to scale AI-assisted development without sacrificing software quality.
The first step is establishing tool usage.
Development leaders should document where AI-generated code is being used across the SDLC, clarify why teams are adopting it and identify stages where stronger human oversight is necessary.
That sounds basic, but visibility matters.
An organization can’t govern AI-assisted development if it doesn’t know which teams are using which tools or what types of code those tools are generating.
The second step is defining guardrails.
This involves auditing existing delivery pipelines, incorporating non-functional requirements into workflows, establishing prompting standards and creating AI-specific pull-request verification checklists.
The third step is roadmapping development milestones.
Organizations should define measurable objectives, establish success metrics and build phased implementation plans for rolling out governance practices across teams and repositories.
The framework is deliberately practical.
Rather than declaring that developers should “use AI responsibly,” it asks organizations to turn responsibility into processes that can actually be followed and measured.
That’s an important distinction.
A policy nobody can operationalize is basically a PDF with good intentions.
Pull requests need a new layer of scrutiny
One of Info-Tech’s recommendations is particularly relevant to day-to-day engineering: AI-specific pull-request verification.
Traditional code review already asks whether a change works, follows coding standards and introduces unnecessary complexity.
AI-assisted development adds additional questions.
Was the code generated by AI?
If so, was the developer able to explain its logic?
Did the model introduce dependencies?
Were security requirements explicitly considered?
Does the code align with the existing architecture?
Are tests sufficient for the risk involved?
Did the AI make assumptions about the business process that need human verification?
These questions don’t necessarily need to become burdensome checklists for every line of code.
The level of scrutiny should depend on risk.
A generated unit test is not the same thing as AI-generated code controlling a financial transaction.
A useful governance program should distinguish between those scenarios.
Human accountability remains the safety net
Info-Tech’s position is not that humans should stop using AI-generated code.
Quite the opposite.
The company argues that AI-assisted development needs a human accountability layer.
“Even with strong prompting and the right tools, organizations still need a human accountability layer to validate, review, and govern AI-assisted development responsibly,” Glaizel said.
That principle is becoming increasingly important as AI moves from code completion into more autonomous software development.
There is a major difference between asking an AI to suggest a function and asking an AI agent to modify multiple components, run tests and prepare a production-ready change.
As autonomy increases, governance needs to increase with it.
The question isn’t whether humans remain in the loop.
It’s where humans remain in the loop.
Testing alone won’t solve the problem
It’s tempting to assume that automated testing can catch whatever AI gets wrong.
Testing is essential, but it has limits.
A test can tell you whether software behaves as expected under defined conditions.
It cannot always tell you whether the expected behavior is the right behavior.
Suppose an AI-generated service correctly processes a transaction but does so through an architecture that creates unacceptable latency at scale.
The unit tests may pass.
Suppose AI-generated code exposes information that the application is technically authorized to retrieve but should never display to a particular user.
The code may work exactly as programmed.
Or suppose the AI creates a dependency that is secure today but difficult to maintain as the application evolves.
Again, the tests may pass.
That’s why Info-Tech emphasizes non-functional requirements and human review.
Performance, security, maintainability and architecture have to be considered alongside functional correctness.
Prompting becomes an engineering discipline
Another implication of AI-assisted development is that prompting can no longer be treated as a purely individual skill.
A developer might ask an AI tool:
“Create an API endpoint for customer records.”
That’s enough to generate code.
It isn’t enough to guarantee that the code fits the organization’s requirements.
A stronger prompt could specify authentication requirements, data access controls, expected traffic, error-handling standards, architectural constraints, testing expectations and relevant business rules.
The more context the AI receives, the more likely it is to produce useful output.
But organizations shouldn’t rely exclusively on developers becoming expert prompt engineers.
Info-Tech recommends establishing prompting standards as part of its guardrail framework.
That shifts prompting from personal experimentation toward an engineering practice.
The organization can define what information should be included, what constraints matter and which requirements should never be omitted.
In effect, the prompt becomes another artifact of software engineering.
AI coding changes the economics of software
There is a bigger industry implication here.
Generative AI is reducing the marginal cost of producing software.
That is potentially transformative.
But when something becomes cheaper to produce, organizations tend to produce more of it.
History offers plenty of examples.
Cheap storage encouraged organizations to retain enormous quantities of data. Cloud infrastructure made it easier to spin up services. Open-source software made it easier to assemble applications from existing components.
AI-generated code could do something similar for software itself.
The result may be a world with more software—and more software that nobody fully understands.
That creates an uncomfortable trade-off.
Organizations could ship faster while simultaneously increasing the amount of code they have to maintain.
The productivity metric therefore needs to evolve.
Lines of code generated per developer is almost meaningless if those lines create future maintenance costs.
The more useful measures may involve deployment frequency, escaped defects, change failure rate, security findings, technical-debt growth and developer time spent maintaining AI-generated components.
In other words, organizations need to measure the outcome of AI-assisted development rather than the volume of AI-assisted development.
Security deserves special attention
Security is perhaps the area where AI-generated code deserves the most skepticism.
AI models have been trained on vast quantities of publicly available code, but they do not automatically understand an organization’s threat model.
A generated authentication flow may appear reasonable while missing a subtle edge case.
A database query may work correctly while creating an injection risk under unusual inputs.
A dependency may solve a problem quickly while introducing a vulnerability or licensing concern.
Security review therefore cannot be replaced by code generation.
In fact, the speed of AI development may make security review more important.
If developers can generate and merge changes much faster, security teams could find themselves reviewing a larger volume of changes without additional resources.
That creates a potential bottleneck.
Organizations may need automated security checks, stronger CI/CD controls and risk-based review policies to keep up.
The objective isn’t to inspect every line manually.
It’s to make sure high-risk changes receive appropriate scrutiny.
The AI Code Quality Starter Kit puts the framework into practice
Info-Tech’s blueprint includes an AI Code Quality Starter Kit, a workbook designed to capture the outputs of the research methodology.
It includes areas for documenting delivery goals, AI guardrails, success metrics and roadmap milestones.
That may sound less exciting than the latest AI coding assistant, but implementation tools are where governance programs often succeed or fail.
Engineering organizations don’t need another abstract principle.
They need a repeatable way to decide what is acceptable, how it should be reviewed and how success will be measured.
The starter kit is intended to provide that structure.
For organizations already using AI coding tools, that could be more useful than another top-down policy memo.
Don’t ban AI. Control it.
The easiest response to the risks of AI-generated code would be to restrict it.
That is unlikely to work.
Developers are already using AI coding tools because the productivity benefits are real. Banning them could simply push usage into unofficial channels, where organizations have even less visibility into what is happening.
The better approach is controlled adoption.
Allow developers to use AI where it provides value.
Establish clear standards.
Automate quality and security checks.
Require human review where the risk warrants it.
Track outcomes.
And adjust the rules as the technology changes.
That’s essentially the model Info-Tech is proposing.
It recognizes that AI-assisted development is not going away—and that the answer to its risks isn’t pretending it isn’t happening.
The next challenge is AI-generated technical debt
The software industry has spent decades learning how to manage technical debt created by human developers.
AI introduces a new version of the problem.
Instead of asking whether a developer took a shortcut, organizations increasingly need to ask whether an AI system generated complexity that nobody fully understands.
That doesn’t mean AI-generated code is inherently worse than human-written code.
In some cases, it may be cleaner, better tested and more consistent than code a developer would have written manually.
The issue is accountability.
Who owns the architectural decision?
Who validates the assumptions?
Who is responsible when the generated code fails?
And who cleans it up six months later?
If those questions don’t have clear answers, AI can turn technical debt into an organizational problem rather than simply an engineering one.
AI coding’s real productivity test is still ahead
The promise of AI-assisted development is compelling: faster delivery, less repetitive work and developers who can spend more time on higher-value problems.
But speed without quality is not productivity.
It is deferred cost.
Info-Tech’s research is a useful reminder that AI-generated code needs to be treated as software, not magic.
It should be reviewed. It should be tested. It should meet architectural and security requirements. And it should have a human owner who understands what it is supposed to do and why.
The organizations that get the most from AI coding tools will probably not be those that generate the most code.
They’ll be the ones that build the strongest system around the code-generation process.
That means governance, guardrails, automated checks, risk-based review and clear accountability.
AI can write the code.
For now, humans still have to own the consequences.
