Remember this Quora comment (which also became a meme)?
(Source: Quora)
Within the pre-large language model (LLM) Stack Overflow era, the challenge was discerning which code snippets to adopt and adapt effectively. Now, while generating code has turn out to be trivially easy, the more profound challenge lies in reliably identifying and integrating high-quality, enterprise-grade code into production environments.
This text will examine the sensible pitfalls and limitations observed when engineers use modern coding agents for real enterprise work, addressing the more complex issues around integration, scalability, accessibility, evolving security practices, data privacy and maintainability in live operational settings. We hope to balance out the hype and supply a more technically-grounded view of the capabilities of AI coding agents.
Limited domain understanding and repair limits
AI agents struggle significantly with designing scalable systems resulting from the sheer explosion of selections and a critical lack of enterprise-specific context. To explain the issue in broad strokes, large enterprise codebases and monorepos are sometimes too vast for agents to directly learn from, and crucial knowledge may be incessantly fragmented across internal documentation and individual expertise.
More specifically, many popular coding agents encounter service limits that hinder their effectiveness in large-scale environments. Indexing features may fail or degrade in quality for repositories exceeding 2,500 files, or resulting from memory constraints. Moreover, files larger than 500 KB are sometimes excluded from indexing/search, which impacts established products with decades-old, larger code files (although newer projects may admittedly face this less incessantly).
For complex tasks involving extensive file contexts or refactoring, developers are expected to offer the relevant files and while also explicitly defining the refactoring procedure and the encompassing construct/command sequences to validate the implementation without introducing feature regressions.
Lack of hardware context and usage
AI agents have demonstrated a critical lack of know-how regarding OS machine, command-line and environment installations (conda/venv). This deficiency can result in frustrating experiences, akin to the agent attempting to execute Linux commands on PowerShell, which may consistently end in ‘unrecognized command’ errors. Moreover, agents incessantly exhibit inconsistent ‘wait tolerance’ on reading command outputs, prematurely declaring an inability to read results (and moving ahead to either retry/skip) before a command has even finished, especially on slower machines.
This isn't merely about nitpicking features; somewhat, the devil is in these practical details. These experience gaps manifest as real points of friction and necessitate constant human vigilance to observe the agent’s activity in real-time. Otherwise, the agent might ignore initial tool call information and either stop prematurely, or proceed with a half-baked solution requiring undoing some/all changes, re-triggering prompts and wasting tokens. Submitting a prompt on a Friday evening and expecting the code updates to be done when checking on Monday morning shouldn’t be guaranteed.
Hallucinations over repeated actions
Working with AI coding agents often presents a longstanding challenge of hallucinations, or incorrect or incomplete pieces of knowledge (akin to small code snippets) inside a bigger set of changesexpected to be fixed by a developer with trivial-to-low effort. Nonetheless, what becomes particularly problematic is when incorrect behavior is repeated inside a single thread, forcing users to either start a brand new thread and re-provide all context, or intervene manually to “unblock” the agent.
For example, during a Python Function code setup, an agent tasked with implementing complex production-readiness changes encountered a file (see below) containing special characters (parentheses, period, star). These characters are quite common in computer science to indicate software versions.
(Image created manually with boilerplate code. Source: Microsoft Learn and Editing Application Host File (host.json) in Azure Portal)
The agent incorrectly flagged this as an unsafe or harmful value, halting all the generation process. This misidentification of an adversarial attack recurred 4 to five times despite various prompts attempting to restart or proceed the modification. This version format is in-fact boilerplate, present in a Python HTTP-trigger code template. The one successful workaround involved instructing the agent to not read the file, and as a substitute request it to easily provide the specified configuration and assure it that the developer will manually add it to that file, confirm and ask it to proceed with remaining code changes.
The shortcoming to exit a repeatedly faulty agent output loop throughout the same thread highlights a practical limitation that significantly wastes development time. In essence, developers are inclined to now spend time on debugging/refining AI-generated code somewhat than Stack Overflow code snippets or their very own.
Lack of enterprise-grade coding practices
Security best practices: Coding agents often default to less secure authentication methods like key-based authentication (client secrets) somewhat than modern identity-based solutions (akin to Entra ID or federated credentials). This oversight can introduce significant vulnerabilities and increase maintenance overhead, as key management and rotation are complex tasks increasingly restricted in enterprise environments.
Outdated SDKs and reinventing the wheel: Agents may not consistently leverage the most recent SDK methods, as a substitute generating more verbose and harder-to-maintain implementations. Piggybacking on the Azure Function example, agents have outputted code using the pre-existing v1 SDK for read/write operations, somewhat than the much cleaner and more maintainable v2 SDK code. Developers must research the most recent best practices online to have a mental map of dependencies and expected implementation that ensures long-term maintainability and reduces upcoming tech migration efforts.
Limited intent recognition and repetitive code: Even for smaller-scoped, modular tasks (that are typically encouraged to attenuate hallucinations or debugging downtime) like extending an existing function definition, agents may follow the instruction literally and produce logic that seems to be near-repetitive, without anticipating the upcoming or unarticulated needs of the developer. That’s, in these modular tasks the agent may not mechanically discover and refactor similar logic into shared functions or improve class definitions, resulting in tech debt and harder-to-manage codebases especially with vibe coding or lazy developers.
Simply put, those viral YouTube reels showcasing rapid zero-to-one app development from a single-sentence prompt simply fail to capture the nuanced challenges of production-grade software, where security, scalability, maintainability and future-resistant design architectures are paramount.
Confirmation bias alignment
Confirmation bias is a major concern, as LLMs incessantly affirm user premises even when the user expresses doubt and asks the agent to refine their understanding or suggest alternate ideas. This tendency, where models align with what they perceive the user wants to listen to, results in reduced overall output quality, especially for more objective/technical tasks like coding.
There’s ample literature to suggest that if a model begins by outputting a claim like “You’re absolutely right!”, the remainder of the output tokens are inclined to justify this claim.
Constant must babysit
Despite the allure of autonomous coding, the fact of AI agents in enterprise development often demands constant human vigilance. Instances like an agent attempting to execute Linux commands on PowerShell, false-positive safety flags or introduce inaccuracies resulting from domain-specific reasons highlight critical gaps; developers simply cannot step away. Reasonably, they need to continually monitor the reasoning process and understand multi-file code additions to avoid wasting time with subpar responses.
The worst possible experience with agents is a developer accepting multi-file code updates riddled with bugs, then evaporating time in debugging resulting from how ‘beautiful’ the code seemingly looks. This may even give rise to the sunk cost fallacy of hoping the code will work after just a number of fixes, especially when the updates are across multiple files in a fancy/unfamiliar codebase with connections to multiple independent services.
It's akin to collaborating with a 10-year old prodigy who has memorized ample knowledge and even addresses every bit of user intent, but prioritizes showing-off that knowledge ove solving the actual problem, and lacks the foresight required for achievement in real-world use cases.
This "babysitting" requirement, coupled with the frustrating reoccurrence of hallucinations, signifies that time spent debugging AI-generated code can eclipse the time savings anticipated with agent usage. Unnecessary to say, developers in large firms must be very intentional and strategic in navigating modern agentic tools and use-cases.
Conclusion
There is no such thing as a doubt that AI coding agents have been nothing wanting revolutionary, accelerating prototyping, automating boilerplate coding and remodeling how developers construct. The true challenge now isn’t generating code, it’s knowing what to ship, find out how to secure it and where to scale it. Smart teams are learning to filter the hype, use agents strategically and double down on engineering judgment.
As GitHub CEO Thomas Dohmke recently observed: Probably the most advanced developers have “moved from writing code to architecting and verifying the implementation work that’s carried out by AI agents.” Within the agentic era, success belongs to not those that can prompt code, but those that can engineer systems that last.
Rahul Raja is a staff software engineer at LinkedIn.
Advitya Gemawat is a machine learning (ML) engineer at Microsoft.
Editors note: The opinions expressed in this text are the authors' personal opinions and don’t reflect the opinions of their employers.
