code0Vörr AIContactDocs
Book a Demo

Make engineering decisions

Use caseIntermediate15 min

Tech leads, architects and engineering managers make calls that span more than one repository and more than one tool: whether an area is worth paying down, whether to build or reuse, how risky a change is, who owns what, and when something can be switched off. This page covers the operations for gathering the evidence behind those calls from indexed code and production signals, and for writing the decision down so others can check it. The agent gathers and reasons over the evidence. The decision stays with you.

When you'd do this

  • You have a quarter's worth of capacity for platform work and need to decide which area's debt is worth paying down, with something better than the loudest complaint.
  • A team proposes building a new rate limiter, PDF renderer or retry helper, and you suspect one already exists somewhere in the organisation.
  • A change to a shared API, message or table is on the table and you need to know its blast radius and how healthy the affected services are before you approve it.
  • Someone senior is leaving, and you want to know which services only they have touched and which resources nobody owns or watches.
  • You want to retire a service, endpoint or internal library and need every consumer, the traffic still reaching it and a staged plan.
  • Two designs are on the table and you have been asked for an ADR that a reviewer can check against the real system.

Before you start

  • CodeZero installed in VS Code with your coding agent (Claude Code, Codex, GitHub Copilot or Cursor), and the organisation's repositories connected and indexed. The index covers committed code on each repository's default branch, including repositories nobody has cloned.
  • Vörr connected to Claude, ChatGPT or another MCP assistant, with your repositories connected and, for the production side, your cloud accounts (AWS, Google Cloud or Azure, read-only) and the observability and CI/CD tools you use. Vörr works with more than 30 of them; connect the ones that hold your error rates, SLOs, alerts and deploys. ChatGPT needs a paid plan with Developer mode turned on.
  • Repositories and resources mapped to workspaces and environments in Vörr, so code, cloud and monitoring names line up. An admin manages connections and the service map. Answers draw on the organisation's connected sources, and workspaces label what comes back.
  • Somewhere to keep decisions: a repository with an ADR or docs folder that CodeZero can write to through an approved plan.

If any of this isn't set up yet, start here:

Operations

Each operation below gathers one kind of evidence for one kind of decision. CodeZero supplies the code side: search, symbols, references, Graph (with its inferred cross-repository edges and data layer), recent commits and owners by commit history. Vörr supplies the production side: cloud resources and blast radius, workspace mapping, error rates, SLOs and error budgets, alerts, deploys and regressions, and coverage. The two are used side by side; Vörr does not run inside CodeZero. Neither product produces a debt score, a risk score for a design or a recommendation you should accept unread. The agent reasons over what they return, and you judge the reasoning.

1. Assess tech debt in an area

  1. CodeZero: ask for the dependency graph for the area, at module level across repositories or at file level within one. Read how many other repositories depend on it and how many it depends on.
  2. CodeZero: search across all indexed repositories for duplicated helpers in the area's domain (date handling, retries, money formatting, clients for the same service). Symbol definitions with the same or similar names in several repositories are a good starting point.
  3. CodeZero: read recent commits for the area's paths and the owners view. High churn spread over many authors, or concentrated in one, tells you different things.
  4. Vörr: for the services the area belongs to, ask for top errors, error rate and latency against the previous week, alerts that fired, and recent deploys alongside any regression windows Vörr detects (with Grafana connected).
  5. Agent: put the four together in a short table per area: coupling, duplication, churn and owners, production signals. Ask it to say which findings are measured and which are its interpretation.
CodeZero ChatAssess the tech debt in the billing domain from evidence. Give me: inbound and outbound cross-repository edges for its modules, helpers duplicated in other repositories (cite each definition), commit churn and the top committers for its paths over recent history. Separate what the index shows from your interpretation. Do not produce a single score.
Vörr in Claude or ChatGPTUsing Vörr, for billing-api and invoice-worker in production: top errors with counts and culprits, error rate and p95 against 7 days ago per source, alerts that fired in the last 30 days, and recent deploys with any regression window you detect around them. Name the source and match quality for each.

