AI coding agents hit production: what works, what breaks, and what nobody warned you about
By September 2025, AI coding agents had moved from impressive demos to uncomfortable production realities at companies large and small. Cursor had become a default development environment for a significant fraction of professional developers. Devin, the autonomous software engineer from Cognition AI, was being evaluated in enterprise environments. GitHub Copilot had gained agent capabilities that could edit across multiple files. The results were genuinely positive in specific contexts and genuinely problematic in others. Both needed honest discussion.
Where agents actually work
The clearest wins for coding agents were in narrow, well-specified tasks with a clear definition of success. Writing unit tests for existing code. Adding type annotations to a JavaScript codebase. Migrating from one library version to another with a documented API change. Filling in boilerplate for a pattern the codebase already established. These tasks have enough local context that the agent can reason about them reliably and enough structure that errors are obvious.
At Cursor, the core product insight was that agents work better when they have access to your codebase and can search for relevant context rather than relying only on what is in the active window. The "codebase-aware" editing mode, where the model can read any file and understand the overall structure of the project, produced noticeably better results than pure in-context editing.
The AI coding tool landscape
| Item | Value |
|---|---|
Cursor Best at: Codebase-aware editing, chat Integration: Standalone IDE Autonomy: Medium (needs approval) | |
GitHub Copilot Agent Best at: PR reviews, multi-file edits Integration: VS Code, GitHub Autonomy: Medium | |
Devin Best at: Long autonomous tasks Integration: Standalone + integrations Autonomy: High (can run commands) | |
Claude in Projects Best at: Long-context code review Integration: API, web Autonomy: Low (text only) | |
Aider Best at: CLI-driven agent editing Integration: Terminal, git Autonomy: Medium (approval gated) |
Where agents break
The failure modes were consistent enough across teams that a pattern emerged. Agents failed reliably when tasks required understanding of system-level constraints that were not documented in code. A coding agent that did not know the performance characteristics of a production database could write correct SQL that was catastrophically slow at scale. An agent that did not know the deployment architecture could produce code that worked in tests but failed in production due to environment differences.
The second failure mode was compounding errors. An agent might make a small incorrect assumption early in a long task, produce code consistent with that assumption, and continue building on a foundation that was subtly wrong. By the time a human reviewed the output, unpicking the error required understanding all the dependent choices that followed from it. This was the "confident and coherent but wrong" problem at the task level rather than the sentence level.
The teams that got the most value from coding agents treated them as very capable junior developers who needed to be briefed thoroughly before starting a task and checked after every significant decision, not trusted to run autonomously for hours and produce reviewed-ready output.
The security problem nobody wanted to talk about
By mid-2025, security researchers had documented a class of attack called prompt injection in agentic contexts. When a coding agent reads a file or browses documentation as part of completing a task, a malicious actor could embed instructions in that content that redirect the agent's behaviour. An agent reading a README that contained hidden text instructing it to also push credentials to an external URL was not a theoretical attack. Several proof-of-concept demonstrations had been published.
The problem is structural. Agents that have tools (file access, network access, command execution) and that take instructions from content in their environment are inherently vulnerable to content that looks like instructions. Sandboxing and permission models help but do not fully solve the problem, because the agent often needs broad permissions to complete legitimate tasks.
What changed developer workflows
Setting aside the failure modes, the productivity effect was real. Studies of professional developers using AI coding tools consistently found time savings in the 30 to 55 percent range for tasks the tools handled well. The composition of developer work shifted: less time on boilerplate, syntax lookups, and mechanical refactoring; more time on architecture, review, and requirement elicitation.
The change that surprised teams most was not the speed gain. It was the democratisation of unfamiliar domains. A backend developer who had never written a complex SQL query could now navigate database optimisation problems that previously required a DBA. A frontend developer could now reason about machine learning API integration. The tools lowered the cost of working outside your established competency in ways that affected team composition and hiring.
- 30-55%
- Time saved on suitable tasks
- 40%
- Developers using AI tools daily in 2025
- 7 hrs
- Claude 4 Opus autonomous record (May)
- Prompt injection
- Top agent security threat category