alt Hacker NewsI think vibe-coding is cool, but it runs into limits pretty fast (at least right now).
It kinda falls apart once you get past a few thousand lines of code... and real systems aren't just big, they're actually messy...shit loads of components, services, edge cases, things breaking in weird ways. Getting all of that to work together reliably is a different game altogether.
And you still need solid software engineering fundamentals. Without understanding architecture, debugging, tradeoffs, and failure modes, it's hard to guide or even evaluate what's being generated.
Vibe-coding feels great for prototypes, hobby projects, or just messing around, or even some internal tools in a handful of cases. But for actual production systems, you still need real engineering behind it.
As of now, I'm 100% hesitant to pay for, or put my data on systems that are vibe-coded without the knowledge of what's been built and how it's been built.
Replies
It absolutely falls apart more often than not. And requires even better engineering practices than before, because people are just accepting the code changes without understanding the technical debt created by them. On this I agree. There are models that can be run locally, this morning I tested Gemma 4 running on 128 GB of RAM. It was very slow, like 20 minutes to refactor something instead of 20 seconds, but it seems to be as capable as the paid models that run on an expensive cloud subscription on one of these hated data centers. And no data is uploaded to them.
I suggest actually using Claude code and make a sample app using it. It absolutely can make apps even if you don’t know any fundamentals. I think it can work up to 20k LOC from my experience. You do need a human to give feedback but not someone who understands software principles.
There are all kinds of memory hacks, tools that index your code, etc.
The thing I have found that makes things work much better is, wait for it... Jira.
Everyone loves to hate on Jira, but it is a mature platform for managing large projects.
First, I use the Jira Rovo MCP (or cli, I don't wanna argue about that) to have Claude Code plan and document my architecture, features, etc. I then manually review and edit all of these items. Then, in a clean session, or many, have it implement, document decisions in comments etc. Everything works so much more reliably for large-ish projects like this.
When I first started doing this in my solo projects it was a major, "well, yeah, duh," moment. You wouldn't ask a human dev to magically have an entire project in their mind, why ask a coding agent to do that? This mental model has really helped me use the tools correctly.
edit: then there is context window management. I use Opus 4.6 1M all the time, but if I get much past 250k usage, that means I have done a poor job in starting new sessions. I never hit the auto-compact state. It is a universal truth that LLMs get dumb the more context you give them.
I think everyone should implement the context status bar config to keep an eye on usage:
https://code.claude.com/docs/en/statusline