A good result lets someone disagree with the conclusion from the same evidence: every coupling claim cites edges, every duplicate cites two or more definitions, churn cites commits, and every production number names its source. Check a sample of the cited files, and check that the Vörr results are matched to the right service and environment, with any name match checked, rather than unmapped.

2. Decide build versus reuse

  1. CodeZero: search all indexed repositories for an existing implementation, by symbol name, by text (the library it would wrap, the error messages it would raise) and by topic using Go deep.
  2. CodeZero: for each candidate, read its definition and references to see how widely it is used, its manifest dependencies, its recent commits and its owners.
  3. Vörr: if the candidate runs as a service, check its health in production: up or down, error rate, current SLO status, and any regression windows Vörr detects (with Grafana connected).
  4. Agent: compare the candidates on fit, adoption, maintenance and production health, and list what would need to change to reuse each one.
CodeZero ChatBefore we build a new rate limiter: does one already exist anywhere in the organisation? Search symbols, text and topics across all indexed repositories. For each candidate, show where it is defined, how many repositories reference it, when it last changed and who maintains it by commit history.
Vörr in Claude or ChatGPTUsing Vörr, how healthy is the shared notification-service in production? Up or down, error rate and p99 per source, current SLO status with remaining budget where the source reports it, and any regression window around recent deploys.

A good result either finds candidates with evidence or says what it searched and where it might still be hiding (a language that is only text-searchable, a repository that is not connected). Name-based references can include same-named symbols from unrelated code, so open the reference list before quoting adoption counts.

3. Assess the risk of a proposed change

  1. CodeZero: find every consumer of what is changing across repositories: references and callers for code, inferred HTTP edges matched to the route, queue consumers for a message, and readers and writers in the data layer for a table.
  2. CodeZero: Verify the medium- and low-confidence edges the assessment depends on. The agent reads the call site and records a verdict for the organisation.
  3. Vörr: map the consuming repositories to environments, and ask for the upstream and downstream blast radius of any cloud resource involved.
  4. Vörr: for each affected service, ask for the current error rate, current SLO status, firing alerts, and regression windows Vörr detects (with Grafana connected) or recurring incident patterns.
  5. Agent: rank the consumers by exposure: production and high-traffic first, services already outside their SLO target called out, unverified edges marked.
CodeZero ChatWe want to change the response shape of GET /v1/customers/:id in customer-api. List every caller in every indexed repository, with the file, the confidence of the edge and the fields each caller reads. Verify the medium and low ones.
Vörr in Claude or ChatGPTUsing Vörr, for checkout-web, support-tools and reporting-worker: which environments are they deployed to, what is their current error rate and SLO status, are any alerts firing, and is there a regression window around any recent deploy?

A good result has two lists, consumers in code and dependents at runtime, plus the health of each one, with the disagreements between the lists called out. A runtime dependent with no code counterpart usually means an unconnected repository or a scheduled job. For carrying out a risky change, use Refactor or upgrade safely or Ship a cross-repository change.

4. Inform a schema or data-contract decision

  1. CodeZero: turn on the data layer in Graph and select the table or collection. Read every module, in every repository, that reads or writes it.
  2. Agent: separate writers from readers, and code that names columns from code that uses whole rows, citing the query or model for each.
  3. CodeZero: for messages, list producers and consumers of the topic and where each parses the payload.
  4. Vörr: for the stores involved, check blast radius and which environments they serve.
CodeZero ChatWhich code reads and which code writes the subscriptions table across all repositories? For each, give the file, read or write, and whether it selects columns by name. If we split plan_id into plan_id and plan_version, which repositories need to change?

This is the operation data engineers use most. A good result calls out every writer explicitly, because a second writer is usually the real decision. Queries built at runtime may not appear in the data layer; search for the table name as text to cross-check.

