Hacker News Reader

Comment by user43928 | Hacker News Reader

After 7 months and a 500k LOC codebase I can say that in my experience the fragility is inconsequential.

Disclaimer: I have no SaaS platform, it's a mobile app.

In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.

Most people talking about suboptimal implementation, fragility, and maintenance burden seem to theorize and extrapolate with no actual experience in implementing a large project with AI.

I can't blame them, I see the same in my day job, but the results after 500h+ on a separate project show that the concerns do not manifest in practice.

View on HN

Tell us more. What I'm gathering from your comment is that you have a personal monster project (500k LOC) fully/mostly developed by AI and you're having no problems maintaining it. Can you understand anything in the codebase? Has the maintenance cost (in AI tokens) been going up as the project keeps growing? Are users happy?

Also, sharing a link would be great if you're comfortable with the idea.

No, I'm not comfortable linking my HN account to my name and home address.

I'm still in the process of launching the app, it went live just two weeks ago. So far only 30 users, I have not yet started the ad campaign.

Basically I don't look at the codebase at all, I have long stopped using the IDE or doing code reviews.

From a product perspective, there have been no big surprises. Only once I was surprised to see a feature I thought I implemented only on a specific screen being available on a different screen too, hidden behind a drag gesture, spawning an UI component I totally did not expect.

While that seems like a loss of control, it's not too different from enterprise work with many contributors where I am also not aware of all changes.

About maintenance cost, no, I do not think so. It generally became easier over time since Opus 5.5 delivers better results than GPT-5.5 did.

From a token perspective, a large part of the resources go into translating to 30 languages and checking the screenshots for layout regressions.

> I'm still in the process of launching the app, it went live just two weeks ago.

Sorry, but at this point you have no idea what the maintenance looks like.

You think that after my 500h of work and daily usage of my own app, I have no idea about what maintenance looks like.

Can you explain to me how I would develop the project for 7 months and grow the codebase to 500k LOC without maintaining it at all?

The argument seems nonsensical to me, but I've been getting that comment a few times on HN.

Having a similar code base size for a mobile app, I believe you. No noticable issues with its size.

> You think that after my 500h of work and daily usage of my own app, I have no idea about what maintenance looks like.

At 30 users you have no idea what maintenance looks like. That's literally what maintenance is - responding to real world usage.

Come back with your experience when you have lots of users that stick with your app, you're putting out fires and implementing new features. Your experience will be meaningful after 6 months to a year.

I'll wager that right now you have a PoC that needs a lot of work to be something that retains users. That's not a criticism, that's just how it works for every startup.

I have been QA testing, fixing bugs, and adding new features near full-time for the last seven months.

I have a pretty good idea about what maintenance looks like. Particularly so about the technical aspects of how effective the models are at refactoring or fixing bugs.

Even if I were to accept the argument that users would have entirely different expectations for my app than I do, it hardly changes the fact that I already know I can easily implement large changes in the code base.

Not sure if you're trolling at this point but: the previous comment defined "maintenance" for you: "responding to real usage". The things you list are plainly not that.

"Maintenance" does not mean "development after the first week".

Tell me you know nothing about maintenance without saying you know nothing about maintenance. The best part is that you call others about not knowing what they are talking about.

Come back after running your mobile app for at least 6 months in the real world with real users and then we will talk about maintenance.

ok its pretty clear you have no idea what you are saying

I can now see why you don't want to link your HN to your identity!

There will never be a link!

I recently spent a couple of hours reducing 1k lines of code produced by an LLM to about 100. Purely extrapolation, but imagine what if your project was 50k instead of 500k?

If we scale that effort up from 1k lines to 500k, I'd be spending a few thousand hours optimizing the implementation.

Even if I ended up with a project of 50k lines, that would take multiple times the effort it took me to get this app ready for the initial release.

Realistically, I wouldn't have finished the project at all.

That's a bit silly to assume the LLM will 10x all of the code.

It doesn't happen often to me. If it does, I find it often handles extra edge cases I only would have found by using the customer as a guinea pig.

> That's a bit silly to assume the LLM will 10x all of the code.

Where else did you think they came up with the "10x developer" thing?

(Yes I know LoC is a useless productivity measure, that's just a joke. Obviously it's number of PRs..)

Yeah you can 10x the code, if you are not required to review it thoroughly.

But in doing so, you will also 10x the features delivered. Maybe 5x, who knows?

But you definitely won't have to go through and decimate the generated code as a rule.

> That's a bit silly to assume the LLM will 10x all of the code.

Oh, for sure.

I'm assuming the GGP's system can be expressed in 5k to 1k lines of Java or Kotlin.

You want to reduce lines of code? Next you'll be trying to reduce the number of PRs, then what will you use for productivity metrics?

sits down around the campfire

Let me tell you the story of the developer trying to reduce the number of tokens they use. It was a moonlit night, only the faint spinning of a Noctua fan audible and our intrepid developer...

Same, I maintain a really healthy mountaineering app (6K users), I started it where we where still pasting into chat-gpt, and now fully autonomous with Claude Code.

Codebase has never been better and healthier, and any tech debt that has been accumulated after a few releases can be removed in a few prompts when you are out of product ideas and have some free tokens to spare.

