What Context Does Devin Actually Need to Fix a Customer-Reported Bug?
Beyond a ticket title, Devin needs four specific things before it can turn a customer bug report into a working fix. It needs the exact scope of what's broken, a reference to existing code that handles the same case correctly, links to any docs the fix depends on, and a measurable definition of done. That's not a guess about what a coding agent probably wants. It's what Cognition's own instructing guide tells you to put in the task.
The gap is that a customer bug report almost never arrives in that shape. It arrives as "the export button doesn't work anymore" in a support ticket, or a Slack message from someone on the customer success team relaying what a user said on a call. Someone has to turn that into the four things above before Devin can act on it, and that translation step is where most handoffs go wrong.
“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
DevinThe four inputs, straight from Devin's docs
Cognition's guide to good vs. bad instructions makes the difference concrete with a paired example. The bad version is "Add a user stats endpoint." The good version is "Create a new endpoint /users/stats that returns a JSON object with user count and average signup age. Use our existing users table in PostgreSQL." Same request, and only one of them is executable.
Reading across both docs, the four inputs break down as:
- Domain and scope. Which repo, which service, which file. A bug report that says "the export is broken" could point at the frontend, the export worker, or the PDF library, and Devin will guess if you don't tell it.
- A pattern to follow. Point at code that already solves an adjacent version of the problem correctly, as in Cognition's own example, "Use
authTemplate.rsas a reference to maintain consistency in error handling." - Links to the docs it needs. If the fix touches a library's timezone handling or an API's request format, link the actual page. Devin reads it; you don't have to paraphrase it into the ticket.
- A measurable success criterion. Not "make sure it works," but something like the docs' own phrasing, "confirm the endpoint returns status 200 and includes all required fields." For a bug fix, that's usually a specific input that should now produce a specific output, plus the test that checks it.
None of these four live in a typical support ticket. They live in the codebase, in a docs site, and in whoever's head remembers that this exact class of bug got fixed correctly six months ago somewhere else in the app. Assembling them is a separate job from noticing the bug.
The assembly step is the part that doesn't scale
Scope is the input that most often arrives thin. A usable version names the directory and the specific files, points at a pattern already used elsewhere in the repo that handles the same case correctly, and links the reference the fix should rely on, for example Intl.DateTimeFormat's timeZone option when the bug is a timezone conversion.
Turning a one-line bug report into those four inputs is its own block of work every time: checking the support tool for duplicates, opening the repo, finding the comparable pattern, and writing the ticket. At a low enough volume, that's fine. It stops being fine on two axes at once.
The first is volume. Once bug reports arrive daily across support tickets, Slack, and the occasional sales call, that per-bug assembly turns into a standing block of someone's day, and it's exactly the kind of task that gets skipped when things are busy, which is when the thin tickets start reaching Devin again.
The second is memory. You only catch the prior tickets you happen to search for, in the tool you happen to search in. That search works only if someone remembers to run it, and it only finds duplicates filed in the same place. A bug mentioned on a sales call or in a different support channel doesn't show up in that search at all, so an "isolated report" framing in the ticket can be wrong without anyone noticing.
Devin's API supports feeding it accumulated context directly. A session created via POST /v3/organizations/{org_id}/sessions accepts knowledge_ids, letting a task pull in previously stored organizational knowledge instead of restating it every time. That's useful once the context exists. It doesn't solve where the context comes from in the first place, which is still the manual search for duplicates and patterns above.
What an aggregation layer replaces
An aggregation layer stops being optional once volume and memory are both working against you. Modem reads Slack, support tickets, and sales call notes as they come in, clusters reports of the same bug into one topic with every account that hit it attached (and each company's plan one question away), and keeps the thread of prior related reports so the fact that other accounts described the same symptom is something the system already knows, not something a human has to go find.
When a topic is ready to hand off, the Modem agent can compose the brief from that context graph and, when you ask, delegate it to Devin directly. The scope still comes from someone pointing at the right files, the same craft the manual version depends on. What Modem removes is the search itself. The affected accounts, the repro wording from each report, and the prior duplicate check are already assembled before the ticket gets written, so the assembly step per bug doesn't scale linearly with how many bugs show up. Modem is our product. Read that paragraph with this in mind, and see our guide to the best ways to hand customer-reported bugs to Devin for a more direct, side-by-side comparison.
The four inputs from Devin's own docs don't change either way. What changes is whether someone reconstructs them from scratch on every bug, or whether the reconstruction already happened by the time the ticket needs writing. The fuller pipeline, from first mention to merged PR, including the two gates worth keeping human, is covered in how to have your coding agent fix user-reported bugs.
Four questions before the next ticket goes out
Before the next customer bug goes to Devin, run through the assembly by hand:
- Which file or service actually owns this?
- What existing code already handles a similar case correctly?
- What doc does the fix depend on, and is it linked rather than paraphrased?
- What does "fixed" look like, stated so Devin can check it itself?
That's the whole difference between a ticket Devin has to guess at and one it can execute. It costs the same manual assembly either way, until something replaces the search.