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 an 11-year-old 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 vacation-day bug that DeepWiki never wrote a page for
A support ticket landed in the admin dashboard of Practica Health's scheduling product, the tool the company runs for outpatient clinics:
Clinic admin (filed via in-app support): A provider went on vacation last week and we blocked the dates on her calendar, but the system still booked three recurring patients into those days. Their appointments were created back in October, way before we added the block.
Ingrid Vashenko, a senior backend engineer on Practica's scheduling team, opened it as a GitHub issue and added the devin label. The codebase behind the ticket is a Java and PHP hybrid that's been in production for eleven years and sits well north of 200,000 lines, well past the point where Ingrid could scope it herself faster than Devin could. Devin's plan came back clean:
Devin (scoping comment): The vacation-block check in
ProviderAvailabilityServiceisn't applied when rendering existing recurring appointment instances. Fix: apply the block filter in the instance-rendering path as well as the booking path. Adding a test for a blocked date against a pre-existing series.
The fix matched what the ticket described, and the new test passed. It also didn't work, because the actual bug lived one layer down. Recurring series in Practica's system are expanded into individual appointment rows by a nightly batch job in a module called RecurrenceExpander, written years before ProviderAvailabilityService existed, and the two were never wired to check each other. DeepWiki's automatic wiki for the repo had a page for the availability service, which is touched constantly and easy to cluster, and no page at all for the recurrence expander, which changes maybe twice a year. Devin's session never saw it, patched the path it could see, and the batch job kept generating unblocked appointments the same night the fix shipped.
Ingrid's second pass added a .devin/wiki.json entry pointing at RecurrenceExpander directly, along with repo_notes explaining that it runs nightly and predates the availability service. The next session found the real interaction in about twenty minutes.
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. Ingrid could name RecurrenceExpander because she'd been debugging Practica's scheduling code for two years. A newer engineer routing the next ticket wouldn't know that module exists, let alone that it's the one place vacation logic and recurrence logic secretly touch. Curating the wiki file by hand scales with how much of the codebase one person can hold in their head, and on a 200,000-line monolith, that's a small fraction of it.
The second limit is repetition. If a second clinic reports the same vacation-day bug through a different channel three 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 clinic's vacation-day 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 that RecurrenceExpander exists, 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, Ingrid's manual wiki.json habit is still the only fix for the gap that actually broke her 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.
