Managing Developers Using AI as a Proxy
When a developer uses AI as a proxy for their own understanding and skill, it creates significant friction in code reviews and hinders long-term team growth. This article explores strategies to address this growing challenge.

A concerning trend has emerged in software development: programmers leveraging artificial intelligence tools not as assistants, but as direct replacements for their own thought processes and coding efforts. This phenomenon, often termed 'vibe coding' when AI-generated code is accepted without full comprehension, introduces substantial challenges, particularly during the code review process. Instead of fostering collaboration and quality, it creates a bottleneck where reviewers spend excessive time deciphering AI-generated code that the supposed author has not deeply understood. This not only degrades code quality but also negates the intended benefits of code reviews for skill development and knowledge sharing within a team.
The core issue lies in the misapplication of AI. When a developer submits AI-generated code without genuine understanding, they bypass the learning and problem-solving stages crucial for personal and team growth. Questions posed during code reviews are met with evasive code modifications rather than genuine engagement, leading to a repetitive cycle of superficial fixes and continued low-quality output. This creates a negative productivity loop, where the reviewer expends more effort than the original 'developer,' all while the team misses out on the essential collaborative and educational aspects of the development lifecycle.
The Impact on Code Reviews
Code reviews are intended to be a collaborative quality assurance step, ensuring code is robust, maintainable, and adheres to team standards. However, when AI acts as a proxy, this process becomes arduous. Reviewers face the task of understanding code generated by a tool, often without the author’s deep insight. This can add anywhere from five to twenty minutes per pull request, a significant overhead when multiplied across a team and numerous contributions.
The cycle of AI-assisted "fixes" is particularly frustrating. A reviewer might ask a specific question about a piece of logic, only for the developer to feed the question into an AI. The AI then generates a response, which is then pasted back into the code, often in a way that makes the original question irrelevant but doesn't necessarily improve the code's underlying correctness or understandability. This superficial resolution pattern forces reviewers into an endless loop of addressing generated issues rather than fostering genuine understanding or improvement.
Eroding Teamwork and Knowledge Sharing
This reliance on AI as a proxy fundamentally undermines teamwork. Instead of developers collaborating to solve problems and share knowledge, one member is effectively offloading their responsibilities. This creates an imbalance where other team members must compensate for the lack of engagement, leading to resentment and burnout. The collaborative spirit that strengthens a team and drives innovation is replaced by a passive consumption of AI-generated output.
Furthermore, the essential practice of knowledge transfer is severely hampered. When a developer doesn’t grapple with a problem themselves, they don’t develop the deeper understanding that allows them to articulate solutions, share best practices, or mentor junior colleagues. The AI might produce syntactically correct code, but it doesn't instill the problem-solving acumen or contextual knowledge that seasoned developers possess and pass on.
The Illusion of Productivity
Management may perceive rapid code generation via AI as increased productivity. However, this is often a mirage. The real cost is borne by the individuals conducting code reviews and the overall project quality. The time spent by experienced engineers deciphering and correcting AI-generated 'slop' represents a significant drag on actual project velocity and can lead to increased technical debt.
This perceived productivity boost can be misleading. Tools are presented as far more capable than they are, and management without deep technical expertise may be convinced by superficial metrics. An experienced programmer, for example, will recognize an LLM's limitations in specific coding tasks. However, if management accepts marketing claims about AI's 'genius-level' capabilities, they may not see the underlying productivity loss, especially if the AI-proxied developer appears to be producing code quickly.
Strategies for Addressing the Problem
Dealing with a developer who acts as an AI proxy requires a multi-faceted approach. Firstly, it's crucial to shift the focus back to individual accountability and understanding. Instead of simply explaining a code issue, prompt the developer to investigate and propose solutions themselves. For instance, rather than stating, 'This string comparison should use IsNullOrWhiteSpace,' ask, 'What are the potential edge cases for string emptiness this code handles?'
Encourage developers to articulate their thought process and the reasoning behind their code, even when AI tools are involved. Require them to explain how the AI's suggestion addresses the problem and why it’s the chosen solution. This forces a level of engagement that 'vibe coding' circumvents, ensuring the developer is at least minimally aware of the code they are submitting.
Leveraging AI for Reviewers
While using AI for code generation by developers is problematic, exploring its use for assisting reviewers might offer a counter-balance. Tools like Claude Sonnet 4.5, Gemini 2.5 Pro, and GPT-5.2 can be experimented with to see if they can help identify potential issues in AI-generated code more efficiently than manual review alone. However, as noted in Source 1, current AI review tools often miss project-specific nuances and focus on trivial details, making them an unreliable substitute for human expertise.
The goal here is not to delegate the entire review to AI but to augment the reviewer's capabilities. An AI assistant could potentially flag suspicious patterns, deviations from common practices, or areas that require deeper human scrutiny. This could help reduce the time spent on rote checking, allowing the human reviewer to focus on the more complex logical and architectural aspects of the code.
Setting Clear Expectations and Standards
Establishing clear guidelines for AI tool usage within the development team is paramount. These guidelines should define AI as an assistant for boilerplate code, suggestions, or research, not as a substitute for problem-solving or code comprehension. Explicitly state that developers are responsible for understanding, verifying, and being able to explain any code they commit, regardless of its origin.
Implement stricter code review processes that require developers to demonstrate a clear understanding of the changes. This might involve asking probing questions about the logic, performance implications, or security considerations of the submitted code. If the developer cannot provide satisfactory answers, the pull request should not be merged until genuine understanding is demonstrated.
Formalizing AI Usage Policies
A formal policy on AI usage can provide a framework for how these tools are integrated into the development workflow. This policy should address intellectual property concerns, licensing of AI-generated code, and ethical considerations. It should also clearly delineate the acceptable and unacceptable uses of AI, emphasizing that AI-generated code must undergo rigorous review and validation by the developer.
Such a policy can serve as a reference point for discussions with management and developers alike. It provides objective criteria for evaluating AI's role and helps to manage expectations about its capabilities and limitations. Without clear guidelines, the ambiguity surrounding AI use will likely continue to fuel the problem of proxy programming.
Alternative Role Placement
For employees who consistently demonstrate an inability or unwillingness to engage with code beyond acting as an AI proxy, their current role may be a poor fit. If the organization is unable to dismiss such employees due to tenure or other factors, exploring alternative roles where their engagement with complex problem-solving is minimized might be a pragmatic solution. This could involve tasks that are more routine or administrative, thus reducing their counterproductive impact on core development teams.
This approach focuses on mitigating the negative drag on skilled developers and project timelines. By reassigning the individual to a role where their reliance on AI as a proxy has less impact, the organization can better utilize its experienced engineers and protect the quality and integrity of its codebase.
Where This Approach Does Not Fit
The 'AI as a proxy' problem is fundamentally a human and process issue, not solely a technical one. Therefore, solutions relying purely on technical fixes, like using AI to review AI code, are unlikely to succeed in the long term. The core of the problem lies in a developer's intentional or unintentional abdication of responsibility for understanding and ownership of their code. This approach is ill-suited for situations where genuine innovation, complex problem-solving, and deep domain expertise are critical. Relying on AI as a proxy in such contexts leads to brittle systems, unmanageable technical debt, and a team that stagnates rather than grows. It also fails where code requires adherence to highly specific, project-internal architectural patterns or business logic that a general-purpose AI has not been trained on.
This article draws on How to deal with a programmer who acts as a proxy for AI? and answers to it (1, 2), on the Stack Exchange network, licensed under CC BY-SA 4.0.
- #AI
- #Artificial Intelligence
- #Programming
- #Software Development
- #code-reviews
- #teamwork



Comments