5. Map ownership and bus factor

  1. CodeZero: read owners by commit history for each repository or path in scope. A path where one person holds most of the commits, and that person is moving on, is a bus-factor risk.
  2. Vörr: list the workspaces and the repositories and resources mapped to each, so ownership in code can be compared with ownership at runtime.
  3. Vörr: search for cloud resources that are not mapped to any workspace, and ask the coverage question: which services nobody watches, meaning no connected monitoring source reports on them.
  4. Agent: join the three into one table per service: top committers, workspace, monitoring coverage, and gaps.
CodeZero ChatFor every repository in the payments area, list the top committers by commit history and the share of recent commits each holds. Flag paths where one person accounts for most of the history.
Vörr in Claude or ChatGPTUsing Vörr, which production resources are not mapped to any workspace, and which services are not watched by any connected monitoring source? Group them by account and tell me the scan coverage behind the answer.

Commit history is a proxy for knowledge, not a statement of ownership; people who review but rarely commit will not show. A good result treats unmapped resources and unwatched services as a list of gaps to fix in the service map and monitoring, not as resources to delete.

6. Deprecate or sunset a service, API or library

  1. CodeZero: find every consumer: imports and references for a library, inferred HTTP edges to each route for an API, deployment-config references for a service, and queue consumers for anything it publishes.
  2. CodeZero: Verify the inferred edges, and note routes with no matched caller. These are either unused or called from outside the indexed code (browsers, partners, cron jobs).
  3. Vörr: ask for throughput and callers from connected sources (metrics and the trace service graph) for the service and its routes, so you know what is still sending traffic.
  4. Vörr: check the resources that would be freed, their blast radius and, on AWS, the spend attached to them.
  5. Agent: draft a staged plan: announce, migrate consumers one by one, watch traffic fall, switch off, remove code and infrastructure. Attach the consumer list and the traffic evidence to each stage.
CodeZero ChatWe plan to retire legacy-pricing-api. List every consumer in every indexed repository: HTTP calls matched to its routes, services that reference it through Helm or Kubernetes config, and queue consumers of what it publishes. List its routes with no matched caller.
Vörr in Claude or ChatGPTUsing Vörr, what traffic is legacy-pricing-api still receiving in production? Throughput and callers per route from each connected source over the last 14 days, and the downstream blast radius of the resources it runs on.

A good result has a consumer list that matches the traffic. A route that still receives traffic with no caller in the code is the case to chase before switching anything off. If no monitoring source covers the service, the traffic answer comes back as no connector rather than zero; treat that as unknown.

7. Choose between options and record an ADR

  1. You: state the decision, the options and the constraints. The agent should not invent options you did not ask for without saying so.
  2. Agent: gather evidence for each option with the operations above: consumers and edges from CodeZero, production health and blast radius from Vörr, owners and churn from commit history.
  3. Agent: draft the ADR with context, options, evidence, consequences and open questions. Every claim cites a file and line, a graph edge with its file:line evidence (and its confidence, where it has one), or a Vörr source and time window.
  4. CodeZero: the agent proposes writing the ADR into your docs or ADR folder as a plan. You approve it; the agent cannot approve its own plan, and it asks before editing outside the plan's repositories.
  5. You and the reviewers: make the decision and fill in the Decision section. The assistant can recommend; it does not decide.
CodeZero ChatDraft an ADR in docs/adr/ comparing two options for order events: keep the shared orders database that reporting reads directly, or publish order events and have reporting consume them. Use the indexed evidence: readers and writers of the order tables, queue producers and consumers, owners of each repository. Cite every claim. Leave the Decision section empty for us.
Vörr in Claude or ChatGPTUsing Vörr, give me the evidence for the ADR's production section: blast radius of orders-prod, error rate and SLO status of reporting-worker and orders-service, and any alerts or regression windows on either in the last 30 days. Cite source and window for each figure.

