Build1 distinct publisher3 min readPublished
A week of agent commits left 340 files in one root directory. The plugin answer parses those filenames into a tree at display time, so the disk never changes and git still sees the flat repo it was handed.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Start with the field that makes this safe to run. Each file node sets `resourceUri` to the real path on disk, so git diff, search and go-to-definition keep operating on the flat file [10]. Folder nodes carry `physicalPath = undefined`, and clicking a file opens that actual file with no symlink and no redirect [9]. There is no second filesystem to reconcile, which is what the author means when he sums it up: "The tree is a lie. The disk is the truth." [17]
The parse is one function [6]. `parsePath` pops the filename, splits the base on the configured separator, and re-glues the extension to the last segment, which is what stops `handler.ts` from becoming a `handler/` folder containing a file called `.ts` [6]. Filenames beginning with a dot short-circuit and come back untouched, so `.gitignore` and `.env` stay leaves [7]. Writes run the same transform backwards: right-click `auth/login/`, create `handler.ts`, and `constructFlatName` writes `auth_login_handler.ts` to disk [8].
For the number to transfer to your repo, the filenames have to already encode the hierarchy you want to see. `insert` walks the parsed segments and creates folder nodes as needed [16]; nothing normalizes segment order. An agent that emits `auth_login_session.ts` on Monday and, say, `session_auth_refresh.ts` on Thursday gives you two unrelated top-level folders. The default separator is `_` because that is the convention agents tend to use when writing flat files, per the author [14]. That default is a bet on the generator's habits, not something the plugin can enforce.
The documented failure is the `.` separator: `auth.login.handler.test.ts` splits into `auth/login/handler/test.ts`, promoting `.test` to a virtual folder, and the README recommends `_` or `-` when test filenames carry dots [15]. Any separator that also appears inside a naming convention will manufacture folders.
Then the cap. `buildTree` reads `logicalFolders.maxFiles`, default 10,000, and passes it to `vscode.workspace.findFiles` along with the exclude globs [11][12]. The 340-file directory that motivated the plugin is 3.4 percent of that ceiling [1], so for the flat agent playground the cap does nothing. The monorepo the author mentions froze the tree for two seconds at 50,000 files [13], and at the default cap that workspace surfaces at most a fifth of its files [2]. (A performance guard that also decides which files exist is doing two jobs.) Whether the truncation shows up in the UI is not covered in the post.
Moves aren't addressed either. Creation round-trips through `constructFlatName` [8], but dragging `auth/login/handler.ts` into `utils/` has to rewrite the on-disk filename and every import that names it. That is where a presentation layer stops being free, and it is the one place I would read the code before installing.
In my context the tradeoff is right. Roughly 300 lines of TypeScript, one parse function, no daemon, no migration commit [5][4]. If it turns out wrong, the rollback is uninstalling an extension, which is not true of any repo restructure I have argued for in review.
Ranked by verification strength, evidence, and original report placement.
After a week of letting an AI agent write code in the project, there were 340 files in one directory by Friday, all flat and all in the root.
Example filenames produced by the agent included auth_login_handler.ts, auth_login_session.ts, utils_helpers.ts and config_env.ts.
The author built Logical Folders, a VSCode and IntelliJ plugin that displays flat files as a virtual directory tree; the files do not move, nothing changes on disk, and the hierarchy is purely visual.
The plugin is described as about 300 lines of TypeScript, with no files moved and no symlinks.
parsePath splits the filename on a configured separator and keeps the extension attached to the last segment, so handler.ts does not become handler plus a fake .ts folder; auth_login_handler.ts with separator _ becomes ["auth", "login", "handler.ts"].
Dotfiles such as .gitignore and .env never split and are returned as-is.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 29, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Coverage at 80% was a price on human attention, and CI is the wrong place to charge it1 distinct publisher
build
Yadda 3's real artifact is not the code, it is the rules the agent could not rewrite1 distinct publisher
build
The Cap Was One Line of Scheduler Policy, Not the GPU1 distinct publisher
build
Agent reliability is a harness problem, not a prompt problem1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Code you can read, numbers you cannot check
The mechanism is genuinely inspectable: parsePath, buildTree and insert appear almost in full on dev.to, and the two load points — extension glued to the last segment, dotfiles short-circuited — are right there in the source. Everything numeric around that code is one person's recollection: 340 files, about 300 lines, two seconds of frozen tree on a 50k-file monorepo. Strong on how, thin on how much.
No user but the author
We cannot measure this. The write-up is the only artifact: no marketplace page, no install figure, no repository, no second developer saying they run it. A build note is a release announcement, not uptake, and treating publication day as adoption would be inventing a number the reporting does not contain.
Honest tool, oversized premise
The plugin's own claims are unusually well-behaved — it says it fakes a tree and leaves the disk alone, and the code shows exactly that, footgun documented rather than hidden. The overreach is one layer up: a single week with one unnamed agent becomes 'flat is the agent's native habitat', and the underscore default is justified by a convention no evidence is offered for. The engineering undersells itself; the diagnosis oversells.
The plugin's author explaining why the plugin should exist
This is a builder writing up his own tool on a platform where a good build note is the distribution channel. That does not make the code suspect — it is printed and checkable — but it does explain the shape of the awkward parts: the dot-separator trap arrives pre-framed as a documented trade-off, and the 10,000-file ceiling as a lesson learned, neither as an open limitation.
Half of it is verifiable, and all of it is one voice
We are confident about what the code does and unconfident about everything else. One publisher, one author, one week, zero corroboration: the counts, the timings and the claim about agent naming habits would each collapse or firm up the moment a second developer installed this and said so. Nobody has.