How do we fix this? We reduce our usage on general purpose frameworks and lessen our dependency on complexity of infrastructure. We use less opensource software, treat all third party code as potentially vulnerable and move closer to component vanilla code (Audited piece by piece for integrity), which AI can generate.
The rise of so-called “AI slop” in open-source software has become a growing concern within the developer community. Increasingly, AI-generated code is finding its way into major repositories, including widely used projects such as cURL and the Linux kernel. While artificial intelligence can be a powerful productivity tool, its careless or unreviewed use is creating serious risks for the integrity, security, and long-term sustainability of open-source ecosystems.
Open-source software has always depended on trust, transparency, and human expertise. Contributors submit code that is reviewed, tested, and refined by maintainers and peers. This collaborative scrutiny is what makes open-source software reliable despite its decentralized nature. However, the introduction of large volumes of AI-generated contributions threatens to overwhelm this model. When developers use AI systems to rapidly generate code without fully understanding or validating it, the quality of commits can degrade significantly. This phenomenon—sometimes referred to as “AI slop”—describes low-quality, poorly reasoned, or unnecessary code that adds noise rather than value.
One of the most pressing issues is volume. Thousands of open-source projects are now receiving AI-assisted or fully AI-generated commits. While some of these contributions are helpful, many are superficial changes, redundant refactors, or poorly optimized implementations that add bloat without improving functionality. Maintainers, who often volunteer their time, must sift through increasing numbers of pull requests. This slows development and increases the likelihood that subtle bugs slip through review.
Security is another major concern. AI models generate code by predicting patterns based on their training data. They do not truly understand system architecture, threat models, or the broader security implications of a change. As a result, AI-generated code may introduce vulnerabilities, insecure dependencies, or unsafe logic. In package ecosystems, this can contribute to “package poisoning,” where malicious or compromised dependencies infiltrate projects. Even without malicious intent, AI-generated code can unknowingly replicate outdated or insecure practices. Once merged into widely used libraries, such flaws can cascade across thousands of downstream systems.
Data integrity is also at risk. Subtle logical errors, incorrect assumptions about edge cases, or mishandled concurrency can compromise the reliability of critical systems. In low-level projects such as operating system components or networking libraries, even a minor flaw can have severe consequences. Unlike application-level bugs, which may only affect a specific feature, foundational software errors can destabilize entire environments. When AI-generated code is accepted without rigorous component-level validation, the potential for systemic issues grows.
Performance degradation and code bloat further compound the problem. AI tools tend to generate verbose implementations, duplicate logic that already exists elsewhere in the codebase, or fail to follow established architectural patterns. Over time, this increases technical debt. Clean, minimal, and elegant code—long hallmarks of well-maintained open-source projects—can be replaced by sprawling, harder-to-maintain structures. This not only affects current maintainability but also makes future refactoring and debugging more difficult.
The cultural implications are equally significant. Open-source communities have traditionally valued craftsmanship, mentorship, and deep technical understanding. If contributors increasingly rely on AI to generate code they do not fully comprehend, the collective knowledge base of the community may erode. Developers who submit AI-generated patches without thoroughly reviewing or testing them risk weakening the culture of accountability that open source depends on.
Some engineers have responded by rejecting AI tools altogether. A growing number have stopped using AI assistance and returned to writing traditional, high-quality code without automated generation. They argue that deep thinking, careful design, and manual craftsmanship are essential to building reliable systems. While this reaction is understandable, completely abandoning AI may be an overcorrection. AI, when used responsibly, can still serve as a valuable assistant—helping with boilerplate, suggesting test cases, or exploring alternative approaches.
The real issue is not the existence of AI tools but the lack of disciplined oversight. An engineer must design, test, and implement every AI-assisted system at a component level. AI should be treated as a junior collaborator whose output requires rigorous review. Every function, algorithm, and structural decision must be evaluated for correctness, efficiency, and security. Engineers remain responsible for understanding the code they merge, regardless of its origin.
This means establishing stronger review processes, automated testing pipelines, and security auditing practices. It also requires cultural reinforcement: contributors should be transparent about AI usage and maintainers should hold AI-generated contributions to the same or higher standards as manually written code. Tooling can help detect common AI patterns, duplicated logic, or suspicious dependencies, but ultimately, human expertise must remain the final gatekeeper.
Ironically, the proliferation of AI-generated code may make skilled classical engineers more valuable than ever. As systems grow more complex and as low-quality contributions increase, organizations and communities will depend even more on individuals who can reason deeply about architecture, performance, and security. The ability to critically analyze algorithms, validate assumptions, and anticipate edge cases cannot be fully automated. In this sense, AI does not replace engineering skill; it amplifies the need for it.
Looking ahead, it is likely that AI-generated code will become increasingly woven into our digital infrastructure. The key question is whether it will be integrated responsibly or recklessly. If developers use AI as a productivity multiplier while maintaining rigorous standards, open-source software can remain robust and innovative. If, however, AI output is accepted uncritically and en mass, we risk undermining the reliability of the very systems that power modern computing. This is particularly concerning when it comes to automation of our systems through agents… We may reach the point where all code may have levels of corruption as a systemic industry problem at the core of frameworks, engines and kernels
The solution lies in balance. AI is a tool—powerful, imperfect, and dependent on human judgment. Engineers must remain architects, reviewers, and guardians of quality. By designing carefully, testing thoroughly, and validating every component for structural and algorithmic integrity, we can harness AI’s strengths without sacrificing the foundational principles that make open-source software trustworthy.
The problem is that if developers do not start actively seeking to safeguard against these types of pitfalls, we may reach a point where all of our code is contaminated. This will mean that when we do a git pull for react as an example or update our ubuntu system, that the package poisoning and other vulnerabilities will be almost impossible to avoid, reducing productivity and increasing costs substantially… In some cases, it may even be to late.