A good ADR states what was checked and what was not, so a reader knows where the evidence ends. Keep it in the repository next to the code it describes, so the next person who asks why can find it.

8. Prioritise reliability work

  1. Vörr: list alert rules and their thresholds, then ask for the firing history of the rules you suspect (Grafana and SigNoz). Rules that fire and resolve repeatedly, or that are silenced, are candidates for tuning or removal.
  2. Vörr: list SLOs and their current status, with remaining budget where the source reports it.
  3. Vörr: ask which services nobody watches and which sources cannot answer which questions, for example silenced or failing rules.
  4. Vörr: on AWS, add waste patterns and rightsizing findings so cost work competes for the same capacity on the same evidence.
  5. Agent: build a ranked list: unwatched production services, SLOs outside target, flapping alerts, cost waste. For each item, cite the signal and link the owning repository and its top committers from CodeZero.
Vörr in Claude or ChatGPTUsing Vörr, help me prioritise reliability work for next quarter. List alert rules and their thresholds, then give the firing history for the checkout and billing rules (Grafana and SigNoz). Add SLOs and their current status, production services no connected source monitors, and reasons any of these answers might be wrong. Cite source for each.

Keep the ranking yours: the list orders evidence, it does not weigh business importance. For the day-to-day version of this, see Monitor service health; for cost, see Reduce cloud cost.

9. Decide how the team adopts CodeZero and Vörr

Adoption is itself an engineering decision, and the guardrails are part of it. Start with what gives one shared picture fastest, and widen once mapping and coverage are in a state you trust.

  • Connect first: the repositories the team changes most, then the cloud account for production, then the monitoring and CI tools that hold your error rates, SLOs and deploys.
  • Read-only by default: Vörr scans cloud accounts with read-only credentials and is read-only towards your systems from the assistant. Stored credentials are never exposed to the assistant.
  • Consent: each user explicitly consents before connecting their assistant to Vörr.
  • Workspace scoping: members see their own workspaces; admins manage connections and the service map. Decide who maps repositories and resources, because unmapped items weaken every answer above.
  • Change people can review: in CodeZero, Planned mode keeps the agent from changing code until a plan is approved, the agent cannot approve its own plan, the agent asks before editing outside the plan's repositories, and only the declared verification commands run without asking.
  • Bounded autonomy: Coffee Mode only runs an approved, fully clarified plan. It never commits, pushes, switches branches, rewrites or merges history, publishes or runs destructive commands; changes stay in the working tree with a summary of the decisions the agent made.
  • Knowledge that stays: verified edges, feature names in Functions, plans and ADRs written into repositories remain for the organisation when people move on, and the tech lead stops being the only place the context lives.

What to watch after adoption: review load on leads, cross-repository breakage caught at plan time rather than after merge, how often leads are interrupted for context, and workspace mapping and scan coverage over time. These are signals to track yourself, not figures the products report. For the published research on AI adoption, delivery stability, time lost to finding information and developer trust in AI output, see What the research says.

Without CodeZero or Vörr

Claude Code in a checkout is good at much of this. It can read a repository's structure, count imports, run git log and git blame for churn and authors, grep for duplicated helpers across every repository you have cloned, and draft a clear ADR from what it finds. With gh, cloud CLIs and vendor MCP servers for your monitoring tools configured and credentialed, it can pull CI history, resources and error rates too. ChatGPT or Claude chat can reason well over exported dashboards, incident write-ups and pasted diffs.

The gaps are specific. It sees only the repositories you cloned, so a consumer in a repository you did not know about looks the same as no consumer. HTTP, queue and environment-variable links between services are not references in source, and matching them across repositories by hand is expensive in context, so broad searches stop early. Production health needs a separate server or CLI and credentials per tool, and the agent has to reconcile service names that differ between code, cloud and monitoring. There is no coverage signal, so an unwatched service and a healthy one can look alike. And nothing between the draft and the edit enforces a plan or an approval.

