Why Does Devin Struggle Once a Codebase Gets Past ~15-20k Lines?
Cognition has never published a line-count cutoff where Devin stops working well, and no benchmark ties a specific number to failure. What Devin's own docs do say is narrower and more useful. DeepWiki, the feature that builds Devin's map of your codebase, runs on automatic clustering that "may hit built-in limits" on large repositories, and the docs call this "the classic large repository problem." That's not a marketing gap. It's an admission that on a big enough repo, the automatic pass through your code skips things, and Devin proceeds on whatever the pass did capture.
So the 15-20k figure users report isn't wrong exactly, it's just not Devin's number. It's roughly the point where most codebases stop fitting comfortably into an automatic summary and start needing someone to steer it by hand. For a bug-fix ticket routed to Devin on a large, mature codebase, that has a specific consequence. Devin scopes the ticket against whatever the indexing pass surfaced, not against the parts of the system that pass happened to skip, and there's no warning printed when the two diverge.
“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
DevinWhat Devin's docs actually admit about scale
Two pieces of Cognition's documentation matter here, and they say different things.
DeepWiki auto-generates architecture docs and diagrams for every connected repo. Repository indexing feeds one other feature too, Ask Devin, a codebase Q&A layer, but DeepWiki is the one that matters for scoping a ticket. By default, DeepWiki decides which parts of your repo are worth a page using cluster-based planning, and Cognition's own docs are direct about where that breaks: "large repositories may hit built-in limits," and the fix is a .devin/wiki.json file that lets a human "bypass the default cluster-based planning and create exactly the pages you specify," because otherwise "the automatic system would otherwise skip" parts of the codebase. Read plainly: past some size, Devin's map of your repo has holes, and nobody tells you where they are unless you go list every folder yourself.
Separately, Cognition's best practices guide recommends breaking work into slices that are "the smallest atomic unit of the project" and take "under 90 minutes of manual engineering work." That's good advice for throughput, but it's also a tell: the guidance assumes a task can be scoped and verified without much reference to the rest of the system. On a small app, most bugs are close to self-contained. On a long-lived monolith, the bug is frequently the interaction between two modules nobody scoped together, and no amount of slicing makes that interaction visible from inside one slice.
Independent testing lines up with this. Answer.AI ran Devin against 20 real engineering tasks and reported that its "most concerning failures came when working with existing codebases" rather than net-new ones, because those tasks "require understanding context and maintaining consistency with established patterns" that a fresh session has to reconstruct every time. Existing and large aren't the same axis, but on a codebase old enough to be 15-20k-plus lines, they travel together more often than not. None of this shows up as an error, though. Devin doesn't refuse the ticket or flag low confidence just because the repo is big; it scopes a plan and starts working, same as it would on a smaller one. What changes is the odds that the plan is quietly wrong in a way tests won't catch, because the part of the system it needed to know about wasn't in the summary it was scoped against.
The wiki file has two ceilings, not one
The .devin/wiki.json workaround is real and it works, but it has a limit. It only covers folders someone already knows to list. You can name the module where two subsystems quietly interact only if you have spent long enough in that part of the codebase to have found it. A newer engineer routing the next ticket wouldn't know the module exists, let alone that it's the one place two unrelated-looking pieces of logic touch. Curating the wiki file by hand scales with how much of the codebase one person can hold in their head, and on a monolith big enough for this to be a problem at all, that's a small fraction of it.
The second limit is repetition. If a second customer reports the same bug through a different channel weeks later, it lands as a fresh, unrelated-looking ticket, and Devin scopes it fresh too, with no memory that this exact interaction already burned a session once.
Modem is our product, and what it actually does here is narrower than fixing the indexing gap. Modem groups related conversations into topics as they arrive, regardless of which channel they came in on, so a Slack thread and a GitHub issue about the same symptom can already sit under one topic before a third report ever shows up. When a task goes to Devin through Modem, the Devin integration writes the brief itself, querying the relevant topics and folding "the feedback and reproduction details engineers usually chase by hand" into the task description before handing it off. If the second report lands under the same topic as the first, that brief carries the earlier report's context forward instead of starting from a blank GitHub issue.
That's a real fix for the repetition problem, not the tribal-knowledge one. It doesn't patch DeepWiki's clustering, tell Devin which unmapped module matters, or make the codebase smaller. A bug nobody has reported twice, in a module nobody has mapped, looks exactly the same to Devin whether Modem is in the loop or not. Below a couple of repeat reports a month, a hand-curated wiki.json is still the only fix for the gap that breaks the first attempt.
For the broader set of ways to get a bug in front of Devin at all, see handing customer-reported bugs to Devin. And if the ticket itself tends to arrive thin regardless of codebase size, what context Devin needs to fix a customer-reported bug covers the fields worth filling in before assignment.
Before the next ticket goes to a big, old repo
Ask one question before trusting a scoping comment on a mature codebase. Does the plan mention a module you know is involved, or only the one that's easiest to find? If Devin's plan reads clean but skips a system you know touches this bug, that's the large-repository gap showing up, not a reason to doubt the ticket.
Two concrete moves fix it before the next session starts. First, add the missing folder to .devin/wiki.json with a one-line repo_notes entry on why it matters, so the next indexing pass has it mapped. Second, if this is the second or third time the same symptom has come in through a different channel, check whether the tool that aggregates your support channels already grouped those reports together, so the ticket isn't scoped from scratch again.