You asked an AI to build your app. It did. In record time. And now you’re staring at 35,000 lines of code you don’t understand, can’t test, and are terrified to touch.
Congratulations. You’ve invented a new kind of hell — one where you move fast and break things, except the things that break are inside your own head.
A developer recently posted about vibecoding an iOS app to 35k lines of code. They no longer knew what the codebase did. The AI happily generated function after function, file after file, layer after layer of abstraction that felt right in the moment and became incomprehensible in aggregate. The top comment was brutal in its simplicity: “The problem you are hitting there has a solution, and it is called Software Engineering.”
Ouch. But also — accurate.
Here’s the dirty secret nobody putting AI coding assistant ads in your feed wants to admit: AI doesn’t write good code. It writes plausible code. Code that looks correct, runs sometimes, and multiplies like bacteria in a petri dish. Every prompt you throw at it generates more lines, more files, more dependencies, more edge cases handled in ways you’ll never audit.
The promise was that AI would eliminate the boring parts of engineering. The reality is that AI IS the boring part of engineering — it just happens at a speed that makes the boring part impossible to keep up with.
Think about what happens when you write code yourself. You make decisions. You choose a data structure and remember why. You feel the weight of a function getting too long and refactor it. You have taste. The code is an artifact of your thinking, and when you return to it three months later, the thinking is still embedded in the structure.
AI-generated code has no memory. No intent. No taste. It has probability. And probability, stretched across 35,000 lines, produces something that looks like software but behaves like a stranger’s luggage — you keep finding things and you have no idea why they’re there.
The bottleneck has shifted. Writing code is no longer the problem. Understanding code is the problem. And understanding was always the actual job.
This is why the smartest teams using AI right now aren’t skipping engineering — they’re doing MORE of it. They plan refactor phases. They use one AI model to read and evaluate the entire codebase, generate documentation, and then hand that off to another model to clean up. They treat AI output like a junior developer’s first draft: enthusiastic, voluminous, and absolutely not ready for production without review.
The irony would be funny if it weren’t so expensive. We built AI to save us from the tedium of writing code, and now we spend our time writing code to manage the code the AI wrote. It’s like hiring a maid who rearranges your furniture every night — technically the house is clean, but you can’t find anything anymore.
And the cost isn’t just time. It’s cognitive overhead. Every line of AI-generated code you don’t fully understand is a small bet that nothing will go wrong in that exact spot. Stack 35,000 of those bets together and you’re not engineering anymore — you’re gambling. The house always wins, and the house is the codebase.
There’s also the literal warming, which the original post darkly acknowledged. All those GPU cycles generating code that will need to be regenerated, refactored, and eventually rewritten — we’re burning compute to produce complexity we’ll pay to undo. At least when humans wrote bad code, they learned from it. AI doesn’t learn from your codebase. It just generates more of it.
Every line of code is a liability. AI didn’t change that equation — it just made the numbers bigger and the interest rate higher.
So where does this leave us? If you’re using AI coding tools — and you probably are, because everyone is — you need to internalize one thing: the AI is not your engineer. It’s your extremely fast, extremely confident intern who has never met a problem that couldn’t be solved with three more helper functions and a new utility file.
You still need to architect. You still need to decide what gets built and why. You still need to know when to say “no, this is getting too complex” — because the AI never will. It will always give you more. More code, more files, more abstraction layers, more of everything except judgment.
The developers who thrive in the AI era won’t be the ones who prompt the best. They’ll be the ones who can look at 35,000 lines of generated code and know — instantly, instinctively — which 5,000 lines actually matter and which 30,000 are noise. That’s not a prompting skill. That’s an engineering skill. The oldest one there is.
AI didn’t kill software engineering. It made it impossible to fake.
FAQ
Q: Isn't AI-generated code good enough if the app works?
A: Working today isn't working tomorrow. AI-generated code that runs but can't be understood, tested, or maintained is a liability that compounds. You're not shipping software — you're shipping a maintenance crisis with a delay timer.
Q: So should I stop using AI coding tools?
A: No. Use them aggressively, but plan for a refactor phase. Treat AI output as a first draft. Have one model evaluate and document the codebase, then another clean it up. The tools are powerful — the workflow around them is what's broken.
Q: Isn't this just the same complaint people had about high-level languages?
A: No. High-level languages abstract complexity away cleanly. AI-generated code buries complexity under more complexity. A garbage collector hides memory management. AI generates 30,000 lines of memory management you now have to read.