Product · Bug handling
Cortex watches Jira around the clock. The moment a bug ticket lands, it reads the report, retrieves the right code, writes a fix, and opens a draft pull request — fully cited, ready for review. Engineers wake up to merge buttons, not triage queues.
NullPointerException in checkout flow
JIRA-1842
src/checkout/totals.ts · cart/state.ts
3 files
Guard null cart, add regression case
12 lines
Linked to JIRA-1842 · awaiting review
#4291
62%
of bug tickets closed without an engineer touching them
4 min
median time from ticket creation to draft PR
0
context switches for the engineer doing the review
How it works
Not a chatbot. Not an autocomplete. A full pipeline that runs on every bug, end to end — from the ticket your support team filed to a branch your team can merge.
A webhook fires the moment a ticket matching your filter is created. No polling, no delay, no missed bugs.
Stack traces, repro steps, screenshots, and linked logs all become signal. Cortex understands the bug before it touches the code.
Embeddings + symbol grep find the exact files involved — even across monorepos with millions of lines.
Cortex proposes a patch with a written rationale, citing the lines it changed and the lines it left alone.
A clean branch is committed with a descriptive message, ready for your CI to run before any human looks at it.
The PR includes the rationale, the diff, the cited files, and a link back to the Jira ticket.
The ticket is updated with the PR link and a status change. Support and product see progress in real time.
Engineers approve, request changes, or reject — exactly like a human PR. You stay in control of every merge.
Features
Null pointers in legacy code. Off-by-ones in reducers. The 4pm Friday regressions. Cortex takes the tickets engineers dread and makes them disappear.
Vector embeddings + symbol grep find the right files even in monorepos with millions of lines. No haystack, only needles.
Cortex parses tracebacks, file paths, and error messages directly from the ticket. The first file it opens is usually the right one.
Every PR explains what changed and why, with line-level citations. Your reviewers spend seconds, not minutes, on context.
Branch is pushed, draft PR is opened, Jira ticket is updated — like a junior engineer on call, every hour of every day.
PRs always opened as drafts. Hard token caps per run. Skip rules for low-confidence fixes. Cortex never pushes to main.
Status updates, PR links, and reviewer comments flow back into the ticket so support and product never have to ask 'where's that fix?'
Cortex grades its own fix. Low-confidence runs surface as suggestions for an engineer instead of opening a PR.
Bugs filed at 11pm don't wait until standup. Cortex runs the moment a ticket lands, so the queue never grows overnight.
See cost per bug run. Set monthly budgets per organization. No surprise bills, no opaque usage.
Anatomy of a Cortex PR
Every Cortex PR ships with the context your reviewers actually want — what changed, why, and what was deliberately left alone. Reviews drop from 20 minutes to 2.
Why
JIRA-1842 reports a NullPointerException when the cart state is hydrated before items load. The totals reducer indexes cart.items without a guard.
Change
Add a null/empty guard in totals.ts:42 and return zeros when no items exist. No behavior change for non-empty carts.
Why not
Considered moving the guard upstream into cart/state.ts but that would mask other consumers of an unhydrated cart. Localized fix preferred.
Connect your first repo in under five minutes. Free for the first 10 bugs.