OperationClaude Code / ChatGPT on their ownWith CodeZero and Vörr
Tech debtCoupling, churn and duplication within cloned repositories; production signals if each tool is wired up separatelyOrganisation-wide graph, search and commit history (CodeZero) with errors, alerts and detected regression windows per service (Vörr)
Build versus reuseGrep cloned repositories for an existing implementationSymbol, text and topic search across every indexed repository, with owners; production health of candidate services
Change riskReferences in cloned code; cross-service callers found by string matchingInferred HTTP, config and queue edges with file:line evidence, a confidence on HTTP and config edges, and Verify; blast radius and SLO status of dependents
Schema decisionsGrep table names and ORM modelsData layer readers and writers across repositories
Ownership and bus factorgit log and blame per cloned repositoryOwners by commit history across repositories; workspace mapping, unmapped resources and unwatched services
DeprecationConsumers in cloned code; traffic from each monitoring tool via its own credentialsConsumers across repositories including HTTP and queues; traffic and callers per connected source, with no connector reported as such
ADRA well-written draft from what it found; coverage is only what the agent reports it searched in cloned repositories.A draft citing edges, files and production sources, written through an approved plan
Reliability prioritiesPossible per tool, stitched by handAlert rules and firing history, SLO status, coverage gaps and AWS cost findings from one assistant

With CodeZero and Vörr

One shared picture of the code (CodeZero)
Every indexed repository is searchable, including ones nobody has cloned, with symbols, references, Graph, and recent commits and owners per path.
Cross-service edges you can check (CodeZero)
HTTP calls matched to routes, deployment-config references, and queue producers and consumers, each with file:line evidence, and a confidence on HTTP and config edges. Verify records a verdict for the organisation.
Data ownership (CodeZero)
Which code reads and writes each table or collection, across repositories.
Production health per service (Vörr)
Error rates and latency per source, never averaged, SLO status, alerts with history, and deploys alongside detected regression windows.
Runtime reach (Vörr)
Cloud resources, workspace and environment mapping, and precomputed blast radius with true counts.
Coverage (Vörr)
Scan coverage per service, unmapped resources, services nobody watches, and reasons an answer might be wrong.
Decisions people can review (CodeZero)
ADRs and changes written through plans that a person approves, with confirmation before any edit outside the plan's repositories.
Combined
CodeZero says who depends on something in code and who has changed it; Vörr says what depends on it at runtime and how it is behaving. A decision that only one side supports is the one to look at again.
Illustrative example

Worked example: retire the legacy pricing API

An engineering manager is asked whether legacy-pricing-api can be switched off this quarter. The team that built it has moved on, and the proposal says only checkout-web still calls it. The tech lead starts with the code side in CodeZero Chat.

Inbound edges to legacy-pricing-api
  checkout-web     GET /v2/quote          high    src/pricing/client.ts:27
  partner-gateway  GET /v2/quote          medium  routes/partners.go:88  (via PRICING_URL in helm/values-prod.yaml)
  invoice-worker   POST /v2/tax-estimate  high    workers/tax.py:41

Queue consumers of pricing.updated
  catalog-sync     consumer                       src/consumers/pricing.ts:15

Routes with no matched caller
  GET /v1/quote
  GET /v2/discounts

Top committers (commit history)
  a.okafor  71%   (no commits in the last 9 months)
  j.lindqvist 18%
CodeZero ChatList every consumer of legacy-pricing-api across all indexed repositories, including deploy-config references and queue consumers, with evidence and confidence where there is one. List its routes with no matched caller, and its top committers.
Illustrative example

Worked example: the production side

legacy-pricing-api (production, workspace: commerce, match: explicit)

