The "20k LOC weekend" stories are selection bias. You hear about the ones that worked, not the hundreds that hit walls at hour 15 when the AI-generated architecture couldn't accommodate a requirement the person hadn't anticipated.
What vibe coding genuinely accelerates: the iteration cycle between "I think I want X" and "seeing X running." That's valuable for discovery - you learn what you actually need faster by building and discarding.
What it doesn't change: the hard part of software was never typing. It's figuring out what the system should actually do when edge case Y meets constraint Z. That work is invisible in LOC metrics but determines whether your product works in production.
The people succeeding with vibe-coded SaaS likely have deep domain knowledge (they know WHAT to build) or are building in well-trodden territory (auth + CRUD + payments - patterns the models have seen millions of times).
For your 60k LOC complex business logic case: the question isn't "should I vibe code more?" but "what's my verification strategy?" If you can specify behavior clearly enough to write tests, you can probably let AI write the implementation. If you can't specify behavior precisely, that's the bottleneck - and no amount of faster code generation helps.
> Is “you don’t really understand the code, so it’ll hurt you later” still a meaningful criticism?
That is one of the strongest valid criticisms. Even if we ignore the possibility that the code that is vibed will be buggy and insecure, the real long-term problem is not having someone who understands the system. Almost every well maintained app has one or more people who grok the whole thing, who can hear a problem described and know right where the fix will be. They'll have a mental model of the whole system and can advise on architecture changes and other refactors. They can help teach the codebase to new folks. And most importantly, when an outage happens, they are the ones who quickly get you back up and running.
The lack of those people is why legacy systems are brittle and hard to maintain, so vibe coding a complex app puts you directly into that painful legacy maintenance mode.
One thought people are starting to throw out there is, "But the AI can just re-write the whole app every time we have a bug, so we never need to know things to that level." But those people have never worked with a customer base who gets ticked off when the same bugs re-appear on every release, or when a dozen small UI changes shows up on every release.
Vibe coding might give you some working code. But working code is an astoundingly low bar to set for actually building a product that pleases a customer base.
The current AI tools extremely good at telling you about how an existing system works. You don't need that one super knowledgeable person anymore.
With the right MCPs or additional context you can have the tools go read PRs or the last 10 tickets that impacted the system and even go out and read cloud configuration or log files to tell you about problems.
The concept of a "bus factor" is a relic of the past.
I feel the same way. AI coding skills seem to sit somewhere between intermediate and advanced. Unless you’re working in a space where you’ve thought very deeply and developed your own solutions—those “gotcha, you didn’t know this” kinds of problems—it doesn’t really feel like AI falls short.
So far, I’ve been reading through almost 100% of the code AI writes because of the traps and edge cases it can introduce. But now, it feels less like “AI code is full of pitfalls” and more like we need to focus on how to use AI properly.
Understanding the system and understanding the code is different. The “system” I just mentioned was “architected” by me just like I would have done in 2018 when I first started with AWS (but with 20 years of experience with coding).
I know what every module does (well Lambda in my case but I’m trying to be more generic), I know the abstractions, I know the business case, etc.
As a team lead/architect, even with other people writing code, I don’t know every line of code does. Claude code/Codex is just a junior/mid level developer to me
I've been using AI assistance on a ~30k LOC production codebase. My take: the "vibe coding" framing is misleading because it implies two modes - understand everything or understand nothing.
What actually happens is tiered understanding. I might vibe-code a utility function (don't care about implementation, just that it works), but I need to deeply understand data flow and business logic boundaries.
The 20k LOC weekend SaaS stories are real but missing context. Either the person has deep domain knowledge (knows WHAT to build, AI helps with HOW), or it's mostly boilerplate with thin business logic.
For complex systems, the testing point is key. AI generates code faster than you can verify behaviour. The bottleneck shifts from "writing code" to "specifying behaviour precisely enough that you know when it's right". That part isn't going away.
The people I see struggling aren't the ones who don't understand their code - it's the ones who don't understand their requirements.
For me, this isn’t just a curiosity—it’s a question of whether I need to completely change the way I work. Given the same conditions, I’d rather revisit the domain knowledge and get better at instructing AI than write everything by hand.
Outside the areas AI struggles with or really deep domain expertise, I feel like comparing productivity just doesn’t make sense anymore.
The people launching a SaaS in 40 hours are not concerned with the state of vibe coding, the quality of code, or the testing.
They care about the business. If you want to be like them, start by caring far less about the actual code or how it gets made. They will bring in people later who do, who will clean up the vibed mess
and they may or may not "listen", they are non-deterministic and have no formal means or requirements to adhere to anything you write. You know this because they violate your rules all the time in your own experience
Sure but in my experience LLMs behave much more consistently than humans with regards to quality. LLMs don't skip tests because they have to make a deadline for example.
And now we have LLMs that review LLM generated code so it's easy to verify quality standards.
At the same time, the LLM will, with some reliability, ignore the patterns or best practices in your code, or implement the same thing twice in different ways.
There are certain things they do, or don't do, that a human typically wouldn't, putting absolutes and anecdotes aside
I have been doing full stack web dev since 2003 and iOS apps since 2008. I do not write code anymore. At my day job I don't think I get more done over time because the code is rarely ever the bottleneck at that place. I do have more time to experiment and try things and say yes more to asks from colleagues.
Outside of work, I have just launched an iOS app I've wanted to build but has been outside my current skillset. I was able to "vibecode" this app in about 4-5 months.
The application has a tiny bit of moat because it involves a ML model (also vibecoded) trained on my own data set.
When I say vibecoded, I never reviewed or read code in detail. I really only ever saw snippets claude code shows here and there. I asked a lot of questions, much more than asking it to make changes. I only gave it high-level architectural guidance like "use MVVC", etc. I did a lot of manual testing and reading logs.
I won't name the app out of fear of shilling my vibeslop, or whatever, check my profile for the domain in an email address if you want to know more.
I think this is exactly the kind of example I wanted to see, so thank you for sharing.
I was thinking about it yesterday and realized that it might actually be worth trying to switch my current project entirely to “vibe development.” That said, I still worry a bit that AI might change the structure or expand the code when all I really want is to tweak a single line or a few expressions—but I’m sure there’s a way to handle that.
From my recent experience doing a project that involved setting up AWS infrastructure with CloudFormation - a VPC, subnets, docker based lambda s, SNS, SQS, etc - and the code on top of it, it did perfectly with code but took some going back and forth with infrastructure as code
The first thing I did was keep everything as decoupled as possible with so it would be simple for Codex and Claude Code (I use both) to reason over. I work the same way when setting up my own repos.
I treat Codex/Claude as junior developers and I keep my hands on the wheel
What's cool about this is that, every time new engineer joins this wave, there are more interesting ideas coming and shaping the "vibers" industry.
In my day to day job, now I am worried, it will be very difficult to get a new job, because I vibe so much that I almost forgot to write code from scratch.
Examples:
* Hey Claude, increase mem usage from 500Mb to 1500Mb in production - fire and forget
* Plan mode: What kind of custom metrics can we add to Xyz query processor? Edit mode: add only 3,4 and 9. Later we will discuss 8
* Any other small changes I have...
I primarily became a manager of bunch of AI agents running in parallel. If you interview me and ask me to write some concurrent code, there is a high probability that I will fail it without my AI babies
Vibe coding sits on an axis from smart autocomplete to one-shotting a $1B SaaS. Traditional software engineering was about holding the system in your head and translating it into syntax, fighting tooling and architecture decisions along the way. I think done properly it removes many of these friction points along the way to validating / implementing the idea.
Now it's easier to traverse a live plan and to quickly make micro pivots as you go.
I also think that architecture needs to change. Design patterns that will help to provide as much context to the LLM as possible to increase understanding.
What's your moat? What's your barrier to entry? What's your competitive advantage? If you can vibe code it in a weekend, someone else can vibe code a competing thing the next weekend. You're not going to build something that becomes a long-term business that way, because anybody else can take your business.
For a larger, more complex system, the real barrier is understanding what needs done well enough that you can build something that can do it. (In my opinion, that has always been the real barrier.)
The moat is most people aren't using LLMS, most people aren't building products, most people who might built it will never hear of your product, people will have other ideas competing for their attention, people are incompetent, and all the work that happens after the coding.
How many people do you think are out there vibe coding things?
Aren't companies built on execution? Or do we now build companies on tech stacks alone?
Before LLMS, how could a solo dev get a moat? Any company could hire a team to replicate your product. They might not care how much it costs them. "Hours spent coding" isn't the moat.
I've 'vibe coded' some internal tooling apps and it feels like i've joined a new company and been given a legacy codebase to work on, despite it being a week old.
I just assume all the posts that claim they've got a 20k line project in a single weekend is just marketing spam.
The real shift feels like moving from “writing code” to “making intent explicit.” If the domain model and invariants are clear, AI helps a lot with mechanical work. If they aren’t, no amount of vibe coding saves time. That makes productivity comparisons kind of meaningless.
Until recently, I thought that complex, multi-domain platforms were still relatively safe. But today, I’m seriously reconsidering and thinking about whether I should switch to a “vibe coding” approach.
I should also consider isolating the custom logic in the existing codebase as much as possible, converting it into general logic, and then testing the “vibe” approach directly.
All these stories about people using llms and hitting it big almost overnight make me feel dumb. I'm sure others feel the same. Probably FOMO.
My sense of using LLMs for coding is me feeling like a maintenance programmer even though the code is brand new and I'm debugging a LLM misunderstanding. Weird to be working on a 10k codebase that didn't exist a few hours ago and I'm now debugging it over the next 4 hours. Having it done around 16-20 work hours later is really strange.
> Weird to be working on a 10k codebase that didn't exist a few hours ago
This is the issue. A firehose of code production is not useful for a long time. But it's very useful in short bursts. Total volume of code was never the bottle neck or the goal.
Working with LLMs has all the same pitfalls of working with people. Programming effectively for the long term requires all the same rules whether you're using LLM's or not: build incrementally, test and refactor as you go (not at the "end"), keep scopes small, ship frequently, etc.
The "20k LOC weekend" stories are selection bias. You hear about the ones that worked, not the hundreds that hit walls at hour 15 when the AI-generated architecture couldn't accommodate a requirement the person hadn't anticipated.
What vibe coding genuinely accelerates: the iteration cycle between "I think I want X" and "seeing X running." That's valuable for discovery - you learn what you actually need faster by building and discarding.
What it doesn't change: the hard part of software was never typing. It's figuring out what the system should actually do when edge case Y meets constraint Z. That work is invisible in LOC metrics but determines whether your product works in production.
The people succeeding with vibe-coded SaaS likely have deep domain knowledge (they know WHAT to build) or are building in well-trodden territory (auth + CRUD + payments - patterns the models have seen millions of times).
For your 60k LOC complex business logic case: the question isn't "should I vibe code more?" but "what's my verification strategy?" If you can specify behavior clearly enough to write tests, you can probably let AI write the implementation. If you can't specify behavior precisely, that's the bottleneck - and no amount of faster code generation helps.
> Is “you don’t really understand the code, so it’ll hurt you later” still a meaningful criticism?
That is one of the strongest valid criticisms. Even if we ignore the possibility that the code that is vibed will be buggy and insecure, the real long-term problem is not having someone who understands the system. Almost every well maintained app has one or more people who grok the whole thing, who can hear a problem described and know right where the fix will be. They'll have a mental model of the whole system and can advise on architecture changes and other refactors. They can help teach the codebase to new folks. And most importantly, when an outage happens, they are the ones who quickly get you back up and running.
The lack of those people is why legacy systems are brittle and hard to maintain, so vibe coding a complex app puts you directly into that painful legacy maintenance mode.
One thought people are starting to throw out there is, "But the AI can just re-write the whole app every time we have a bug, so we never need to know things to that level." But those people have never worked with a customer base who gets ticked off when the same bugs re-appear on every release, or when a dozen small UI changes shows up on every release.
Vibe coding might give you some working code. But working code is an astoundingly low bar to set for actually building a product that pleases a customer base.
The current AI tools extremely good at telling you about how an existing system works. You don't need that one super knowledgeable person anymore.
With the right MCPs or additional context you can have the tools go read PRs or the last 10 tickets that impacted the system and even go out and read cloud configuration or log files to tell you about problems.
The concept of a "bus factor" is a relic of the past.
I feel the same way. AI coding skills seem to sit somewhere between intermediate and advanced. Unless you’re working in a space where you’ve thought very deeply and developed your own solutions—those “gotcha, you didn’t know this” kinds of problems—it doesn’t really feel like AI falls short.
So far, I’ve been reading through almost 100% of the code AI writes because of the traps and edge cases it can introduce. But now, it feels less like “AI code is full of pitfalls” and more like we need to focus on how to use AI properly.
Understanding the system and understanding the code is different. The “system” I just mentioned was “architected” by me just like I would have done in 2018 when I first started with AWS (but with 20 years of experience with coding).
I know what every module does (well Lambda in my case but I’m trying to be more generic), I know the abstractions, I know the business case, etc.
As a team lead/architect, even with other people writing code, I don’t know every line of code does. Claude code/Codex is just a junior/mid level developer to me
I've been using AI assistance on a ~30k LOC production codebase. My take: the "vibe coding" framing is misleading because it implies two modes - understand everything or understand nothing.
What actually happens is tiered understanding. I might vibe-code a utility function (don't care about implementation, just that it works), but I need to deeply understand data flow and business logic boundaries.
The 20k LOC weekend SaaS stories are real but missing context. Either the person has deep domain knowledge (knows WHAT to build, AI helps with HOW), or it's mostly boilerplate with thin business logic.
For complex systems, the testing point is key. AI generates code faster than you can verify behaviour. The bottleneck shifts from "writing code" to "specifying behaviour precisely enough that you know when it's right". That part isn't going away.
The people I see struggling aren't the ones who don't understand their code - it's the ones who don't understand their requirements.
For me, this isn’t just a curiosity—it’s a question of whether I need to completely change the way I work. Given the same conditions, I’d rather revisit the domain knowledge and get better at instructing AI than write everything by hand. Outside the areas AI struggles with or really deep domain expertise, I feel like comparing productivity just doesn’t make sense anymore.
The people launching a SaaS in 40 hours are not concerned with the state of vibe coding, the quality of code, or the testing.
They care about the business. If you want to be like them, start by caring far less about the actual code or how it gets made. They will bring in people later who do, who will clean up the vibed mess
*I'm generally not a fan of this, but you asked
You can tell LLMs to conform to certain quality standards and code in a way you think is best.
Gold plating code with the best quality standards takes LLMs seconds whereas it would take you days doing it by hand.
> You can tell LLMs to...
and they may or may not "listen", they are non-deterministic and have no formal means or requirements to adhere to anything you write. You know this because they violate your rules all the time in your own experience
Sure but in my experience LLMs behave much more consistently than humans with regards to quality. LLMs don't skip tests because they have to make a deadline for example.
And now we have LLMs that review LLM generated code so it's easy to verify quality standards.
At the same time, the LLM will, with some reliability, ignore the patterns or best practices in your code, or implement the same thing twice in different ways.
There are certain things they do, or don't do, that a human typically wouldn't, putting absolutes and anecdotes aside
Humans, with reliability, will ignore the patterns or best practices in your code and implement the same thing twice in different ways.
In 25 years I've never worked in a codebase where this wasn't true.
As a group or the same person under the same constraints
It's far to nuanced for generalities tbt
I have been doing full stack web dev since 2003 and iOS apps since 2008. I do not write code anymore. At my day job I don't think I get more done over time because the code is rarely ever the bottleneck at that place. I do have more time to experiment and try things and say yes more to asks from colleagues.
Outside of work, I have just launched an iOS app I've wanted to build but has been outside my current skillset. I was able to "vibecode" this app in about 4-5 months.
The application has a tiny bit of moat because it involves a ML model (also vibecoded) trained on my own data set.
When I say vibecoded, I never reviewed or read code in detail. I really only ever saw snippets claude code shows here and there. I asked a lot of questions, much more than asking it to make changes. I only gave it high-level architectural guidance like "use MVVC", etc. I did a lot of manual testing and reading logs.
I won't name the app out of fear of shilling my vibeslop, or whatever, check my profile for the domain in an email address if you want to know more.
I think this is exactly the kind of example I wanted to see, so thank you for sharing. I was thinking about it yesterday and realized that it might actually be worth trying to switch my current project entirely to “vibe development.” That said, I still worry a bit that AI might change the structure or expand the code when all I really want is to tweak a single line or a few expressions—but I’m sure there’s a way to handle that.
From my recent experience doing a project that involved setting up AWS infrastructure with CloudFormation - a VPC, subnets, docker based lambda s, SNS, SQS, etc - and the code on top of it, it did perfectly with code but took some going back and forth with infrastructure as code
The first thing I did was keep everything as decoupled as possible with so it would be simple for Codex and Claude Code (I use both) to reason over. I work the same way when setting up my own repos.
I treat Codex/Claude as junior developers and I keep my hands on the wheel
LOC doesn’t matter if you have clean modularity
For different people, its in different stages.
What's cool about this is that, every time new engineer joins this wave, there are more interesting ideas coming and shaping the "vibers" industry.
In my day to day job, now I am worried, it will be very difficult to get a new job, because I vibe so much that I almost forgot to write code from scratch.
Examples:
* Hey Claude, increase mem usage from 500Mb to 1500Mb in production - fire and forget
* Plan mode: What kind of custom metrics can we add to Xyz query processor? Edit mode: add only 3,4 and 9. Later we will discuss 8
* Any other small changes I have...
I primarily became a manager of bunch of AI agents running in parallel. If you interview me and ask me to write some concurrent code, there is a high probability that I will fail it without my AI babies
Vibe coding sits on an axis from smart autocomplete to one-shotting a $1B SaaS. Traditional software engineering was about holding the system in your head and translating it into syntax, fighting tooling and architecture decisions along the way. I think done properly it removes many of these friction points along the way to validating / implementing the idea.
Now it's easier to traverse a live plan and to quickly make micro pivots as you go.
I also think that architecture needs to change. Design patterns that will help to provide as much context to the LLM as possible to increase understanding.
What's your moat? What's your barrier to entry? What's your competitive advantage? If you can vibe code it in a weekend, someone else can vibe code a competing thing the next weekend. You're not going to build something that becomes a long-term business that way, because anybody else can take your business.
For a larger, more complex system, the real barrier is understanding what needs done well enough that you can build something that can do it. (In my opinion, that has always been the real barrier.)
Why do you think you need exclusivity?
The moat is most people aren't using LLMS, most people aren't building products, most people who might built it will never hear of your product, people will have other ideas competing for their attention, people are incompetent, and all the work that happens after the coding.
How many people do you think are out there vibe coding things?
Aren't companies built on execution? Or do we now build companies on tech stacks alone?
Before LLMS, how could a solo dev get a moat? Any company could hire a team to replicate your product. They might not care how much it costs them. "Hours spent coding" isn't the moat.
I've 'vibe coded' some internal tooling apps and it feels like i've joined a new company and been given a legacy codebase to work on, despite it being a week old.
I just assume all the posts that claim they've got a 20k line project in a single weekend is just marketing spam.
The problem with these discussions is no matter your specific experience with these tools someone will just say "you're holding it wrong"
"If it worked for my use case and didn't work for yours, you're obviously just doing something wrong. That's the only explanation."
The real shift feels like moving from “writing code” to “making intent explicit.” If the domain model and invariants are clear, AI helps a lot with mechanical work. If they aren’t, no amount of vibe coding saves time. That makes productivity comparisons kind of meaningless.
Until recently, I thought that complex, multi-domain platforms were still relatively safe. But today, I’m seriously reconsidering and thinking about whether I should switch to a “vibe coding” approach.
I should also consider isolating the custom logic in the existing codebase as much as possible, converting it into general logic, and then testing the “vibe” approach directly.
All these stories about people using llms and hitting it big almost overnight make me feel dumb. I'm sure others feel the same. Probably FOMO.
My sense of using LLMs for coding is me feeling like a maintenance programmer even though the code is brand new and I'm debugging a LLM misunderstanding. Weird to be working on a 10k codebase that didn't exist a few hours ago and I'm now debugging it over the next 4 hours. Having it done around 16-20 work hours later is really strange.
> Weird to be working on a 10k codebase that didn't exist a few hours ago
This is the issue. A firehose of code production is not useful for a long time. But it's very useful in short bursts. Total volume of code was never the bottle neck or the goal.
Working with LLMs has all the same pitfalls of working with people. Programming effectively for the long term requires all the same rules whether you're using LLM's or not: build incrementally, test and refactor as you go (not at the "end"), keep scopes small, ship frequently, etc.