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.

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?

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 )

> 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.

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.

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

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.

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 :)