The Limitations of Agentic Coding (and How Humans Fill the Gap)

By the apprat.io AI Code Engineering Team 7 min read

In short: Coding agents can invent APIs, weaken tests, miss security flaws, lose context in long sessions and produce inconsistent architecture. These failures are manageable with small tasks, strong tests, careful review and real-device testing, which keep accountability with people.

Coding agents are impressive, and that is exactly why their limitations deserve a plain description. Teams that understand where agents fail get more value from them, because they put human attention where it matters. This is not an argument against agentic coding; it is the reasoning behind our approach of AI speed with human responsibility. Capabilities improve over time, so treat the list below as patterns to watch for, not permanent truths.

Seven common limitations

Limitation 1: Confident wrongness

Agents can call library functions that do not exist, use options that were removed or mix versions. The code looks right and may even compile in dynamic languages until the line runs. Human gap-filler: run the code, read dependency documentation for anything unfamiliar and rely on type checkers and tests.

Limitation 2: Tests that prove too little

An agent that is asked to make tests pass may change the assertion, mock away the interesting part or write tests that mirror the implementation. Gap-filler: review test changes first, and write acceptance criteria before the agent starts.

Limitation 3: Security blind spots

Missing authorization checks, trusting client input, secrets in code, weak session handling and unsafe file uploads are common in generated code, because plausible code is not the same as hardened code. Gap-filler: human security review of authentication, payment and data access, with automated scanning as a supplement.

Limitation 4: Lost context

In long sessions early constraints fade, and in big codebases the agent may not find the relevant module. The result is duplicated helpers or contradictory patterns. Gap-filler: short tasks, fresh sessions and instruction files; see AGENTS.md and CLAUDE.md.

Limitation 5: Architecture drift

Each change may be locally reasonable while the whole slowly becomes inconsistent. Agents optimize for the task at hand, not the long-term shape of the system. Gap-filler: an engineer owns the architecture, reviews structure and schedules refactoring.

Limitation 6: No access to reality

An agent cannot feel that a screen is slow, notice a confusing permission prompt or see how an app behaves on a cheap phone with weak signal. It also cannot read the mind of your customer. Gap-filler: testing on real iOS and Android devices and talking to users.

Limitation 7: Store and legal context

Apple and Google policies, privacy law and licensing are specialized and change over time. Agents may be outdated or oversimplify. Gap-filler: humans verify current requirements, such as App Store Review Guideline 4.2 on minimum functionality and Google Play testing rules, before release.

A habit set that works

  1. Keep tasks small enough to review in one sitting.
  2. Define success before the agent starts.
  3. Run tests and static analysis yourself.
  4. Read dependency and configuration changes carefully.
  5. Test on physical devices.
  6. Name a responsible person for every release.

An example of the gap in practice

Picture an agent asked to add a profile photo upload. It produces a neat screen, an upload function and a passing test. A human reviewer then asks four questions the agent never raised. What file types and sizes are accepted? Who may view or delete the image? How is it stored, and where, given privacy law? What happens on a slow mobile connection when the upload fails halfway? None of these is exotic, yet each can become a security or support problem. This is the ordinary work of an engineer, and it is why we keep a person accountable for every change.

What this means for planning

Budget review and testing as first-class work, not leftovers. If you ignore these limits, the cost reappears later as rescue work; see our rescue playbook for broken AI-generated apps and the explanation of human-in-the-loop development.

How apprat.io fills the gap

Our AI Code Engineers use coding agents such as Claude Code, OpenAI Codex and Cursor for implementation, then plan, review every change, test on real devices, handle store submission and take accountability. ISO 9001 and ISO 27001 certified processes keep that discipline consistent. If you have an AI-generated app you are unsure about, book a call for free.

Frequently asked questions

What are the biggest limitations of coding agents?

Hallucinated APIs, weak tests, security blind spots, lost context and architecture drift are the most common patterns, along with the inability to test on real devices.

Will these limitations disappear soon?

Agents improve, but accountability, security judgment and real-world testing remain human responsibilities for the foreseeable future.

How can I tell if my AI-generated app has problems?

Run a code audit covering security, tests, dependencies and performance. Real-device testing often reveals issues quickly.

Does this mean I should avoid agentic coding?

No. It means pairing agents with review, testing and clear accountability.