One preprint links monolithic repos to prompt injection risk

A preprint posted to arXiv argues that highly modular codebases are significantly harder to hijack through indirect prompt injection than monolithic ones. That's a new argument for something a lot of engineers already do out of habit: keeping files small.

The stakes here aren't abstract. If an attacker can plant instructions in a file your coding agent reads, a smaller blast radius matters. A workspace split into narrow, single-purpose files limits how much context an injected instruction can touch before a human notices something's off. A single sprawling file gives an injected prompt more surface to work with and more places to hide.

I'd treat this as a tiebreaker, not a mandate. One preprint isn't enough to justify scheduling a refactor sprint. If you're already on the fence about splitting a module, this is a reason to lean toward doing it. If your repo is fine as-is, this alone isn't a reason to touch it.

The more actionable part is a habit I've watched agents fall into by default: concatenating new helpers into whatever file already exists, because that minimizes the agent's own edit count. It's the path of least resistance for the tool, not for the codebase. Left unchecked, it's how you end up with the 4,000-line file the paper is implicitly warning about.

What to watch

The open question is whether this result holds up outside the paper's own setup, and whether "modular" ends up meaning something more specific than "small files." Until then, the practical move isn't a rewrite. It's noticing when an agent is about to bolt another function onto an already-overloaded file and telling it to make a new one instead.