How Do You Turn Recurring Customer Bug Patterns Into Devin Knowledge Entries?
Write a Devin Knowledge entry once a bug has actually recurred, not the first time someone reports it. The test isn't how annoying the report was or how long the fix took, it's whether you can write a one-sentence trigger a future report would echo, and whether the same explanation and the same fix hold up the second and third time. If a bug has shown up more than once with the same root cause, it belongs in Knowledge. If it's shown up once, it's a ticket.
That test comes straight from how Devin actually uses Knowledge. Cognition's docs describe it as a memory system Devin checks against a trigger description and pulls in "when relevant, not all at once or all at the beginning." The guidance on what to write is equally direct: "We recommend including the aspects of your prompts or playbooks you find yourself repeating regularly." Repeating regularly is the whole bar. A bug you've only explained once hasn't cleared it yet.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in Notion
DevinRecurring and reusable are two different questions
A bug clearing the bar needs both. Recurring means the same underlying cause shows up more than once, worded differently by different people. Reusable means the three-line explanation you'd write today will still be accurate the fifth time it happens.
Plenty of bugs are recurring but not reusable. A flaky integration test that fails for a different reason each run technically "recurs," but there's no single trigger-and-fix pair to write down, each occurrence needs its own diagnosis. That's still a ticket, just a chronic one.
The bugs worth a Knowledge entry are the boring, mechanical ones. Think a rate limit that resets on UTC boundaries and gets read as a bug every time someone's in a different timezone, a webhook retry that silently drops after the third attempt, or a config flag that gets reset on redeploy. Same cause, same fix, different person hitting it each time.
Write the trigger before you write the fix
Devin's docs are specific about the two parts of an entry. There's a trigger description, which "can be a simple phrase or sentence" and is mandatory on every entry, and there's content, meant to be "a handful of sentences with relevant information." The trigger is the harder of the two to get right, because it only works if it resembles what someone would actually type or paste when they hit the bug, not the internal name your team uses for it.
If you can't compress the recurring complaint into a phrase a future report would resemble, that's usually a sign the pattern isn't solid yet, not a sign you need a longer entry. Cognition's own guidance backs this up on the other side too: "Split up your Knowledge into smaller ones where possible. Devin is capable of accessing multiple Knowledge 'items' at once." Bundling three unrelated bugs into one general "known issues" entry just means Devin reads the whole thing every time any part of it matches, which is exactly what the docs warn against: "Devin will read the entire Knowledge contents, so keep it all relevant and up-to-date." Stale or unrelated lines in an entry don't sit quietly, they get read alongside the part that's still true.
What Corvid Labs wrote down instead of re-explaining it a fourth time
Corvid Labs builds shift-scheduling software for hospital nursing teams. Dana Okafor, an engineer on the platform team, noticed the same page landing in the on-call channel for the third time in a month:
Dana Okafor, in #eng-support: This is the third time this month someone's paged about a shift that's supposedly still open. Same story every time: a charge nurse marks it covered after arranging a swap, and by the next morning the schedule shows it unfilled again like the swap never happened, so the original nurse gets paged. The fix is the same two-line change every time. We keep rebuilding it because nobody remembers we already shipped it twice.
The root cause was that the covered flag lived on the day's schedule snapshot, not on the shift record, so the nightly rebalance job dropped it. Dana wrote the Knowledge entry with the trigger shift reopens as unfilled after the overnight rebalance. The content laid out that the covered flag is snapshot-scoped and gets cleared on rebalance, that a matching report should be checked against a recent rebalance run before anyone assumes it's new, and that the fix is having the rebalance job preserve coveredFlag instead of resetting it.
A few weeks later a different report came in worded completely differently, "the app un-assigned my covered shift overnight," from a different charge nurse, triaged by a different engineer. The trigger matched anyway, because Dana had written it around what the bug does, not around the internal name for it. The engineer confirmed the same rebalance path, applied the known fix, and closed the ticket in under fifteen minutes instead of re-running the investigation from scratch.
Where noticing "wait, haven't we seen this?" stops scaling
The Corvid Labs example worked because Dana happened to remember the two earlier reports clearly enough to recognize the third, and all three happened to land as pages in the same on-call channel, which made the pattern visible to one person. That's the part that breaks down as volume or channel count grows. A recompute-style bug like this one is just as likely to surface as a Slack complaint in a different team's channel, a support ticket from a customer who never touches the on-call channel, and a GitHub issue from a partner integrating against the scheduling API, three different tools, three different people, no single inbox where the pattern is visible. Catching that it's the same bug across tools depends entirely on one person happening to read all three and connecting them, and that stops being reliable well before a team hits a few dozen reports a month.
The failure mode isn't that nobody notices eventually, it's that Knowledge entries only get written for the bugs someone happened to catch recurring. The ones that recur quietly across channels that different people watch never clear the bar, and every recurrence gets fully re-diagnosed instead of matched to an entry that doesn't exist yet.
That's the point where the DIY version of this, a person's memory plus a search through old tickets, stops being enough. What's needed instead is something that counts recurrences across channels automatically, so the decision to write a Knowledge entry rests on an actual number instead of a hunch.
Where a counted topic becomes the shortlist
That's the category Modem works in. Modem clusters duplicate reports out of Slack, support tickets, and GitHub or GitLab issues into a single topic, whatever wording each person used, and keeps a running count and the quotes attached. A topic sitting at "6 reports, 3 different wordings, one root cause" is a strong Knowledge-entry candidate; a topic at one report isn't yet, and the count makes that an objective call instead of a memory test.
Modem doesn't write the entry for you, Knowledge isn't something it publishes into. What it gives you is the shortlist and the material. The clustered quotes are usually most of the "content" section already written, and the trigger just needs pulling out of the common phrasing across them. It's also where the connection to Devin closes the loop. Modem's Devin integration hands off the fix itself, enriching the task brief with the same reproduction details the topic accumulated, so the bug that just earned a Knowledge entry also arrives at Devin with full context the next time it's assigned as work rather than looked up as memory. Modem is what we sell, which is a reason to read that last part skeptically rather than a reason to distrust the counting itself. A team logging a handful of cross-channel reports a month can keep running the recurrence test by memory just fine; the math starts favoring an automatic count once that volume climbs into the dozens.
For the surrounding steps, what context Devin actually needs to fix a customer-reported bug covers the brief itself, and the six ways teams hand customer-reported bugs to Devin covers the handoff paths Knowledge entries end up feeding.
Prune as often as you write
A Knowledge base that only grows turns into the thing it was meant to prevent. Devin reads through the whole pile on every matching trigger, stale entries included, so an outdated line doesn't sit quietly next to a good one, it gets weighed the same. When a fix changes, edit the existing entry instead of adding a second one with an overlapping trigger; two entries competing to match the same report is worse than one slightly outdated one. And if a bug hasn't recurred in six months, it was probably a one-off that happened to repeat twice, not a pattern, and it's fine to retire.
Start with the two or three bugs your team has already re-diagnosed more than once this quarter. Those are already proven recurring, the trigger practically writes itself from how the last report was worded, and writing them up is the fastest way to see whether the next recurrence actually gets caught.
