Where AI engineering gets stuck
Coding agents and chat assistants are already good at a lot of day-to-day engineering. The trouble starts when the facts a task needs live outside the folder that is open or the text that was pasted: in another repository, in a running service, in a CI system or in a teammate's head. This page says fairly what the agents do well, names each recurring place they get stuck and the mechanism behind it, and points to the use-case page that covers it in depth. The index at the end lists every activity.
What the agents already do well
Start from what works, because most of the remaining problems are about reach, not reasoning.
- Claude Code, or a similar coding agent, in a local checkout reads, searches and edits any file in the repositories cloned on the machine, including several at once if you clone them.
- It runs shell commands: git log, blame and diff, test runners, linters and builds, and gh for pull requests and GitHub Actions logs.
- It uses cloud and cluster CLIs such as aws, gcloud, az, kubectl and terraform, if they are installed and credentialed on the machine.
- It uses any MCP server you configure, for example a vendor server for GitHub, Sentry, Datadog, Grafana or a cloud provider, each set up and credentialed separately.
- It fetches web pages and documentation, and reasons well over whatever it retrieves.
- ChatGPT and Claude chat reason well over pasted logs, stack traces, diffs, screenshots and uploaded files, search the web, and use whatever connectors are enabled.
If everything a task needs is in the open repository, or in text you can paste, an agent on its own is often enough. The gaps below are the cases where it is not, and in most of them the agent could get there with enough cloning, configuration and direction from you. The cost is in that setup, and in knowing that it is needed.
The nine places it gets stuck
| Where it gets stuck | Why it happens | Covered in depth in |
|---|---|---|
| 1. Re-created helpers and broken callers | Only cloned repositories are visible, and search is literal and local | Build a feature; Refactor or upgrade safely |
| 2. Cross-service links are missed | HTTP, queue and config links between services are not references in source | Ship a cross-repository change; Understand system architecture |
| 3. No runtime, cloud or CI context | Each tool needs its own MCP server or CLI and credentials, and the agent stitches results itself | Debug a production error; Explore cloud infrastructure |
| 4. The wrong service is queried | The same service has different names in different tools | Monitor service health |
| 5. False zeros | An empty result looks the same as not scanned or not connected | Review security and exposure; Investigate deployments and CI failures |
| 6. The wrong deploy is blamed | There is no organisation-wide deploy timeline unless every CI system is queried | Investigate deployments and CI failures; From incident to fix |
| 7. It stops early and generates | Context limits and step budgets make broad searches expensive | Understand and onboard to a codebase; Build a feature |
| 8. One large diff nobody can review | There is no built-in plan, approval or write-scope boundary | Delegate approved work; Review a pull request |
| 9. Re-explaining the system every session | Context lives in prompts and people, not in a shared place | Keep context across the team |
1. It only sees what is cloned, and searches it literally
A coding agent's tools work on the filesystem. Grep, glob and ripgrep return exact matches in the folders on your machine, and their default ignore rules skip node_modules and build output, so an installed shared package is invisible too. Find-usages in an editor is local in the same way.
To the agent, an empty search reads as 'it doesn't exist'. So it writes a new helper instead of reusing the one in a shared repository, and it changes a function signature after updating every caller it can see, which is every caller in the repositories you happened to clone.
Example: the agent renames formatMoney to formatCurrency in shared-utils, updates the three callers it finds in the two repositories you have cloned, and the tests pass. Two other services that are not on your machine still import formatMoney and fail when they next upgrade the package.
What removes it: CodeZero indexes the organisation's repositories, including ones not checked out locally, and searches them by text, symbol, references and topic, preferring your local working tree where you have one. References are matched by name and callers are heuristic, so treat them as a thorough starting list, not a compiler's proof.
2. Links between services are not in the source
Services talk to each other through a URL built from an environment variable, a queue topic named in a string, or a hostname in a Helm values file. None of those is an import or a symbol reference, so no amount of find-usages connects the producer to its consumers. The agent can read every line of the service and still not know who calls it.
Example: you remove shippingEta from the GET /orders/:id response in orders-api. web-storefront calls it as fetch(`${ORDERS_API_URL}/orders/${id}`) and notifications-worker reads the same field from order.updated events. Searching orders-api for shippingEta finds only the code you are deleting.
What removes it: CodeZero Graph infers cross-repository edges. It matches HTTP calls to declared routes in other repositories, finds services referenced through Kubernetes, Helm or Compose config, and pairs queue producers with consumers. Each edge shows file:line evidence, and HTTP and config edges also show a confidence. Verify asks the agent to check the call site. The verdict is kept for the whole organisation.
3. Runtime, cloud and CI context needs per-tool setup
Most debugging and operations questions are about the running system. A coding agent can answer them, but only through a separately configured MCP server or CLI for each tool, with credentials on the developer's machine, and then it has to stitch the results together itself. A chat assistant only sees what you paste. Each missing tool is a silent gap, and production credentials on every laptop are a risk most teams would rather not take.
Example: to answer 'is checkout erroring since the last deploy, and what does it depend on?', the agent needs a Datadog server, a Sentry server, the Argo CD CLI, kubectl for the cluster and aws for the load balancer and database. You have three of the five set up, so the answer covers three of the five.
What removes it: Vörr connects cloud accounts (read-only), more than 30 observability, error-tracking and CI/CD tools, and your repositories once, at the organisation level. It exposes them to Claude, ChatGPT or another MCP assistant through one connector. Stored credentials are never exposed to the assistant, and it is read-only towards your systems.
4. The same service has different names in each tool
The repository is called checkout-service, the APM calls it checkout-svc, the error tracker calls it web-checkout and the deploy tool calls it checkout. An agent querying each tool has to guess the mapping. When it guesses wrong it either gets nothing back or picks up a similarly named service, and it reports either result with the same confidence.
Example: asked for checkout's error rate, the agent queries 'checkout' in every tool. The APM returns checkout-worker, a background job, and the error tracker returns nothing. The summary says the error rate is low and there are no new errors.
What removes it: Vörr resolves names through the service map, then confirmed aliases, then catalogue names, then the raw name. Every result carries its source, its match quality (explicit, identity, exact, name, suggested or unmapped) and its environment, and you can list the real service, job and project names in each tool.
5. An empty result looks like a real zero
Nothing in a grep result tells you which repositories were not cloned. A query against a tool that is not connected, or a cloud API call that was denied, can also come back empty. The agent has no coverage signal, so 'nothing found' turns into 'there is nothing'. These are the most expensive answers, because they sound like good news.
Example: 'Are any storage buckets public in the production account?' comes back with 'none found'. The role the agent used had no permission to read bucket policies, so every check returned access denied, and the agent summarised that as zero.
What removes it: Vörr reports scan coverage per cloud service (completed, scanned-empty, access denied, failed, throttled), unindexed resource types and Terraform coverage. It says 'no connector' instead of returning zero, and it lists which sources can answer a question and which services nobody watches. With CodeZero, ask which repositories were searched before you accept that nothing calls a function.
6. There is no organisation-wide deploy timeline
git log and gh show the history of the repository you are in. Deploys of other services, made through Argo CD, Jenkins, Flux CD or another CI system, are not in that history. When a symptom starts, the agent reaches for the most recent change it can see, which is not necessarily the one that caused it.
Example: checkout p99 doubles at 14:10. The agent finds a checkout commit deployed at 13:50, a copy change, and proposes reverting it. The actual cause is inventory-service, deployed by Jenkins at 14:05, which checkout calls on every request.
What removes it: Vörr's deploy feed combines every connected CI/CD source, plus GitHub Actions, GitLab CI and Bitbucket Pipelines through the code connection, with regression windows Vörr detects (with Grafana connected), shown alongside deploys. Root-cause scoring weighs the preceding deploy alongside memory, CPU, dependency, database and other causes, and CI build failures come back already diagnosed with category, phase and reason, plus failing test names where the CI source reports them (Jenkins, CircleCI, Buildkite and Drone).
7. Context and step budgets make it stop early
Every file read, search result and log page uses context, and a long search gets compacted or cut short. A broad search across many repositories, or thousands of log lines, fills that context quickly. After a few searches come back empty or noisy, the agent tends to stop looking and produce the most plausible answer from what it has: new code, or a summary of the first page of results.
Example: asked how payment retries work, the agent reads the first eight files that mention retry, explains a retry loop in a deprecated client, and never reaches the queue-based retry worker that production uses.
What removes it: answers that are already aggregated, so one question replaces many reads. In CodeZero that means the organisation index, Graph, Functions (which shows each functional area's Entry, Goes Through and Reads / Writes) and topic context. In Vörr it means top errors with counts, metrics per source, blast radius with true counts and a single trace's bottleneck span.
8. One large diff, and no plan, approval or write-scope boundary
An agent can write a plan, and plan mode or permission rules can hold edits until you agree, but the approval is a setting you manage per session and machine, and nothing scopes edits to the repositories the plan named. You can confirm every edit and stay at the keyboard, or turn confirmations off and get one large pass across several repositories at the end. Neither gives you a reviewable unit of work.
Example: 'add a due date to invoices' comes back as a 40-file diff across three repositories. It includes a regenerated lockfile, a CI config change and a new date helper nobody asked for. The reviewer cannot tell which changes were decisions and which were accidents.
What removes it: in CodeZero, the agent investigates first and asks the decisions the code cannot answer. It then produces a plan naming the repositories, the phases and the verification commands, and it cannot approve that plan itself. After approval, the agent asks before editing outside the plan's repositories, the work becomes tasks you can run one at a time, by phase or all together, and outside Coffee Mode only the declared verification commands run without asking. Coffee Mode can finish an approved, fully clarified plan unattended. It never commits, pushes or switches branches.
9. Re-explaining the system every session
Each new session starts from the open repository plus whatever instruction files you maintain for it. Those files help, but they are per repository and written by hand. What the team has learned, such as which service really calls which, what a service is called in each tool, and which inferred link turned out to be wrong, lives in people's prompts and heads. So each engineer's assistant works from a slightly different picture.
Example: on Monday you establish with your agent that billing gets tax rates from tax-service through a queue, not a database read. On Tuesday a teammate's agent assumes a direct read and plans a schema change in the wrong repository.
What removes it: the context lives in the products rather than in prompts. CodeZero has the shared index, generated feature names and Verify verdicts kept for the organisation. Vörr has the connected sources, the service map and confirmed aliases. Everyone asks against the same picture.
Which product removes which blocker
- CodeZero (VS Code, with Claude Code, Codex, GitHub Copilot or Cursor as the agent)
- Blockers 1, 2, 7, 8 and 9 on the code side: the organisation index, cross-repository search, Graph with inferred edges and Verify, Functions, and plans the agent cannot approve, with confirmation before any edit outside the plan's repositories.
- Vörr (from Claude, ChatGPT or another MCP assistant)
- Blockers 3, 4, 5, 6 and 9 on the runtime side: connected cloud, observability and CI/CD sources, name resolution with match quality, coverage and 'no connector' answers, and the organisation-wide deploy feed.
They are separate products that work side by side. Vörr does not run inside CodeZero, and CodeZero does not call Vörr. A typical investigation takes the service, deploy and error that Vörr identified into a CodeZero prompt.
Habits that catch these problems with any setup
- Ask what was covered: which repositories were searched and which sources were queried. An empty answer means nothing until you know.
- Ask how a service name was matched before you trust a number about it.
- Ask for the deploys in every service in the window before a symptom, not just the deploys in the repository you are in.
- Ask for file:line evidence behind any claim that one service calls another, and check the call site for the ones that change your plan.
- Agree a plan, with the repositories and verification it names, before any edits happen.
Starter prompts
Each of these runs into one of the blockers above if the agent has only the open repository to work from. Each activity page has many more.
Before writing anything: does any repository in the organisation already do this? Search by topic as well as by name, include shared packages, and tell me which repositories you searched.Which services in other repositories call this route or consume this event? Give each one with its confidence and file:line evidence, and separate direct references from inferred ones.Using Vörr, is checkout degraded in production? Give error rate and p95 per source, with the matched service name and match quality, and list every deploy in the organisation in the hour before it changed.Using Vörr, which sources and scans could answer this, and were any of them access denied, failed, throttled or not connected?Find your activity
| If you are trying to… | Page |
|---|---|
| Get productive in an unfamiliar codebase | Understand and onboard to a codebase |
| See how services, data and dependencies fit together | Understand system architecture |
| Answer questions about the system from Claude or ChatGPT, without opening an IDE | Answer system questions without the IDE |
| Add behaviour to a service, reusing what already exists | Build a feature |
| Make a change that spans several repositories | Ship a cross-repository change |
| Rename, change an API or upgrade a dependency without breaking callers | Refactor or upgrade safely |
| Find, write and run the tests that cover a change | Write and run tests |
| Understand what a pull request really affects | Review a pull request |
| Hand off well-defined work and review the result | Delegate approved work |
| Work out why a pipeline or deploy failed | Investigate deployments and CI failures |
| Explain an error or latency change in production | Debug a production error |
| Move from an open incident to a safe, verified fix | From incident to fix |
| Check health, SLOs, alerts and coverage for a service | Monitor service health |
| Find out what runs in your cloud accounts and what depends on it | Explore cloud infrastructure |
| Check what is publicly exposed and how far a failure would spread | Review security and exposure |
| Find waste and savings in AWS spend | Reduce cloud cost |
| Scope and size product work against the real system | Plan product work |
| Weigh a technical decision with evidence from code and runtime | Make engineering decisions |
| Give the whole team the same context | Keep context across the team |
Where to go next
For how the two products divide the work and hand findings to each other, read How Vörr AI and CodeZero work together. For the published research behind these blockers, covering code duplication, trust in AI output, delivery stability and time spent finding information, see What the research says.