In a monoculture, a single species or type dominates a system, to the exclusion of all others.
The term comes from agriculture, when a field is planted entirely with one crop. It may be efficient and easy to manage, but a single disease, pest, or environmental change can wipe out the entire yield.
Different varieties have different vulnerabilities, so a field of diverse crops can contain the damage naturally. A monoculture has no such defense.
Latest Videos FromTechRadar
That same monoculture condition is now occurring in software development.
CEO and co-founder of Qodo.
Many organizations using AI tools for coding rely on a single AI model to both generate code and review it. On paper, this is efficient. But in reality, it creates a closed loop where the reviewer can’t catch things that the generator is blind to.
Security flaws go undetected in reviews and suboptimal architectural decisions go unchallenged because the reviewing system shares the same assumptions as the system that produced the code.
When issues arise, engineers look at recent commits, failed deployments, and configuration changes. The assumption that a single AI platform can objectively review its own output is rarely questioned.
The solution to an agricultural monoculture is to introduce different crop varieties with different vulnerabilities, so that no single threat can devastate the entire field. The same is true in AI coding monocultures. Organizations need to introduce AI tools that are genuinely independent of the systems they’re reviewing.
Separation of duties
So, why can’t the same AI just review its own work?
Asking a coding assistant to review itself is like asking a human to proofread their own writing. The human may catch typos and grammatical errors, but they often won’t catch logical inconsistencies or arguments that don’t hold up.
This is because the human writer often subconsciously reads what they meant to write rather than what is actually on the page. A model reviewing its own output does the same thing; it evaluates the output against the same patterns and objectives that produced it in the first place.
Similarly, an AI model trained on the same data and optimized for the same signals as the model that wrote the code will carry the same blind spots. It will catch what it’s capable of catching, and miss the things that the generating model missed.
Finance figured out this separation-of-duties principle long ago. If the same person who initiates a transaction can also approve it, that opens the door to fraudulent or erroneous transactions. The approval step only works if the approver is independent of the person who initiated the transaction.
Likewise, organizations must introduce a dedicated review tool that operates independently of the system that generated the code. Choosing a different vendor won’t automatically solve the problem if the underlying models share the same training data or architectural assumptions.
Genuine independence requires different training data and different signals, and the tool must specifically be built for scrutiny, not completion.
Defense-in-depth
A dedicated review tool is a strong starting point, but separation of duties alone isn’t enough. The same principle that argues against a single AI doing everything also applies within the review function itself.
Code review is not a single task. Finding bugs, enforcing standards, assessing risk, and understanding how a change fits into the broader system are separate forms of reasoning, even when they appear in the same pull request.
Asking one agent to handle all of them at once forces tradeoffs between depth, speed, and coverage. In other words, some things will get less attention than they require.
Just as a mature security architecture layers independent controls so that what one misses another catches, a mature review architecture assigns distinct responsibilities to systems optimized for each one.
In practice that might mean one agent focused specifically on security vulnerabilities, another enforcing architectural standards and coding conventions, a third assessing the blast radius of a change, and a human reviewer making the final judgment call on anything flagged as high risk.
Each layer asks different questions and operates on different signals. The goal is ensuring that no single blind spot, including those shared across an AI monoculture, can let a problem through unchallenged.
The shifting role of platform engineering
As AI generates a larger share of production code, organizations will need to designate clear ownership over which AI does what, and ensure the review function doesn’t get quietly collapsed into the generation function in the name of efficiency. That responsibility will increasingly fall on platform engineering teams.
The role has traditionally been about making developers more productive by simplifying tooling, maintaining infrastructure, and reducing friction. That work hasn’t disappeared, but as developers move from writing code themselves to directing agents that write it for them, platform engineers will need to govern the systems that generate code, not just maintain them.
That means owning the standards those agents follow and ensuring visibility into what’s actually happening across the codebase. Most importantly, it means treating code generation and code review as distinct functions that require distinct capabilities, and resisting the organizational pressure to consolidate them into a single platform because it’s simpler to manage.
Organizational memory
As AI handles more of the writing and reviewing, accumulated institutional knowledge gets lost. Why was that architectural decision made two years ago? Which parts of the codebase affect each other in ways that aren’t obvious? What broke before and why? AI coding tools don’t carry any of that context. They look at the task in front of them, complete it, and move on.
This kind of institutional knowledge used to live in the heads of the engineers who wrote and reviewed the code. As AI takes over more of that work, it needs to be captured in places such as documented standards and recorded review decisions or it simply vanishes. When organizations build that kind of memory into their development process, their systems get smarter about their codebase over time.
That means a review function that doesn’t just flag problems in isolation, but learns the organization’s standards, remembers past decisions, and understands how different parts of the codebase connect and depend on each other.
Getting ahead of monoculture risk
The AI monoculture risk is what happens when no one asks whether the system reviewing the code is genuinely independent of the system that wrote it.
Microsoft CEO Satya Nadella recently argued that the real opportunity in AI is not in picking the best model, but in building a learning loop where human knowledge and AI capability compound together, and that a company should be able to swap out a generalist model without losing the expertise built into its own systems.
That’s only possible if the governance infrastructure is built at the same pace as the generation capability.
The organizations that do that early will be in a much better position than those that wait until something breaks.
We’ve reviewed, rated, and ranked the best vibe coding tools.
This article was produced as part of TechRadar Pro Perspectives, our channel to feature the best and brightest minds in the technology industry today.
The views expressed here are those of the author and are not necessarily those of TechRadarPro or Future plc. If you are interested in contributing find out more here: https://www.techradar.com/pro/perspectives-how-to-submit
https://cdn.mos.cms.futurecdn.net/wZAaq2s2qH4tHBJTEBNZXM-2560-80.jpg
Source link