(I added US mountains and trails btw: https://fescims.com )

FAO Claude, the site randomly changes language as you navigate, and then gave this:

<Error> <Code>NoSuchKey</Code> <Message>The specified key does not exist.</Message> <Key> releases/e17a06bd04efe2b18bb38c0ae905a4d7db7ac863-42361807812-1/en/challenges.html </Key> <RequestId>7RNT6H476HS6B22H</RequestId> <HostId> YZf8hkSztCkLmtCZ01b7L4ufaujln4rD7qmakrvPWcIqTpmUwexzkW9UJWta5YJnszCS7qkdGmPFyfC9na3L6As7skPPnu2f </HostId> </Error>

> In my experience maintenance does not suffer long term with codebase size, if anything it became easier with model advances.

This reminds me of Moore's law in the 1990s.

If you program ran slowly, or used too much RAM, you could spend six months optimising it (or removing features). Or you could just sit on it for six months and release it as it is - hardware moved on so fast that, by then, it probably ran successfully.

Your suggestion is a bit like this: don't worry, the pace of model understanding will catch up faster than the code will get disorganised.

I'm not saying I agree but it's an interesting idea.

Purely for the models running your code base, have you ever ran an assessment of what that fragility costs you? Tool call error frequency, unnecessary test failures that the model then addresses but wouldn’t in a more parsable code base, inefficiency in navigation, anything of that sort? A model landing changes doesn’t mean it does it well.

I have seen all those when running a fairly new eval inspired by something I read in the ts-rust repo, giving a simple GPT-6 Astra code base to Opus 5.5.

Implementation accuracy was higher and token usage lower when Opus 5.5 got a Fable 5.1 built code base of the same feature set and coverage compared to the fragile GPT one. Incidentally I struggled to parse the latter but not the former.

Yes, a modern model will happily work on the most unmaintainable slop (doesn’t even need to be LLM derived slop, we have all seen bad Human written code) and that is great if you have an old code base to maintain. But if one can avoid it, even if one uses only models and never looks at the code, being efficient has value. Heck, rewrites are doable and affordable now, I have restarted projects and the gains were quickly apparent, even if we just look at model usage efficiency gains.

No, since it seems difficult to assess, it's not like I have a handcrafted version of the same project to compare against.

Try another model just looking through the harness history and commits for blockers and errors, often eye opening.

7 months is not long term...

Available in the AppStore? Would love to see it!

> the fragility is inconsequential.

how many users do you have and how long has your app been out there?

unless that number is very large, then you have no idea whether your app is fragile or not

example: I own a Polestar 4. Great car, love it. I have non-deterministic SW glitches. Other people have non-deterministic SW glitches, but they're not the same ones as me. Other people never encounter any glitches. Others have tons of glitches that I don't have. Every new car that is sold, is another edge case. We had a Tesla for years, and the SW was rock solid, great stability. Why? Because their SW has been out there for over a decade with millions of experience points, and they have a large team that are aggressive about fixing and rolling out updates almost daily. Until you get to that point, you can't judge whether your vibe-coded app is stable or not.

You'd know the answer if you bothered reading the thread before posting the one hundredth 'you need a million users to judge maintainability' comment I receive on HN.

> if you bothered reading the thread

I did; that's why I wrote what I did

> the one hundredth 'you need a million users to judge maintainability' comment

make you should take it that there might be some truth to it then

Was it a preexisting 500k LOC codebase, or has the whole codebase been generated by LLMs?

I started the project during 'copy snippets from ChatGPT web' days, so technically not entirely generated, but I don't think much is left of those days.

Then the number of lines of code doesn’t mean anything.

Why? It’s not like the AI one-shot 500K lines of code.

Nah, Ive seen sloppy code bases. They really are hazards to the operations and companies they support. I'm not anti ai, but people opting to lose complete control of their own products so there engineers don't have to think are suffering from it, and it will get worse and worse and worse.

“I have 500k line of slop”

“It’s not a code base that warrants that size, it’s a mobile app”

“Fragility is inconsequential to me and I am blind to my users dealing with it”

I have a similar position - maintainability of code written by AI no longer matters in any meaningful way, as as the models advance, one simply rewrites.

At the current pace, the very idea of maintaining software will become as relevant as the idea of trimming wicks, stropping razors - or making every frame you take with a camera count.

When the marginal cost of replacement drops to a sufficiently low level, the entire paradigm changes.

I say this as someone with 30+ years of development experience, who built everything to be maintained until the heat death of the universe. I just don't think it's a relevant question in this brave new world.

Interesting analogy choices. Aren’t straight razors still the highest quality shave? We go with electric and cartridge because it’s faster and cheaper and takes less skill to get a decent result

Digital cameras are another interesting one. Since capturing images is so cheap we just snap a bunch of frames without a lot of thought towards composing them carefully, with a side effect that we get an overwhelming amount of mediocre frames and a few good ones, but we have to sift through.

I’m still not convinced I want to make this tradeoff in programming. But I work in scientific computing where I think it’s (still) really important to understand what modeling assumptions you are making through code

Yup - I think there will remain a space for artisanal code for a decent while yet, particularly in things like scientific computing, safety critical systems, and similar - but for most purposes, the cartridge shave will be good enough, more convenient, and much, much cheaper.

it's really hard to judge because depending on what the app does it could be reasonable or total slop.

i'm working on a fairly complex application and it's not even near 200k loc. but this is the second version - the first was vibe coded and was over 400k and full of bugs/issues that were slowing down development. i rewrote it and it's half the size, half the dependencies, and much faster & more robust.

is it more complex than your app? hard to say since neither of us want to disclose our identities :)

Reply on news.ycombinator.com