66%
of developers cite “AI solutions that are almost right, but not quite” as a frustration. It is the biggest single one.
Stack Overflow Developer Survey, 2025 31,476 responses to this question
In development · Early access open
Change impact intelligence for the AI coding era
Small diff. Long reach.
Your AI writes the PR. Graphentra proves which screens, APIs and flows it can reach, with a traceable path for every one, so your team tests what matters and ships on evidence.
Changed
validateToken()
Proof path
tests: e2e/otp.spec.ts
validateToken then verifyOtp then /login/otp
OTP login calls the updated token validator. Check valid, invalid and expired codes.
- Reached, proven path
- 3
- Not traced
- 1
- Evidence
- a91f…c3
validateToken() reaches three surfaces with a proven path, and one path that cannot be traced. Illustrative example - What changed?
- What could it reach?
- What should we verify?
- What could we not trace?
[01] The change behind the change
Your ticket tells one story. Your code tells the rest.
A shared function changes. Another screen depends on it. An API consumer sits a few calls away. A change may reach further than its ticket says, and a regression plan built from the ticket inherits its blind spots.
- 01
Hidden dependencies
See the connections that reach beyond the feature you meant to change, including the ones nobody wrote down.
- 02
Unfocused regression
Replace “test everything, just in case” with a reasoned starting point your team can review and adjust.
- 03
Unclear release calls
Put the change, the checks and their evidence into one conversation instead of five.
AUTH-1287 In review
Update token validation to check the audience claim
- OTP login In ticket
- Password login Not in ticket
- Guardian access Not in ticket
- Dynamic permissions Unknown
- Declared in the ticket
- 1 flow
- Reachable in the code
- 3 flows
- Could not be traced
- 1 path
[02] How it works
Read. Trace. Prove. Say what to test.
Four steps from a diff to a checklist. Same diff, same answer, and every claim comes with its path.
-
The Git diff is mapped to the exact symbols that changed, using the TypeScript compiler and type checker. Not regex, not embeddings.
- Symbol-level, not file-level
- Compiler-grade parsing
- From changed functions to their callers Built · prototype
-
The dependency graph is walked backwards from each changed symbol to its callers, components, routes and API endpoints.
- Callers to routes and endpoints
- Every hop recorded
- From changed functions to their callers Built · prototype
- Surfaces inside the hashed evidence In development
-
Every affected surface carries its path, a confidence tier (proven, likely or unknown) and whether an existing test reaches it. What cannot be traced is listed as unknown, never silently dropped.
- A path for every claim
- Unknown stays visible
- A proof path for every affected surface In development
- Proven, likely and unknown confidence tiers In development
- Mapping to existing tests In development
-
A ranked, plain-English QA checklist. An LLM may narrate it. It never changes the evidence.
- Ranked for QA
- Narration is optional
- QA checklist written from the evidence Built · prototype
- A complete report that needs no LLM In development
9 import { jwt, SECRET, AUDIENCE } from './config'
10
11 export function validateToken(token: string) {
12 − return jwt.verify(token, SECRET)
12 + const claims = jwt.verify(token, SECRET)
13 + if (claims.aud !== AUDIENCE) throw new TokenError('audience')
14 + return claims
15 }
Read from the diff
- 1 function changed ·
validateToken() - Signature unchanged
- Behaviour changed · audience check added
- verifyOtp() OTP login /login/otp Direct
- passwordLogin() Password login /login Shared
- sessionMiddleware Guardian access /guardian/children Indirect
- loadPermissions() Not traced dynamic import Unknown
4 surfaces listed · 3 reached by a traced path · 1 not traced
- OTP login validateToken → verifyOtp → /login/otp Tracing… Proven
- Password login validateToken → passwordLogin → /login Tracing… Proven
- Guardian access validateToken → sessionMiddleware → /guardian/children Tracing… Proven
- Dynamic permissions validateToken → loadPermissions → dynamic import Tracing… Unknown
Test reach · Guardian access
No existing test reaches it, and the ticket does not mention it.
- 1 Guardian access First Guardian access: check access after login and after session expiry. No test reaches this surface, and the ticket does not mention it.
- 2 OTP login No. 2 OTP login: check valid, invalid and expired codes.
- 3 Password login No. 3 Password login: check that a valid login still creates a working session.
- 4 Dynamic permissions Manual Dynamic permissions: not traced. Check role-based access by hand.
An LLM may narrate this list. It never changes the evidence.
The limit of proof. Proof applies to the paths Graphentra reports. No path found is not proof of safety.
[03] The pull request check
What your team would see.
One check on the pull request: the surfaces a change can reach, the path to each, whether a test reaches them, and what could not be traced.
Graphentra Impact PR #482 evidence a91f…c3 (reproducible)
Change: validateToken() in auth/token.ts, body change (audience check added)
| Surface | Confidence | In ticket? | Test reaches it? |
|---|---|---|---|
| Proven | Yes | Yes | |
| Proof path proven
OTP login calls the updated token validator. Check valid, invalid and expired codes. Tests that reach it | |||
| Proven | No | Yes | |
| Proof path proven
Password login uses the same token validator. Check that a valid login still creates a working session. Tests that reach it | |||
| Proven | No | No manual check | |
| Proof path proven
Guardian access relies on session middleware that uses the updated validator. Check access after login and after session expiry. Tests that reach it None found. | |||
| Unknown | No | Not applicable: the path is not traced not traced | |
| Proof path unknown
Permissions are loaded with a dynamic import, so the path beyond it cannot be traced. It is reported as unknown, not assumed safe. Tests that reach it Cannot be answered: the path is not traced. | |||
Was this useful? Useful Noise Missed something
QA checklist, ranked
- Guardian access: check access after login and after session expiry. No test reaches this surface, and the ticket does not mention it.
- OTP login: check valid, invalid and expired codes.
- Password login: check that a valid login still creates a working session.
- Dynamic permissions: not traced. Check role-based access by hand.
[04] Why now
AI writes the code. Someone still has to know its reach.
More code is being written with AI. Here is what four independent studies found about what happens next, quoted as published.
89%
of organisations had experienced an AI-related production incident. Reviewing and validating AI-generated code was the top delivery bottleneck for developers and engineering leaders alike.
Qodo, State of AI Code Quality, 2026 500 US developers and 300 engineering leaders
Faster, less stable
Higher AI adoption correlates with higher throughput and higher delivery instability.
DORA, State of AI-assisted Software Development, 2025 Nearly 5,000 technology professionals
3.1% → 5.7%
Code reverted or substantially revised within two weeks of being written rose from 3.1% of changed lines in 2020 to 5.7% in 2024.
GitClear, AI Copilot Code Quality, 2025 211 million changed lines
Figures are from the sources named, in the year shown. They describe developers and organisations in general, not results from Graphentra.
[05] What makes it different
Six things we will not compromise on.
-
Proof, not guesses
Every reported surface comes with the chain of calls that reaches it. Open the path and check it yourself.
- In development
-
Speaks in surfaces
Screens, endpoints and flows: the language of the people who test. Not only file names.
- In development
-
Honest about the unknown
Dynamic dispatch, reflection and runtime-only wiring are reported as unknown. They are never silently dropped.
- In development
-
Works on day one
No test history, instrumentation or recorded sessions. It starts from the repository and the diff.
- Built · prototype
-
Runs in your own CI
The analysis runs in your own CI. LLM narration is optional.
- In development
- In development
-
Built for people and agents
A comment on the pull request for people. MCP tools for coding agents.
- In development
- In development
[06] Shared context
Built for everyone behind the release.
QA & test engineers
What did the ticket not tell me?
Graphentra gives you
A ranked checklist of the screens and flows a change can reach, with the reason attached to every item.
Developers & tech leads
What else did my change touch?
Graphentra gives you
The chain of calls from your change to every screen and endpoint it reaches, one path per claim.
Product & release teams
Are we confident enough to ship?
Graphentra gives you
A shared view of what was reached, what has a test, and what could not be traced.
AI coding agents
What will this edit reach?
Graphentra gives you
MCP tools an agent can call before and after an edit, so it checks its own change against the evidence.
Read the use case In development
[07] Built to earn trust
Same diff, same answer. No path found is not proof of safety.
01
Connections you can inspect
Every claim follows a traceable path through your code. An LLM may narrate the evidence in the language of your application. It never replaces the path itself.
02
Control stays with your team
The analysis runs in your own CI, and your team decides what to test. LLM narration is optional, and it never changes the evidence.
03
Unknown means unknown
Anything Graphentra cannot trace is listed as unknown and stays on the report. It is never quietly counted as safe.
[08] Where we are
Honest about what exists today.
Graphentra is pre-launch. A prototype of the analysis engine exists. The examples on this site illustrate the intended experience.
-
Now Built · prototype
Built in the prototype
- From changed functions to their callers
- Content-hashed evidence file
- Works on day one
- and 3 more
-
Next In development
In development for the MVP
- GitHub Action with a sticky PR comment and check
- Surfaces inside the hashed evidence
- A proof path for every affected surface
- and 8 more
-
Later Planned
Planned after the MVP
- Release-level regression scope
- Run only the affected tests, with a CI-minutes report
- Incident back-trace
- and 9 more
[09] A few good questions
The details that matter.
Something else on your mind? Ask it in the early-access form. We read every request.
01 Is Graphentra available today?
Not generally. Graphentra is in development and early access is open to a small number of teams. A prototype of the analysis engine exists. The GitHub check and the rest of the MVP are in development. The examples on this site illustrate the intended experience.
02 Do we need an existing test suite?
No. Graphentra starts from the repository and the diff, so it works before you have tests. If you do have tests, the planned PR check shows which of them reach each affected surface and flags surfaces that have none. If you have none, you still get the surfaces and a QA checklist.
03 Does “affected” mean “buggy”?
No. Affected means a change can reach a surface, so it may deserve a check. Tests and people decide whether the behaviour is correct. Graphentra says where to look, not what you will find.
04 Which stacks are supported?
The MVP targets TypeScript and TSX with React (including React Router), Next.js, Express and NestJS, in a single repository or a simple workspace, on GitHub. Support is in development and not yet certified. Not yet supported: other languages, Vue, Angular, GitLab, Bitbucket and cross-repository analysis.
05 Where does the analysis run?
In your own CI. The planned GitHub Action runs the analysis inside your workflow. The evidence includes excerpts of the changed lines, and we are writing a precise statement of exactly what leaves your CI. It is not published yet, and we will not summarise it until it is.
06 How is this different from AI code review?
AI code reviewers comment on code. Graphentra tells QA what to test. Its evidence is deterministic: the same diff gives the same answer, every reported surface has a proof path, and what it could not trace is listed as unknown. It is designed to work alongside AI reviewers and coding agents, and to feed them.
07 Is an LLM involved?
Optionally. The analysis itself is deterministic and uses no LLM. An LLM can narrate the evidence as a plain-English QA checklist, and it never changes the evidence. A complete report that needs no LLM is in development.
[10] Early access
Help shape Graphentra.
We’re building Graphentra with QA and engineering teams who want to understand which parts of their application a code change may affect. Tell us how your team plans regression testing today, and we’ll contact you about relevant early-access and pilot opportunities.
- See early product demonstrations
- Help shape the change-impact workflow
- Explore a pilot using realistic change scenarios
No spam. We’ll only contact you about Graphentra and relevant early-access opportunities.
Your team & workflow
All fields are required.
Request received
Thank you for your interest in Graphentra.
We’re currently speaking with QA and engineering teams about how they plan regression testing after code changes. We’ll review your submission and contact you about relevant early-access or pilot opportunities.