Common questions from engineering leaders.

Because the velocity has already changed and the perimeter hasn’t. AI assistants are generating, refactoring, and merging code at machine speed across every team in your org, while merge review, change management, and audit trails still run at human speed. The result is governance debt that compounds every sprint: code reaches production that no human author can fully explain, no reviewer fully understood, and no policy was ever asked to evaluate. Tomosu closes that gap by inserting a governance layer between AI-generated code and production, so velocity stays high and reliability doesn’t silently erode.

Tests catch what you thought to test for. CI catches what your linters know to look for. Neither catches the failure modes that AI introduces: subtle context drift, plausible-but-wrong dependency choices, business-logic violations that compile cleanly, security regressions that pattern-match to safe code. The 2026 State of AI-Powered Engineering report puts the number at 43%: that’s the share of AI-generated changes that still break in production after passing QA and staging. Tomosu adds a governance evaluation that reasons about policy fit and risk, not just syntax correctness. It’s the layer your test pyramid was never built to be.

Left → right (dev to prod): every AI-generated PR clears a streaming governance lane (context resolved, policy aligned, risk composed, evidence written) before merge. The risky 5% gets a human; the rest moves at AI speed. Reliability stops depending on whether the right reviewer was awake.

Right ← left (prod back to dev): the moment something fails in production, Tomosu attributes it to the responsible AI change, surfaces the failure pattern, and feeds it back as a guardrail in the lane. The same class of incident doesn’t ship twice. Engineers stop firefighting; the system gets stronger every cycle. That closed loop is what turns AI-accelerated velocity into AI-accelerated reliability.

It compounds in three places at once. On reliability: repeat incidents from the same hallucinated patterns, MTTR creeping up, on-call burnout. On compliance: SOC 2, ISO, and internal AI-use policies become quarterly fire drills because no system of record explains why each AI change was allowed to merge. On trust: the next board, regulator, or enterprise customer asks “how do you govern AI-generated code in production?” and the honest answer is “we don’t.” The cost isn’t a single big incident; it’s the slow erosion of the velocity advantage AI was supposed to deliver.

The opposite. Tomosu is built so the boring 95% of AI-generated PRs (well-scoped, policy-aligned, low-risk) clear the lane in seconds with full evidence written automatically. Your reviewer attention goes only to the changes that actually need a human eye. In practice that means fewer review queue interrupts, faster merge throughput on routine work, and far fewer 2 a.m. pages from changes that should never have shipped. The governance layer isn’t a tax on engineers; it’s the thing that lets engineers trust AI-assisted velocity without owning the failure mode personally.

No. Tomosu sits above them. Your engineers keep their AI assistants. Your SRE team keeps Datadog, New Relic, or Dynatrace. Tomosu is the governance layer that unifies signal across all of them into one risk ledger.

Your choice. Most teams start advisory, see the risk ledger take shape over 30 days, and promote specific policies to blocking once they’ve built trust in the signal.

Read-only: Git PR/commit metadata, observability pointers (metrics/logs/traces), and ticketing metadata. Deploy metadata optional. Data handling, retention, and tenant isolation are finalized during onboarding security review.

First risk score within two weeks. Measurable MTTR and escalation reduction by day 60. Full board-ready trendline by day 90. Outcomes are baseline-dependent, not guaranteed.

CTO or VP Engineering is the economic buyer. The strongest conversations include a Head of Support or Head of SRE as co-champion, since they feel the interrupt tax most directly.

Claude Code is developer-initiated and dev-time—it reads files you hand it. Tomosu runs on a cron on your production server: it reads live logs, extracts class names from stack traces, fetches the actual source files from GitHub that caused the error, and creates structured tickets automatically while your team sleeps. The trigger is your production runtime, not a developer’s question. They operate in entirely different positions in the stack.

The LLM call is the easy part. What takes 12–18 months: a 25-rule scoring matrix with empirically calibrated critical caps, SHA-256 file hashing to skip unchanged code, token-count batching to avoid context window overflows, error fingerprinting to prevent hundreds of duplicate tickets from one root cause, semantic deduplication via vector embeddings, and per-user spending limits. The weights in the scoring matrix only become credible after you’ve correlated them against real production incidents—data you don’t have until after your first outage.

Your APM tells you something is broken. Tomosu tells you which change broke it, which governance rule it violated, and here is the before/after fix. Specifically: a production error surfaces → Tomosu extracts the failing class → fetches that source file from Git → runs the scoring matrix → creates a ticket with root cause, telemetry signal, and code diff attached. Existing observability watches symptoms. Tomosu attributes causes and closes the loop back to the code that shipped them.

