Can Devin Tell When a Customer Bug Report Is a Duplicate of One It Already Fixed?
No. Devin's Jira and GitHub integrations open a session against whatever ticket or issue triggered it, and nothing in either integration checks that ticket against Devin's own history of tickets it has already closed. If a second customer reports the same underlying bug through a different channel, in a different ticket, Devin scopes and fixes it as a new problem, because to Devin it is a new problem. There is no shared memory across tickets unless a person builds one.
The trigger mechanics make this concrete. Devin's Jira integration fires on direct assignment, a playbook label like !plan or !implement, the generic devin label, or an @Devin mention, and each of those triggers acts on the ticket it fired from. The one piece of cross-session awareness the docs describe is scoped even narrower than it sounds: it's part of the @Devin-mention trigger specifically, not the other three. It only says "if a session already exists for the ticket, your message will be forwarded to the existing session," which is a check against the same ticket, not against every other ticket describing the same bug. Two tickets, two sessions, even if the diff Devin would write is identical both times.
What actually happens when the same bug arrives twice
Say a metering bug ships. Customer A hits it, files a Jira ticket, gets the devin label, and Devin opens a PR that patches the rounding error in the usage-aggregation job. Two weeks later, Customer B hits the same bug through a support inbox that funnels into a different Jira project. Nobody links ticket B to ticket A, because nothing does that linking automatically. Ticket B gets the devin label too. Devin scopes it fresh: reads the description, maybe re-derives the same root cause, and opens a second PR.
Best case, that PR is a near-duplicate of the first and a reviewer catches the redundancy before merge. Worse case, ticket A's fix touched a code path that's since moved, ticket B's session doesn't know that, and the two PRs diverge on how they patch what is, underneath, one bug. Either way, an engineer now has two PRs to reconcile instead of one, and the reconciliation work exists purely because nothing upstream of Devin noticed the tickets were the same.
Why this isn't a Devin gap, exactly
What's missing here isn't a bug in Devin, it's a boundary. Devin's Knowledge feature is the closest thing to institutional memory Devin has, and its own docs never mention conflict resolution between entries at all. Keeping entries current is a habit the docs recommend, not a system that enforces it. Knowledge helps Devin apply a standing convention consistently. It doesn't compare an incoming ticket against the full set of bugs Devin has already fixed and flag an overlap. Nothing in Devin's product surface is built to do that comparison, because Devin's job starts at the ticket, and by the time a ticket exists, the "is this new" decision has already been made by whoever filed it.
That's the actual shape of the gap. It sits upstream of Devin, at the point where a report becomes a ticket. Whatever catches the duplicate there, or doesn't, determines whether Devin ever sees two tickets for one bug.
Owen Delacroix's two rounding bugs
In March, a utility co-op in Idaho filed a Jira ticket against Solace Metering, a vendor that builds industrial usage sensors: "March invoice shows 40% higher usage than our own meter logs, must be a units bug." Someone on the support team labeled it devin. Devin scoped it, found a unit-conversion error in the nightly aggregation job that was double-counting partial-hour readings, and shipped a fix. Ticket closed.
Six weeks later, a different co-op in Oregon filed a ticket through the support portal: "Our usage numbers jumped for no reason starting this billing cycle, can you check the meter firmware?" Different wording, different suspected cause, same underlying bug: the March fix had been reverted during an unrelated rollback, and nobody had caught it. Owen, the engineer on call that week, read the Oregon ticket cold, didn't recognize it as a repeat, and labeled it devin. Devin scoped it as a firmware question, spent a session ruling out sensor calibration, and landed on the same rounding fix that had already shipped once. The PR was correct. It also cost a full session finding something that was already sitting in the closed ticket from March, because nothing surfaced that ticket to the person triaging Oregon's report.
Owen wrote it up in the incident retro afterward: "Two sessions, one bug, six weeks apart. If Oregon's ticket had referenced Idaho's ticket number anywhere in the description, we'd have caught it before Devin ever touched it."
The manual habit, and where it stops holding
The fix for Owen's team, as a habit rather than a tool, is a duplicate-check step before the label goes on: search Jira and GitHub for the symptom's key nouns, check the last few closed devin-labeled tickets in the same component, and only apply the label once that search comes back empty. This works. It's exactly the check Devin itself doesn't run, done by a human instead.
It stops working at the point where reports don't share vocabulary. Owen's two co-ops described one bug as "usage bug" and the other as "meter firmware," and a keyword search across tickets doesn't reliably catch that without someone already suspecting a link. It also stops scaling once reports arrive through more than one system: a support portal, a Jira project fed by a different team, a Slack Connect channel with a partner. Each new channel is another place the same bug can surface looking unrelated, and the manual search has to expand to cover all of them, every time, before every ticket gets labeled.
Catching the second ticket before Devin sees it
This is the point an aggregation layer earns a place ahead of the ticket, not inside Devin. Modem is our product, so weigh the specifics against your own backlog rather than the pitch. Modem reads Slack, support tools, and prior tickets as reports arrive and clusters mentions of the same underlying symptom into one topic, matching on what customers actually described rather than the exact words they used, before anything reaches Jira or GitHub. If Oregon's "usage jumped for no reason" had come in through a channel Modem was watching, it would have matched against the topic already carrying Idaho's March report, the original fix, and the fact that it had shipped, and the ticket that reached Devin would have said so instead of reading like a fresh firmware question.
Modem's Devin integration lets the Modem agent compose that ticket directly from the topic once it's ready, carrying the prior report and its resolution along with the new one, so Devin's scoping step starts from the full history instead of one customer's isolated wording. Below the volume where duplicate reports actually happen, Owen's search-before-you-label habit is the right amount of process, and there's no need to route it through anything else. Reach for a layer like this once the same bug has cost your team a second session more than once.
For the broader discipline of noticing repeat reports before they fragment across channels, see how to tell if multiple customers are hitting the same bug across different Slack channels. For the tooling landscape beyond a manual search habit, see the best tools to deduplicate bug reports.
Before the next ticket gets labeled
Devin will do exactly what a ticket tells it to, once per ticket, every time. If the same bug is going to show up more than once, the only question worth asking before the devin label goes on is whether anything upstream already knows that.