Throughput by route, last 14 days (source: Datadog APM)
  GET /v2/quote          ~410 req/min   callers: checkout-web, partner-gateway
  POST /v2/tax-estimate  ~35 req/min    callers: invoice-worker
  GET /v1/quote          ~2 req/min     callers: unknown (no trace context)
  GET /v2/discounts      0

Error rate 0.4% (Datadog), SLO 99.5% availability, 61% budget remaining
Alerts: pricing-latency-p99 fired 9 times in 30 days, resolved each time

Coverage: CloudWatch and Datadog connected; partner-gateway not watched
by any connected source.
Vörr in Claude or ChatGPTUsing Vörr, what traffic is legacy-pricing-api receiving in production per route over the last 14 days, from which callers, and what is its error rate and SLO status? Include coverage.
Illustrative example

Worked example: conclusion, verification and follow-ups

  1. Conclusion: not this quarter as proposed. There are four consumers, not one, and GET /v1/quote still receives traffic with no caller in the indexed code. The single maintainer has not committed in nine months, which argues for retiring it, but on a staged plan.
  2. Verify: the lead asks the agent to Verify the medium-confidence partner-gateway edge. It reads routes/partners.go and helm/values-prod.yaml, confirms the call reaches legacy-pricing-api through PRICING_URL, and records the verdict.
  3. Coverage gap: partner-gateway is not watched by any connected source. Its traffic to the pricing API is visible only from the pricing side. The lead raises adding it to monitoring as a reliability item.
  4. Unknown caller: the GET /v1/quote traffic has no trace context. The lead asks the partner team to identify the caller before the route is removed.
  5. Record: the agent drafts docs/adr/0042-retire-legacy-pricing-api.md citing the edges and production figures above, through a plan the lead approves. The manager and lead fill in the Decision: migrate invoice-worker and catalog-sync first, remove GET /v2/discounts now, and revisit after the unknown caller is identified.
  6. Follow-up: each consumer migration becomes its own plan through Ship a cross-repository change, and the flapping latency alert goes into the reliability list.

Verify and follow up

  • Provenance: every claim should cite a file and line or a commit (CodeZero), or a source, window and environment (Vörr). Open a sample, and every one the decision rests on.
  • Confidence and verdicts: Verify medium- and low-confidence inferred edges before relying on them. Wrong and retargeted verdicts change risk assessments too.
  • Match quality: treat inferred Vörr matches as needing a check and unmapped ones as gaps in the service map. Make sure figures are for the right environment.
  • Coverage: check the index includes every repository you expect, the cloud scan completed for the services involved, and a monitoring source covers each service you quote numbers for. A missing connector is unknown, not zero.
  • Interpretation: ask the agent to label which parts of its assessment are measured and which are its reasoning, and challenge the reasoning.
  • Record: write the decision into the repository as an ADR through an approved plan, and before the next review ask the agent to compare the ADR's evidence with the current index and signals.
  • Next: carry out the change with Refactor or upgrade safely or Ship a cross-repository change, and track the reliability items with Monitor service health.

Limits

  • Neither product scores tech debt, rates a design, or makes the decision. The agent's assessment is reasoning over evidence and needs checking like any other analysis.
  • CodeZero's relationships are heuristic, not compiler-accurate. References match by name, so same-named symbols can appear, and callers and callees are approximate.
  • Inferred edges can be wrong or missing where URLs are built at runtime, gateways rewrite paths, or topic names live only in infrastructure.
  • The index covers committed code on the default branch of connected repositories. Unconnected repositories and callers outside the organisation's code are not visible.
  • Owners by commit history measure who changed code, not who is accountable for it or who reviews it.
  • Production evidence is bounded by what is connected: cloud accounts, the latest scan and the monitoring and CI tools added to Vörr. Cost analysis is AWS only.
  • Vörr is read-only from the assistant. It reports on infrastructure and monitoring; it does not change alert rules, mappings or resources from chat.
  • Traffic and error figures reflect the window and sources you asked about. Short windows can miss monthly jobs and seasonal callers.

Related