How does a “small startup” end up with a multi million line “legacy” codebase? Something not mathing
What is the point of working at a startup if you’re dealing with millions of lines of legacy code ? Isn’t the whole point of startups to create & innovate with a clean slate and modern tools?
I’ve never seen a startup with a multi million line legacy codebase.
>”Have you worked at many startups?”
In response to a question about a legacy codebase at a startup. That implies that they think whatever they are doing is common. And forking a multi million line codebase and heavily developing it isn’t common for startups.
OP might just be working at a small software company or for one that broke from a bigger one and is now "startup" like?
My observation has been:
- Initial greenfield work by an LLM is fast and very effective with minimal or no human oversight.
- Subsequent work ends up being over engineered and very verbose. Assumptions are made that aren't suited to the problem at hand (for example I find Fable is extremely regex happy where structured data would work much better from a readability perspective.)
- Once code bloats beyond a certain point due to unguided LLM usage, complexity is high enough that only LLMs can operate on the codebase with any economical amount of time.
- Rinse repeat and your code ends up unclear about any state that's not explicitly being tested and verified in QA loops
For some of our products this has been fine, for others it's been problematic. An understanding of your size and reliability requirements will help make the conversation more productive.
Why aren't you guiding your LLM usage? Is that what I said - to spam it and not guide anything? Or to have a careful workflow where you agree on design and maximize your human judgement/leverage?
> any state that's not explicitly being tested and verified in QA loops
As opposed to before, when engineers perfectly reasoned about code behavior from first principals and QA was unnecessary?
You didn't say anything positively or negatively regarding this so I made an assumption that you were using the LLM relatively unguided (e.g. a bit of oversight, not the kind of thing that heavy code reviews used to involve pre-agents.) Feel free to add clarity on your actual usage loop.
> As opposed to before, when engineers perfectly reasoned about code behavior from first principals and QA was unnecessary?
In my experience, most engineers are quite good at reasoning about code behavior for non-QAed code paths. Obviously things fall through the cracks. But I've been in the ground floor of plenty of Big Techs in their early stages before agents and, yes, a lot of initial development had spotty test coverage and yet most of the engineers had good mental models of what was happening. It used to be a very valuable skill to wrap your head around a torrid piece of code with few or no tests but was nonetheless a core piece of your application. Conversely, agentic development can bring cognitive debt [1].
===
This isn't a fight. We aren't sparring over what's right and wrong. I'm just curious how other people use agents in their work as someone who is also now in a startup that uses LLM agents heavily and has no limitations on spend.
I feel like this statement betrays your lack of advanced experience coding with LLMs.
OP's elaboration of the steps they are going through (planning, agreeing on plan, getting one LLM to draft execution plan, approving it, then executing with a separate LLM, then reviewing/testing) made it super obvious to me that they are guiding their LLMs quite considerably as part of their work.
Anyone making blanket statements about LLMs producing garbage is just telling on themselves about not having proper SDLC practices in place.
I find for my own work that I need to read the diff the LLM produces then offer feedback on the diff in its own loop before I am satisfied, and this is after all the unattended QA steps through Codex Computer or Claude MCPs happen. Then auto reviewers come in and then reviewers come in. Of course, at our stage, we rarely have this luxury and it's only reserved for the very core of our codebase.
This is still much less guidance than we used to do for code before agents became popular. Even at Series A companies, before agents, we used to socialize tech specs, get buy-in from multiple engineers, create test plans, etc etc.
> Anyone making blanket statements about LLMs producing garbage is just telling on themselves about not having proper SDLC practices in place.
> I feel like this statement betrays your lack of advanced experience coding with LLMs.
Are we in school debate club? I don't know what's going on lol, I'm just curious how people are using LLMs! Is it just that irresistable to take a cheap shot at each other?
Yes, this is literally what that means.
Not that I know of but that's the conclusion I drew from your statement.
It's not a cheap shot unless you took it personally?
I suppose I could have said "the fact that OP's explanation of how they work did not lead you to conclude they were in fact guiding their LLM usage quite a bit tells me that perhaps you have not been working with LLMs in any advanced capacity".
For the SDLC comment I admit it was a broader statement (based on observing people generalizing that "LLMs produce bad outputs") and not specifically aimed at you, and I didn't make that clear, so my bad.
What exactly does "unguided" mean to you, then?
You might be surprised at how much benefit you get from the model council[0] pattern.
The common pattern I've seen is "build with Claude, review with GPT", or vice-versa.
It's been proven to be very effective.
0: https://www.google.com/search?q=model+council+pattern&udm=14
Design is too expensive, we do agile. QA too expensive, we fire all of them, and claim devops is the now, which allows us to fire the Ops team too, 100% ownership from deisng to ops on devs.
One person with an agent can replace all these teams. Yeah mo profits.
Easy! The output of 6 months ago Opus! Which seemed so wonderful at the time.
And if you're saying (based on your other comments) that a 6 month window is enough to create a legacy codebase...that indicates a serious lack of experience or understanding as to what a legacy codebase is, or why they exist.
Accept that other people may ascribe different meanings/interpretations to words than you, and that if your reading of their statement doesn't make sense to you, perhaps you are simply reading it wrong.
Trying to hold someone else to your definition of words suits what purpose exactly? Are you just trying to "win" ?
15 people is a pretty small startup, what if this is a 50-person startup?
Doesn't seem like that much to me, depending on what you're building and the size of your team.
15 devs putting out 400k LOC a year into the same codebase is not normal at all. I’ve never seen anything close to that kind of rate of growth across that number of people.
And 50 engineers is not even remotely close to a small startup. I have worked at a startup that had 50 engineers after a few years, but it was a multi billion dollar unicorn.
But who cares? The point is any codebase over a few years old with lots of customers and a big surface area has lots of code, much of it "legacy" from the standpoint of a guy in 2026.
This whole thread around loc is depressing. It speaks volumes of some peoples inexperience working on actual legacy code. Legacy code is not just age or size but that the technical foundation is dated in a fundamental way. A giant monolith running on a now defunk framework using a database only one guy in canada knows about.
Case and point in my day job. The org that owns XMM development does not know how to recover a physical bench that is bricked because everyone who knew how has left. So now they just use simulators…
Interestingly, AI figured out some of this pretty easily for me. But the org has the exact same AI as i do. At the same time another org is close to a year into a greenfield rewrite that has been developed via agentic swarms. Absolute trainwreck.
AI doesnt make bad engineers good. Anyone who says they are doing 4 eng work likely would be without ai too. Those that claim otherwise, are the bad engineers.
Yes of course there are words that have very clear meaning, and that's not the case here.
"startup" and "legacy" - used in the context of this discussion - are not words like "left" and "right" where everyone has a universal agreed-upon understanding of their meaning.