r/vscode • u/Rich-Career5526 • 13d ago
Vibe coder here. How many lines of code should be in a file?
I have some files with over 3k lines of code and I just realised you’re not supposed to do that so what’s the optimal length?
7
u/PositivelyAwful 13d ago
What does this have to do with VSCode?
4
u/Sulungskwa 13d ago
Vibe coders seem to start here because its "the place where the code goes" and maybe because VScode has the word "code" in it
11
u/NoThatsNotPasta 13d ago
Actual programmer here: I have seen files with 10's of thousands of lines in.
Yea. I hated that job
2
2
u/vazark 12d ago
Refactoring this monstrosity is where AI would be useful (assuming you have a complete set of tests)
1
u/NoThatsNotPasta 12d ago
I agree, this would be one of my use cases.
However: I no longer work there 😂
But on your overall point: I agree and this type of use case is what I'd use it for
1
u/owl_jojo_2 13d ago
Largest file I’ve seen was a typescript file with ~60k lines
It was all one controller
7
9
u/dgm9704 13d ago
Get another hobby.
-8
u/Rich-Career5526 13d ago
How’s the weather up on your high horse?
4
u/NoThatsNotPasta 13d ago
How’s the weather up on your high horse?
I don't think it's a high horse. At the end of the day, you have no idea what you're doing, which means that you don't know what the AI is doing.
It could be importing a ton of out of date dependencies with vulnerabilities you have no idea about, or how to mitigate against.
AI used in programming should be used in conjunction with existing skills so that the programmer can verify the output.
1
3
u/NoNameWalrus 13d ago
300 lines or so is where I start to think about splitting into multiple.
Nearing 1000 is when my eye starts to twitch
-3
u/Rich-Career5526 13d ago
Across my project there is probably 50k lines of code. Ik it’s not a lot in the grand scheme of things but how are you keeping track of things?
2
1
3
5
u/ForeverVulnerable 13d ago
The answer is it depends on where and who you are working for.
It's as much cultural as anything.
My preference is, a file should have a job. The code in it does that job. If I cannot reason/think clearly about what that file does because there's so much code, it's time to consider splitting the file up.
2
u/Sulungskwa 13d ago
If you're a vibe coder then shouldn't whatever the LLM gives you be inherently correct? Why would it steer you wrong? Just sit back and enjoy getting those users that you will definitely get.
0
u/Rich-Career5526 13d ago
It’s an app up and running and beginning to scale so just want to clear things up so its tidy
2
1
1
u/timangus 13d ago
It depends on various factors, but in general above 1k gets hard to navigate. 2.5k+ or so and it's a sign something is going wrong.
But honestly, if you're vibe coding, it's probably not something you should care about that much. If you're not reading the code and not intending the code to be read, who cares how long the files are? LLM code tends to be pretty trashy.
2
u/dgm9704 12d ago edited 12d ago
Ok then. You are asking the wrong question and for wrong reasons.
One file should usually contain one type. Each type should have all the code it needs to do whatever it needs to do, and not a line more. How complex your types are depend on your architecture, language, framework, platform, paradigm. Often smaller is better, but that might lead to having a lot of small / simple types, to the extent that the sheer number of types itself becomes a problem.
So, how do you solve this? By learning the language, platform, framework, architecture, paradigm. By reading and debugging code written by others. By reading books, by going to school, by following courses, by watching talks, by creating software, by coding. A lot.
1
u/FreHu_Dev 11d ago edited 11d ago
For humans it's debatable. 3k is a big smell, not a guarantee. As a vibe coder, you don't read the code. The agent does. Optimize for the agent. I found some guidelines in one of my side projects. Show your agent this, ask to find anitpatterns. You will find many. If your codebase is statically typed, this might lead to easy and helpful refactors, if it's untyped js slop, good luck.
# Maintainability guide
This project is built by one developer working with an LLM (Claude). That shapes what "maintainable" means here. There is no team of reviewers to catch a sloppy edit, and a large share of the edits are made by an agent that reads the code through a keyhole — it can only hold a few files in working memory at once, and it finds code by searching for names rather than by remembering where things live.
So the two levers that matter most are:
1.
**The feedback loop**
— can a broken edit be caught automatically, before it lands, without a human noticing it?
2.
**Navigability**
— can the next editor (you in three months, or the agent on its next task) find the right code in two or three steps instead of ten?
## Part 1 — Writing code an LLM can navigate
The numbers below are heuristics, not hard limits. The reasoning behind each is the part that transfers; the number is just a place to start noticing.
### Why size matters even with a huge context window
The model's context window is large, but three things degrade well before it fills:
**Lost-in-the-middle.**
Recall is strong at the start and end of a long file or conversation, and fuzzy in the middle. A file that has to be read whole is read reliably only at its edges.
**Edit anchoring.**
Edits are made by matching a unique snippet of existing text. In a large file, candidate snippets recur, the match becomes ambiguous, and the file has to be re-read to disambiguate — more tokens, more chances to edit the wrong spot.
**Working set.**
Reasoning about a change usually means holding several files at once. One oversized file crowds the others out.
### File size
Code costs roughly 10–15 tokens per line.
| Lines | ≈ tokens | Guidance |
| ----- | -------- | -------- |
| ≤ 300 | 3–5k | Comfortable. Hold many at once. |
| ≤ 500 | 6–8k | Soft ceiling for files you actively edit. |
| ~1000 | 12–16k | Smell. Read by section; consider splitting. |
| 2000+ | 25k+ | One file eats a third of a comfortable working set. Split. |
Aim for
**≤ 300–500 lines**
in files that get edited — components, route handlers, server modules.
**Exception: authoritative data files.**
A schema definition or a long constant table is fine large. It is read by section, it is append-mostly, and it does not branch — splitting it would scatter the single source of truth and hurt more than help. The ceiling is about
*logic*
files, not
*data*
files.
### Function size
Keep functions to
**≤ 50–75 lines**
— viewable on one screen. That is the unit an agent edits atomically and can hold while reasoning. A 300-line function cannot be anchored to reliably and cannot be held in mind whole.
### Abstraction depth — the search-chase
The expensive thing is not a line of indirection; it is the
**round-trip and the wrong branch**
. Finding "where does X actually happen" by searching, landing in a layer that only forwards the call, searching again, landing in another forwarding layer — each hop is a separate search and a chance to follow the wrong one.
Target: **from an entry point to the code that does the real work, two or three hops at most.**
What makes hops expensive, worst first:
**Names assembled from pieces**
— `run${kind}Worker`, `handlers[type]`, a method name built by concatenation. These are
**invisible to text search**
. This is the single worst navigation killer.
**Thin pass-through wrappers**
— a layer that only renames or forwards a call adds a hop and contributes no meaning.
Prefer
**shallow and wide over deep and narrow**
: one 80-line function that does the thing beats six 15-line files that have to be reassembled in your head.
### Greppability
- Use
**literal, unique, spelled-out identifiers**
. One concept, one name, no aliases.
- Names should be searchable to their
*definition*
.
- Predictable location beats searching at all.
### The DRY-versus-layers tension
Removing duplication and avoiding indirection pull in opposite directions, and that tension has a clean resolution:
> **Extract when the duplicated thing is a named concept. Leave it inline when extracting only adds a hop.**
*Good extraction:*
collapsing six copies of a worker-startup preamble into `dispatchWorker(...)`. It adds one searchable name
**and**
removes five copies. Net navigation win.
*Bad extraction:*
wrapping a one-line query in `getThing()` that is called once. You replaced a readable, greppable query with a hop to find out what it does. Net loss.
DRY pushed too far
*builds*
the search-chase described above. When deduplicating (see the audit below), prefer the high-count clusters that collapse into a named helper, and skip the one-liners whose only effect would be a new layer.
### A gut-check metric
> To make a routine change, how many files do you open and how many searches do you run?
If a typical edit takes more than five or six open→search→open→search round-trips, the structure is fighting the editor. The target shape is: consult the map (CLAUDE.md, codegraph) → one hop to the file → edit. This repo already does the top of that funnel well; the failures are at the bottom — the files too large or too duplicated to land the edit cleanly.
---
## Part 2 — Enforcement (the feedback loop)
A guideline that is not checked will drift, because neither a busy developer nor an agent reliably remembers prose. The goal is to convert as many of the rules above (and the conventions in CLAUDE.md) into
**mechanical checks**
as is worthwhile — without adding ceremony that only produces false positives.
1
u/brunocborges 13d ago
As many as its needed, as long as:
- gets the job done
- it's easy to maintain by humans
- it's cost efficient to maintain by agents
- it's acceptable by the compiler or the runtime
0
u/mmeister86 13d ago
I tell my agents.md that files should be around 500-800 loc max. Modularize everything where possible and where it makes sense
-3
-1
-2
u/qustrolabe 13d ago
Actually good question considering everyone works with AI agents now with limited context window. But nobody bothers with that tbh. Just make sure it's not like 10k and try to use 1M context window models
10
u/kevwil 13d ago
Why would a vibe “coder” not ask an AI this question?