Issue lists don’t move engineering organizations. Trending numbers do. Tomosu gives every file two scores: a pre-analysis score (what the code is right now) and a confidence score (projected if fixes are applied, hard-capped at 85 so the AI never oversells itself). Critical caps make the stakes concrete: one missing external timeout puts a Grade C ceiling on the codebase regardless of everything else; one hardcoded secret is Grade F. These are the numbers that go into QBRs and board decks. Issue lists don’t.

Every prior wave of software delivery removed a bottleneck and left a new layer behind: cloud left orchestration, CI/CD left pipelines, observability left telemetry. AI removed the last bottleneck, writing the code, and left behind the one thing no existing category owns: deciding whether what was produced is fit for production. Test frameworks judge correctness. APMs report what already broke. Code assistants generate without accountability for risk. None of them sit between AI-accelerated change and production with the authority to decide. Tomosu is the first platform built specifically to be that layer: one score, one governance loop, one system of record spanning development, pre-merge and runtime. If the category is new, it is because the problem is new.

Firefighting time is made of four things: incidents that should never have shipped, triage spent working out which change caused it, repeat incidents of a class you already fixed once, and senior engineers pulled into L1 and L2 work that never needed them.

Tomosu attacks all four. Risk is scored and hardened before merge, so a category of incident never reaches production. When something does break, the responsible change is attributed immediately instead of being hunted across a dozen dashboards. Routine L1 and L2 escalations resolve automatically rather than paging a name. And every escalation is turned into a guardrail, so the same failure pattern cannot ship twice. The reclaimed hours are not a soft benefit: they are the difference between a roadmap that ships and a roadmap that slips.

Reliability knowledge usually lives in two bad places: a wiki nobody updates, and the heads of three senior engineers who are asleep, on holiday, or leaving. Both decay, and neither is available at 3am.

Tomosu runs as a multi-tier agentic system that observes, prevents, resolves, escalates and learns continuously, not on business hours. Every resolved incident, every escalation and every accepted fix becomes governed knowledge that is versioned, attributed and fed back as a guardrail on the next change. Coverage stops depending on who is on call, and the system is strongest precisely when your team is least available. Knowledge stops being tribal and starts compounding.

There are two doors. The Free Edition lets an engineer scan a repository and see a real PRI in minutes, with no procurement conversation. The guided pilot is for teams who want the full loop.

The pilot runs on a 90-day shape with milestones rather than vibes: read-only connection and a baseline PRI in the first two weeks, then the IDE plugin and an advisory merge gate on your first repositories, then escalation routing with context attached, then the closed loop where incidents feed back as guardrails and you have a board-ready PRI trendline. Integration is read-only against the tools you already run, so it is live in days and measurable in weeks. Nothing is ripped out, and the gate stays advisory until you choose to enforce it.

No. Production does not care who wrote the code, and neither does the PRI. A missing timeout, an unbounded query, a swallowed exception or an untraced dependency is the same production risk whether a senior engineer typed it in 2019 or an agent generated it this morning. Human-built or AI-assisted, the same governance loop applies. What AI changed is the rate: risk that used to accumulate over years now accumulates over sprints, which is why the layer became urgent. Most teams find their first baseline scan says as much about the legacy estate as it does about anything generated last week.

Something specific and measurable, not a promise that nothing will ever break. What is guaranteed is that you will know: every application carries a PRI you can trend, every governance decision carries an evidence trail you can audit, and every escalation feeds back as a guardrail rather than evaporating. Reliability stops being an opinion and becomes a number that moves.

What it is not is a claim that a score reaches a particular value on a particular date. Outcomes depend on your codebase and on how much of the loop you switch on. Any vendor promising you zero incidents is selling you something else.

You should not trust it on day one, and the product does not ask you to. The gate starts advisory: Tomosu publishes verdicts alongside your existing process while you compare them against what your reviewers would have decided. You enforce when the evidence earns it, not because a vendor switched it on.

Three things make that comparison honest. Every verdict carries the reasoning and the evidence behind it, so it can be argued with rather than obeyed. Scores are calibrated to your organization instead of a generic industry baseline. And the projected confidence score is hard-capped at 85, so the system is structurally prevented from overselling its own fixes. Humans keep the override, always.

Dashboards get abandoned when they report and never decide. Tomosu sits in the path of a decision that has to happen anyway, whether a change merges, so it gets used by construction rather than by discipline.

The scale question is really a comparability question. Because every service is scored the same way, a PRI of 62 means the same thing in payments as it does in onboarding, which is what makes it possible to rank a portfolio, target the fragile 10% and defend where reliability investment goes. Engineers meet Tomosu in the IDE and the pull request; leaders meet the same underlying number as a trendline. Nobody is asked to open a new tab to do their job.