Of course this whole "it will make your more productive" marketing s** is absurd! How can we know? Living on the Moon will make you 27% happier! How do you know that? Has anyone done it in the past? Is there data to back that up? How would you measure happiness? How do we measure productivity, for that matter? That one is still a mystery. But it doesn't matter that we don't know how to, we'll just make it 2x better. That's absurd!
I remember from the days when watching TV. There were these preposterous commercials saying "23% more efficient than other toothpastes" or "33% less dandruff than a regular shampoo" or shit like that. How do you know what products do I use? How do you measure that? What skin type? No. It is just better. Trust us.
I mean, the financial backing in this sector is staggering. We know that already. It's a fact. There are also numbers. Billions if not trillions of them. What does Joe The Developer think all this kind of money goes to? Some of them, and not a small part, goes into marketing. Unless Joe still believes in the "build it and they will come" fake motto. Whomever has a stake in this will back it up, marketing it like crazy. Assume victory even in defeat as the old guy says. I was laughing hard one day when I saw Ilya Sutskever, laptop in hand, strolling the parks for a green meadow to work, develop ground-breaking ideas to save humanity! That's just marketing.
Liked your post. I don't think it matters (that much) that your native language is not English. We don't want to sound all the same by using AI to fix our grammar (ok, maybe this one, yes) or the awkward twists of sentences. Sometimes AI fixes them too good, leaving little room for some poetry into it.
I'm not sure I understand. Do you mean that overtime some people will develop intuition for the "right vibes" and it won't be replicable by others or computers?
All LLMs hit a ceiling of complexity beyond which they cease to understand the code base. Greenfield projects show this particularly well, because the LLM works until it doesn’t. There are lots of greenfield projects that should exist! And lots of ways that someone can manage context and their own understanding of code to push the LLM further than its current limits, although not indefinitely far.
The greenfield phase feels amazing and if it stopped there I would have been really happy. This is where LLMs are really good. It's also a lot more fun than glueing tools together so I can see more people getting into it. It's not something one does profesionnaly though. It's more like an extra. I guess we'll have to see how far they can push the ceiling...
I understand the audience this person has written for: professional developers. In that context, sure. But for everyone except professional developers vibe coding is amazing.
It gets the things they want to do done. No paying someone else, no asking for help on $chatprotocolchannel, no getting a friend to help. It's just there. It doesn't matter if it's ugly. It doesn't need to be monetized, doesn't need to be worked on by a team of people. It just needs to work... enough.
Vibe coding may not be for you. But vibe coding is so that we don't need to bother you for trivial things (like porting a 12 .c file X11/cairo program to a single .pl file cariro/gtk program).
I think it’s terrible if you want to work at a company, but probably decent if you are building an app for yourself that has a good business case and good marketability.
As a STEM field, the software engineer's role is probably still secure against AI tool wielders waving around chainsaws without the necessary training and accidentally sawing production databases in half.
What LLMs are poised to replace is basically the entirety of the liberal arts and academic disciplines, where output is largely measured on the production of language - irrespective of that language's correspondence to any actual underlying reality. Musicians and authors - fiction and non-fiction alike - are already witnessing their impending obsolescence in real time.
This is the wrong view. It's more like "Soon, everyone will be able to go from idea to a prototype". IMO, there's a different value perception when people can use concrete things even if they are not perfect. This is what I like about end-to-end vibe coding tools.
I don't see a non developer using Claude Code but I can totally see them using Github Spark or any similar tool. After that, the question is how can I ensure this person can keep moving forward with the idea.
It's great that more non developers can create their own software now and I made it clear that I'm in full agreement with this.
What I'd argue is that people who build software professionally and got really good at it (or want to) focus on completely different types of projects where vide coding is irrelevant.
i wish more folks would post P(how much I believe my own take) when they make takes.
I don't think the author is fundamentally wrong; but its delivered with a sense of certainty thats similar in tone to the past 5 years of skepticism that has repeatedly been wrong.
Instead of saying "vibe coded codebases are garbage", the author would be better served writing about "what does the perfect harness for vibe coded codebase look like so that it can actually scale to production"?
There's no way to know for sure. If there was, we wouldn't be having this conversation. But I'm trying to make an educated guess.
I read the news: AI is taking over and we'll soon all be out of jobs. So I have to decide. Do I double down on software engineering, pivot to vibe coding, or try something completely different?
I need a sense of certainty to make this call, so I researched it. This post is the result. I might be wrong, but at least I'm choosing a clear direction instead of constantly switching and never getting good at either.
Vibe coding today doesn't deliver anywhere near the value of a competent software engineer. Rather than extrapolate from past progress, I looked at what it would take today.
You asked about how we will turn a vibe-coded codebase into production-ready systems. I have no idea how we'll do that and I didn't find someone with a solid plan for it.
The logical conclusion here is that there's still plenty of runway for skilled software engineers. So I'm betting on becoming a better one with or without AI.
About "vibe coded codebases are garbage".
If someone doesn't know how to build software (or quality doesn't matter) vibe coding is perfect. The code might be garbage but it beats having nothing.
These projects would otherwise be Excel spreadsheets or duct-taped tools. Now they have another option.
The problem is when people suggest vibe coding replaces developer skills, as if producing code was the bottleneck.
Fair enough. I went back and forth on whether to include it. I kept it anyway because I thought it was a funny way to capture what I feel vibe coding is: just keep rerolling until I get what we want.
Plus, I thought it would immediately shut down the strawman that I'm anti-AI. The generated image clearly shows I'm not.
Sorry it put you off. I hope you still found the text interesting.
I know 2 MBA types who have been in tech a long time who are currently doing a combo of vibe coding v0 style coupled with a regular LLM spitting out code (o3 pro I believe), coupled with a coding agent in slack they talk to, connected to github, both of them seem to be making considerably progress on being able to launch to a few 100 users on their own. That said, both of them seem to realize they can't scale an app without devops, so they will hit a wall there I suspect. Largely agree with this blog, but we'll see where things go with agents.
I think the author is a bit behind the "complexity prompting" state of things. He says learning vibe coding is easy and he did it in a couple of weeks, but he also hit a wall and now its bugs everywhere. So maybe... there is more to learn?
I also hit the complexity wall and worked through it. LLMs are genius with arms that can reach anything but eyes two inches from the screen. As a metaphor, think of when a code base gets too big for one person to manage everything, people start to "own" different parts of the code. Treat LLMs the same and build a different context for each owner.
The key is to not get to a point where you lose sight of the big picture. You are riding a bronco - try not to get thrown off! If you do, ask the LLM to describe the structure of things or restructure things to be more consistent, etc. Get to a place where YOU understand everything, at least in an architectural sense. Only then can you properly instruct the AI forward.
I'll accept this criticism. I've only done it for a month or so. That said, I do feel confident that, after reading plenty of online articles, I have learnt 80% of AI coding skills.
I configured Playwright and PostgreSQL MCP. Loads of unit and e2e tests for Claude to run after each change. Storybook for my components. I have multiple doc files in each folder.
I'm happy to learn though and would welcome any suggestions.What am I missing?
Right now, I have a bug with my message queue. I didn't spend enough time thinking about the proper way to implement and test it. I guess I also didn't pay enough attention to the PR. But then, if I did, is it really vibe coding or classic software engineering while getting Claude to write for me with the added burden of reviewing it thoroughly?
The issue is that if a user sends a message to someone, quickly switches to someone else and sends a message, both messages get sent to the first person.
I'll have to figure out why it happens. My guess is that it's somewhere in the React app. Claude can't figure it out. What can I do to help it?
If coding agents progress like the predictions, there is no world where many people are not out of jobs. Not just coders, but code related jobs. There is so much infra around humans not writing good code, or not being able to plan well.
If agents get so good that they overcome these obstacles then most mid tier companies dev staff is going to be a couple of people making sure the agents are online and running.
That's a lot of "if" to bet my career on. I can't see a situation where I can do most of my work using LLMs and retain my coding skills. I can see it with people who used to be great developers and moved to management. After a few years, they can't write code anymore.
But if it does happen, I'd rather be the one with enough technical skills to be able to jump in when agents aren't good enough or create new ones than the one managing them.
The term "You're absolutely right" has become a joke / meme for idiotic vibe coding sessions that i really hope Anthropic will ban this phrase with its next models.
> There's no first-mover advantage when the entire playing field gets bulldozed.
I feel like the AI companies are constantly getting ahead of themselves. The recent generation of LLMs is getting really good at writing or modifying code incrementally following a precise specification. But no, of course that's no longer good enough. Now we have agents who are as dodgy as LLMs were a few years ago. It's as if Boeing launched the 707 too early, got it to work after a few (plane) crashes, but then, instead of focusing on that, they launch the 747 also too early, and it also promptly crashes. Little wonder that people will be more preoccupied with the crashes than with what actually works...
The article isn't saying "vibe coding goes nowhere" -- that's just the headline.
The point being made is that vibe coding is changing so fast that any investments you make today into learning is quickly obsolete tomorrow as someone puts out a new tool/framework/VSCode-fork that automates/incorporates your home-brewed prompt workflow.
It's like a deflationary spiral in economics -- if you know that prices will drop tomorrow, only the sucker buys something today (but because no one is buying today, that demand destruction causes prices to drop, creating a self-fulfilling doom loop).
Similarly: with LLM coding, any investment you spend in figuring out how to prompt-engineer your planning phase will be made obsolete by tomorrow's tools. Really your blog post about "how I made Claude agents develop 5 feature branches in parallel" is free R&D for the next AI tool developer who will just incorporate your tips&tricks (and theoretically even monetize it for themselves)
The argument here (get your pitchforks ready, all ye early adopters) is "we all just need to sit back for 6 months and see how these tools shake out, early adoption is just wasted effort."
Everyone is doing this sort of "better write some MCPs" thing, so that you can keep the LLM on the straight and narrow.
Well, let me tell you something. I just went through my entire backlog of improvements to my trading system with Claude, and I didn't write any MCPs, I didn't write long paragraphs for every instruction. I just said things like:
- We need a mock exchange that fits the same interface. Boom, here you go.
- How about some tests for the mock exchange? Also done.
- Let's make the mock exchange have a sawtooth pattern in the prices. Ok.
- I want to write some smart order managers that can manage VWAPs, float-with-market, and so on. Boom, here you go.
- But I don't understand how the smart orders are used in a strategy? Ok, here's a bunch of tests for you to study.
- I think we could parse the incoming messages faster. Read the docs about this lib, I think we can use this thing here. Boom, done.
- I have some benchmarks set up for one exchange, can you set up similar for others? Done.
- You added a lock, I don't want that, let's not share data, let's pass a message. Claude goes through the code, changes all the patterns it made, problem solved.
- This struct <here>, it has a member that is initialized in two steps. Let's do it in one. Boom, done.
- I'm gonna show you an old repo, it uses this old market data connector. How do we use the new one instead? Claude suggests an upgrade plan starting with a shared module, continuing towards full integration. Does the first bit, I'm mulling over the second.
Over the last four days, it has revolutionized my code. I had a bunch of things I knew I could do if given enough time. None of the above would stump me as an experienced dev these days. But it would take my attention. I'd be in a loop of edit/compile/test over every feature I've mentioned above, and I would be sure to have errors in either syntax or structure. At some point, I would use a pattern that was not ideal, and I'd have to backtrack and type/google/stackoverflow my way out of, and each step would take a while.
Now, I can tell Claude what to do, and it does it. When it fails, it's productively failing. It's closer to the target, and a gentle nudge pushes it to where I want.
You're describing exactly what I distinguish as legitimate AI use, not vibe coding. You're an experienced dev who understands your system deeply, making architectural decisions ("no locks, pass messages instead") and using Claude to implement specific, well-defined tasks faster.
The key difference: you could do everything yourself and Claude is doing the typing for you.
When you say "None of the above would stump me as an experienced dev", that's the opposite of vibe coding.
You're using AI as a typing accelerator for a codebase you understand, not as a replacement for expertise you never developed.
I one time had a hilarious chat with a 13 year old who started coding php/js when he was 9. He couldn't really code at all but every day for 4 years he examined/learned 3 things, libraries, api, frameworks. He knew how to query absolutely everything.
His projects were pure glue code. One was some data sets + some data visualization with charts + some map api. A few hours of work, it looked rather remarkable.
Our chat was specially hilarious since I take writing everything from scratch to the absurd level. His one trick was to know all the places online where you can ask your noob developer questions. He was working with a kind of imaginary token system where you get to ask a limited number of questions per month on each platform.
His queries were truly fantastic. A reasonable dev could answer them with little effort, sometimes the next guy would write out the glue code. He didn't ask for much.
13 seems some kind of magical sweet spot where we take the person just serious enough.
Sometimes people had questions about the API, he knew those inside out which was a hilarious contrast.
I asked him: What do you do when it stops working? The answer was to start from scratch. He posted the old glue code, explained it didn't work anymore and someone would answer the easy question.
The process was so completely alien to me that I'm not going to guess where the LLM's are taking us.
The author got too big for their britches and was drunk on perceived power. No need to have many parallel agents going on. Focus on one project and implementing features one at a time and dogfooding and testing. Shipping any code, vibed or not, then saying it blew up is not the LLMs fault. I can’t believe I’m saying that. It’s the shipper’s responsibility to make sure it works. Of course if you are a manager and let your junior ship code it will blow up…
And yes I know AI is marketed as more. But it’s still people’s fault for swallowing the PR and shipping crappy code then complaining about the lies. Stop deflecting responsibility for your work
I do agree that I should take responsibility for my work. This is why I experimented on a small side project with a limited user base instead of my main app, which generates my income.
What really sold vibe Coding to me was the idea that I could be significantly faster by working on multiple features in parallel. I'm an agent orchestrator. I send them off in the right direction, regularly check on them and correct if needed. They run all the tests and keep working until they all pass. Once they're done, I review their work and if I'm satisfied, merge it.
The hard reality is that properly reviewing code at this scale is extremely difficult and I inevitably let errors slip through.
Maybe I should spend more time reviewing it. But I'm almost certain it would take me more time and effort than writing the code myself and I'm not even sure I'd ever reach the same level of understanding.
If I ask Claude to do one thing at a time and monitor it, I need to get the prompt right, wait for it to respond with some changes and then review them thoroughly before accepting them. I can imagine this being an alternative way to build software. But I doubt it's faster.
In my experience limiting myself to two projects in parallel is most productive, with a clear primary project whose agent’s completion take precedence over the other’s. It lets me still have concurrent work going on, but I’m very clearly still taking care to be precise and targeted with my prompting. Too many things going on, and I’m no longer optimizing for doing the task but for having as much parallel execution and progress as possible, and that’s a trap of perceived productivity.
52 comments
[ 3.9 ms ] story [ 74.2 ms ] threadI remember from the days when watching TV. There were these preposterous commercials saying "23% more efficient than other toothpastes" or "33% less dandruff than a regular shampoo" or shit like that. How do you know what products do I use? How do you measure that? What skin type? No. It is just better. Trust us.
I mean, the financial backing in this sector is staggering. We know that already. It's a fact. There are also numbers. Billions if not trillions of them. What does Joe The Developer think all this kind of money goes to? Some of them, and not a small part, goes into marketing. Unless Joe still believes in the "build it and they will come" fake motto. Whomever has a stake in this will back it up, marketing it like crazy. Assume victory even in defeat as the old guy says. I was laughing hard one day when I saw Ilya Sutskever, laptop in hand, strolling the parks for a green meadow to work, develop ground-breaking ideas to save humanity! That's just marketing.
Liked your post. I don't think it matters (that much) that your native language is not English. We don't want to sound all the same by using AI to fix our grammar (ok, maybe this one, yes) or the awkward twists of sentences. Sometimes AI fixes them too good, leaving little room for some poetry into it.
It gets the things they want to do done. No paying someone else, no asking for help on $chatprotocolchannel, no getting a friend to help. It's just there. It doesn't matter if it's ugly. It doesn't need to be monetized, doesn't need to be worked on by a team of people. It just needs to work... enough.
Vibe coding may not be for you. But vibe coding is so that we don't need to bother you for trivial things (like porting a 12 .c file X11/cairo program to a single .pl file cariro/gtk program).
What LLMs are poised to replace is basically the entirety of the liberal arts and academic disciplines, where output is largely measured on the production of language - irrespective of that language's correspondence to any actual underlying reality. Musicians and authors - fiction and non-fiction alike - are already witnessing their impending obsolescence in real time.
This is the wrong view. It's more like "Soon, everyone will be able to go from idea to a prototype". IMO, there's a different value perception when people can use concrete things even if they are not perfect. This is what I like about end-to-end vibe coding tools. I don't see a non developer using Claude Code but I can totally see them using Github Spark or any similar tool. After that, the question is how can I ensure this person can keep moving forward with the idea.
I don't think the author is fundamentally wrong; but its delivered with a sense of certainty thats similar in tone to the past 5 years of skepticism that has repeatedly been wrong.
Instead of saying "vibe coded codebases are garbage", the author would be better served writing about "what does the perfect harness for vibe coded codebase look like so that it can actually scale to production"?
I read the news: AI is taking over and we'll soon all be out of jobs. So I have to decide. Do I double down on software engineering, pivot to vibe coding, or try something completely different?
I need a sense of certainty to make this call, so I researched it. This post is the result. I might be wrong, but at least I'm choosing a clear direction instead of constantly switching and never getting good at either.
Vibe coding today doesn't deliver anywhere near the value of a competent software engineer. Rather than extrapolate from past progress, I looked at what it would take today. You asked about how we will turn a vibe-coded codebase into production-ready systems. I have no idea how we'll do that and I didn't find someone with a solid plan for it.
The logical conclusion here is that there's still plenty of runway for skilled software engineers. So I'm betting on becoming a better one with or without AI.
About "vibe coded codebases are garbage". If someone doesn't know how to build software (or quality doesn't matter) vibe coding is perfect. The code might be garbage but it beats having nothing.
These projects would otherwise be Excel spreadsheets or duct-taped tools. Now they have another option.
The problem is when people suggest vibe coding replaces developer skills, as if producing code was the bottleneck.
Plus, I thought it would immediately shut down the strawman that I'm anti-AI. The generated image clearly shows I'm not.
Sorry it put you off. I hope you still found the text interesting.
I also hit the complexity wall and worked through it. LLMs are genius with arms that can reach anything but eyes two inches from the screen. As a metaphor, think of when a code base gets too big for one person to manage everything, people start to "own" different parts of the code. Treat LLMs the same and build a different context for each owner.
The key is to not get to a point where you lose sight of the big picture. You are riding a bronco - try not to get thrown off! If you do, ask the LLM to describe the structure of things or restructure things to be more consistent, etc. Get to a place where YOU understand everything, at least in an architectural sense. Only then can you properly instruct the AI forward.
Right now, I have a bug with my message queue. I didn't spend enough time thinking about the proper way to implement and test it. I guess I also didn't pay enough attention to the PR. But then, if I did, is it really vibe coding or classic software engineering while getting Claude to write for me with the added burden of reviewing it thoroughly?
The issue is that if a user sends a message to someone, quickly switches to someone else and sends a message, both messages get sent to the first person.
I'll have to figure out why it happens. My guess is that it's somewhere in the React app. Claude can't figure it out. What can I do to help it?
If agents get so good that they overcome these obstacles then most mid tier companies dev staff is going to be a couple of people making sure the agents are online and running.
Vibe coding is just the canary in the coal mine.
But if it does happen, I'd rather be the one with enough technical skills to be able to jump in when agents aren't good enough or create new ones than the one managing them.
I feel like the AI companies are constantly getting ahead of themselves. The recent generation of LLMs is getting really good at writing or modifying code incrementally following a precise specification. But no, of course that's no longer good enough. Now we have agents who are as dodgy as LLMs were a few years ago. It's as if Boeing launched the 707 too early, got it to work after a few (plane) crashes, but then, instead of focusing on that, they launch the 747 also too early, and it also promptly crashes. Little wonder that people will be more preoccupied with the crashes than with what actually works...
Interestingly, I wrote something similar recently "Too Fast to Think: The Hidden Fatigue of AI Vibe Coding", https://www.tabulamag.com/p/too-fast-to-think-the-hidden-fat...
There seems to be something overloading our capacity as coders.
The point being made is that vibe coding is changing so fast that any investments you make today into learning is quickly obsolete tomorrow as someone puts out a new tool/framework/VSCode-fork that automates/incorporates your home-brewed prompt workflow.
It's like a deflationary spiral in economics -- if you know that prices will drop tomorrow, only the sucker buys something today (but because no one is buying today, that demand destruction causes prices to drop, creating a self-fulfilling doom loop).
Similarly: with LLM coding, any investment you spend in figuring out how to prompt-engineer your planning phase will be made obsolete by tomorrow's tools. Really your blog post about "how I made Claude agents develop 5 feature branches in parallel" is free R&D for the next AI tool developer who will just incorporate your tips&tricks (and theoretically even monetize it for themselves)
The argument here (get your pitchforks ready, all ye early adopters) is "we all just need to sit back for 6 months and see how these tools shake out, early adoption is just wasted effort."
Everyone is doing this sort of "better write some MCPs" thing, so that you can keep the LLM on the straight and narrow.
Well, let me tell you something. I just went through my entire backlog of improvements to my trading system with Claude, and I didn't write any MCPs, I didn't write long paragraphs for every instruction. I just said things like:
- We need a mock exchange that fits the same interface. Boom, here you go.
- How about some tests for the mock exchange? Also done.
- Let's make the mock exchange have a sawtooth pattern in the prices. Ok.
- I want to write some smart order managers that can manage VWAPs, float-with-market, and so on. Boom, here you go.
- But I don't understand how the smart orders are used in a strategy? Ok, here's a bunch of tests for you to study.
- I think we could parse the incoming messages faster. Read the docs about this lib, I think we can use this thing here. Boom, done.
- I have some benchmarks set up for one exchange, can you set up similar for others? Done.
- You added a lock, I don't want that, let's not share data, let's pass a message. Claude goes through the code, changes all the patterns it made, problem solved.
- This struct <here>, it has a member that is initialized in two steps. Let's do it in one. Boom, done.
- I'm gonna show you an old repo, it uses this old market data connector. How do we use the new one instead? Claude suggests an upgrade plan starting with a shared module, continuing towards full integration. Does the first bit, I'm mulling over the second.
Over the last four days, it has revolutionized my code. I had a bunch of things I knew I could do if given enough time. None of the above would stump me as an experienced dev these days. But it would take my attention. I'd be in a loop of edit/compile/test over every feature I've mentioned above, and I would be sure to have errors in either syntax or structure. At some point, I would use a pattern that was not ideal, and I'd have to backtrack and type/google/stackoverflow my way out of, and each step would take a while.
Now, I can tell Claude what to do, and it does it. When it fails, it's productively failing. It's closer to the target, and a gentle nudge pushes it to where I want.
His projects were pure glue code. One was some data sets + some data visualization with charts + some map api. A few hours of work, it looked rather remarkable.
Our chat was specially hilarious since I take writing everything from scratch to the absurd level. His one trick was to know all the places online where you can ask your noob developer questions. He was working with a kind of imaginary token system where you get to ask a limited number of questions per month on each platform.
His queries were truly fantastic. A reasonable dev could answer them with little effort, sometimes the next guy would write out the glue code. He didn't ask for much.
13 seems some kind of magical sweet spot where we take the person just serious enough.
Sometimes people had questions about the API, he knew those inside out which was a hilarious contrast.
I asked him: What do you do when it stops working? The answer was to start from scratch. He posted the old glue code, explained it didn't work anymore and someone would answer the easy question.
The process was so completely alien to me that I'm not going to guess where the LLM's are taking us.
And yes I know AI is marketed as more. But it’s still people’s fault for swallowing the PR and shipping crappy code then complaining about the lies. Stop deflecting responsibility for your work
What really sold vibe Coding to me was the idea that I could be significantly faster by working on multiple features in parallel. I'm an agent orchestrator. I send them off in the right direction, regularly check on them and correct if needed. They run all the tests and keep working until they all pass. Once they're done, I review their work and if I'm satisfied, merge it.
The hard reality is that properly reviewing code at this scale is extremely difficult and I inevitably let errors slip through.
Maybe I should spend more time reviewing it. But I'm almost certain it would take me more time and effort than writing the code myself and I'm not even sure I'd ever reach the same level of understanding.
If I ask Claude to do one thing at a time and monitor it, I need to get the prompt right, wait for it to respond with some changes and then review them thoroughly before accepting them. I can imagine this being an alternative way to build software. But I doubt it's faster.