finds the real cause firstA stack trace points at the line that threw, but the bug is usually somewhere else. ML.ai reads the execution path, finds the actual root cause, and writes a fix you can review before it lands.
auth.test.ts fails: expected 200, received 401
Ran auth.test.ts1 failed
Traced auth.test.ts → middleware.ts → session.ts
The bug is in session.ts, not the middleware.
getSession() reads the store without awaiting it, so the middleware sees no session and answers 401 for a valid token.
Re-ran auth.test.ts
after the fix
login returns 200
passingauth suite
18 passedDescribe a task or ask a question
for debuggingDevelopers chasing a bug that keeps coming back, or an error that surfaces far from its cause.
Setup-order and state bugs that pass on one run and fail on the next.
Errors that surface far from the code that caused them.
Bugs that pass through middleware and state before they show up.
A stack trace tells you where the error surfaced, not where the bug lives. These four things are what ML.ai does differently from reading the trace yourself.
Received 401. The cause is two imports away.
What a single test file can see
A generic chat model answers from the snippet you pasted in, not the actual codebase. It cannot follow the import chain from the test into the auth middleware into the session store.
expect(res.status).toBe(200)if (!session) return res.status(401)const s = store.get(id)The test, the middleware, and the session store
The session store returns null on an expired token and the middleware treats null as missing. The token expired between setup and assertion, so the failure is a race in the test setup.
“Fixed the session lookup”
A description versus the real diff
Being told "we fixed the expiry check" is not the same as seeing the exact line that changed. Every edit here is a real diff you review before it lands.
@explore read middleware.ts and session.ts
What @explore will and won't guess at
@explore traces the failing path through the codebase before suggesting what to change, and finds the root cause in the session store returning null.
You read the trace, grep the error, add console.logs and re-run until the real cause turns up somewhere else.
Terminal
$console.log(token) # middleware.ts
$npm test → still 401Re-run
$console.log(session) # session.ts
$npm test → still 401Re-run
Forty minutes of logging before the timing issue shows
Paste the error or failing test. ML.ai reads the execution path, finds the race in the session store and writes the fix.
auth.test.ts fails: expected 200, received 401
Traced middleware.ts into session.ts
Root cause: the session store returns null
general
general · Read · Diagnose · Propose fix
Reads the function that failed and its callers, states what is actually wrong, then proposes a fix as a diff behind the same approval gate as any other edit.
@explore
@explore · Read · Search · Edit
Read-only search across the codebase, useful when the failing code touches an unfamiliar part of the system before a fix is attempted.
traces a bug to its causeMost debugging comes down to the chain of calls that led to the error and the state that was wrong three files upstream.
Explorer
general, the default agent, takes the whole task
auth.test.ts fails: expected 200, received 401
Explorer
auth.test.ts fails: expected 200, received 401
Ran auth.test.ts1 failed
Read middleware.ts, where the 401 is sent
Followed the session lookup into session.ts
Found the root cause
Describe a task or ask a question
Explorer
Describe a task or ask a question
Explorer
Allowed · auth.test.ts re-run: 200, passing
Describe a task or ask a question
Explorer
general, the default agent, takes the whole task
auth.test.ts fails: expected 200, received 401
Where debugging usually goes wrong, and how ML.ai closes each gap.
Where the 401 startsWith ML.ai
auth.test.tsgot 401
middleware.tssends the 401
session.tsreturns null, root cause
The stack trace points at the middleware returning 401, so you patch the middleware. The test passes until the session store hits the same race again next week.
How handles it
The agent traces the full execution path before writing anything. It finds the session store returning null and fixes the root cause instead of the symptom.
One read of the call chainWith ML.ai
middleware.tsread
session.tsread
tokenStore.jsread
You add logging to the middleware and re-run, then add logging to the session store and re-run again, and forty minutes go by before the timing issue shows up.
How handles it
The agent reads the files in one pass and identifies the timing issue without needing console.logs. What took forty minutes of re-running takes one read of the call chain.
Every caller of getSessionWith ML.ai
middleware.tsgets SessionNotFound
api/me.tsgets SessionNotFound
jobs/refresh.tsgets SessionNotFound
You catch the null in the middleware and return a fresh session. The test passes. But the session store still silently drops expired sessions, and any other caller hits the same issue.
How handles it
The agent sees the session store as the origin of the null and fixes the throw behavior there, so every caller gets an explicit error instead of a silent null.
The real edges of what general can do here, stated plainly instead of left for you to discover.
If the 401 only happens in production, paste the log line or the config value. It traces from what you give it.
Run the test until it fails once and paste that output. A real failure gives it something to trace, a description of one doesn’t.
Ran auth.test.ts, no prompt
Wants to edit session.ts
Running auth.test.ts doesn’t prompt, because test runners are trusted by name. The edit to session.ts still waits for your Allow.
Apply edits to 3 files?
One diff across the schema, the API route and the task card.
Give general a feature description and it reads the relevant files, plans the edit across every layer, and writes it as one reviewable diff.
Plan · session store migration
Open question: hard cutover or dual write
architect reads the code and returns the critical files, the trade-offs and a step-by-step plan before a single file changes.
Yes. The agent reads the test, the code under test, and the surrounding state to find race conditions or timing issues. It cannot reproduce load-dependent flakiness, but it catches setup-order and state-management bugs.
It can only read what is in the workspace. Paste the relevant external detail (a config value, a log line) into the request and it factors that in.
No. It reads the code, follows the execution path, and runs the failing test to see the real error (test runners run without a prompt). It does not attach to a running process or set breakpoints, and any edit it proposes still waits for your approval.
If the services are in the workspace, it follows the call chain across them the same way it follows one through files. For any part of the path outside the repo, paste the log line or config value and it factors that in.
today, or talk to us about what is nextInstall the editor agent on your own machine, or book a call to talk through your team’s workloads and see where ML.ai fits.
