Limitations: hallucination and knowledge cutoff
To work safely with an agent you need to know where and why it goes wrong. There are three main sources:
- Hallucination — the model convincingly writes an API, function or behaviour that does not exist. The cause is picking a continuation by probability: "there ought to be such a method" can outweigh "such a method exists".
- Knowledge cutoff — training data ends at some date. Library versions, API changes and deprecations after it are unknown to the model.
- Context decay — in a very long session earlier agreements get summarised and detail is lost.
| Risk area | Typical Android symptom | How to catch it |
|---|---|---|
| Non-existent API | A Compose modifier or parameter that does not exist | Compilation — it fails immediately |
| Outdated approach | A deprecated library or old Gradle syntax | Lint warnings plus a check against the official docs |
| Wrong behaviour (it compiles) | A coroutine launched in the wrong scope | Unit/UI tests, code review |
| Fabricated fact | "This exists from API level 26" — an unverified figure | Checking developer.android.com |
The most dangerous category is code that compiles but behaves wrongly. A compile error announces itself; wrong behaviour can reach production wherever there is no test. That is why test coverage for agent-written code matters more than for hand-written code, not less.
Practical countermeasures:
- Supply version information yourself. Point at
libs.versions.tomlso the agent reads instead of guessing. - Point it at the official docs. If the agent can reach the web, ask it to read the specific page.
- Verify concrete numbers and API claims. Statements like "this exists from API level 26" should not be accepted unchecked.
- Split long sessions. New task → new session. Keep important decisions in CLAUDE.md.
📚 Sources and documentation
- Android official documentationofficialdeveloper.android.com
Where to check every claim about API existence and behaviour.
- Context window and compactionofficialcode.claude.com