Guess what happens when you can suddenly build features ahead of schedule? You can make them bulletproof instead of cutting corners.
Our code is better and more robust than it's ever been. Our rate of user-reported bugs have dropped more than 50% since we started "vibe" coding 6-ish months ago.
Product people love the idea of being able to fire their dev teams, but I'm not sure they understand the implications (some of wich may not become clear for years).
It's interesting that you describe yourself as a developer now.
Because just three months ago, in your first post [1] to HN, you said:
> I'm somewhat non-technical but I've been using Claude to hack MVPs together for months now.
Sure: you might feel as though you have now 10x'ed yourself. But, quite honestly, when the reality is that just a few months back you self-described as "somewhat non-technical", it's clear that (a) you're at such an early stage in your learning and understanding of tech, as a developer, that it's relatively easy to experience bigs gains, and (b) you can't actually have much of an objective measure on this, because you are in fact quite new to the field.
I read a lot of your other comments. To me, even before I had confirmation that you were actually "somewhat non-technical", and fairly new to the field — effectively a junior developer by any real measure — this was already quite apparent to me.
Based upon having been a developer for some decades myself already: I can generally spot those that talk-the-talk — and similarly: I can generally spot those who have non-trivial / deeper experience with various fields of tech.
Powering-up with AI tooling doesn't remedy that. Even if it might seem otherwise from your "somewhat non-technical"-but-newly-empowered position.
Good luck with your coding endeavours though, and with your evangelism.
I have no doubts at all that the world is changing — including how software is developed. But I see your posts for what they are.
Unfortunately there’s no bans for stuff like that.
But that’s why I call it out: yes, exactly, it degrades the conversation when someone is preaching about a new tech, and how it’s gonna change development, and claiming they’re a developer themselves - while not being upfront about the fact that they’ve not actually got much real-world experience as a developer at all in general.
And this kind of thing should always be called out when spotted. It’s just plain disingenuous at the end of the day.
I’ve probably been contracted to fix more broken projects (by devs who royally messed up), than the count of MVPs this person has made, or indeed the number of months they’ve been coding.
But at the end of the day, these kinds of folk simply make us more experienced folk more valuable to those that need a professional service in a bail-out scenario. I’ve got decades of real-world coding experience, and a healthy list of successfully published / deployed projects, including some fairly big clients over the years. My CV speaks volumes, particularly when contrast against someone with little experience in the field of software development. I’ve seen languages and tooling come and go. I’ve headed teams and worked solo. I’ve witnessed plenty of folk
like this in my time. It’s certainly not my first rodeo!
Unfortunate that someone chose to downvote me, as opposed to engaging me in conversation as to why my view might perhaps be incorrect or maybe shortsighted - as per the HN guidelines. But no real surprise - I guess that in itself is quite telling here.
Karma points might come and go sometimes, but whatever: I’ve been posting on HN (and other sites) for years, on and off. I’ve no need to try and portray myself as something I’m not, nor portray myself to have skills or experience that I don’t have. I generally post to share my knowledge and experience, because real-world experience adds up over time.
Yeah I was a jr developer for a year before I became a PM. That's the definition of being "somewhat non-technical" as I put it.
you've been a developer for some decades which is why your reality is threatened that your craft is increasingly becoming irrelevant so you had to snoop my profile to find some confirmation that your reality doesn't get shattered
this is nothing new of course. obnoxious neckbeard engineers who don't understand where the world is going have existed since the unix debates on irc. you'll find plenty of people who agree with you on mastodon lol.
Ah right, junior dev for a year. Wow, how amazing.
Plenty of room for you to 10x many times over then.
Over the years, I’ve met plenty of folk who have dabbled with software development, before deciding it wasn’t for them - then pivoting to something less technical.
Nah, I don’t feel threatened at all by AI. My job is secure. Tools change, sure. But there’s plenty of years left in software development for sufficiently skilled humans. No matter what a junior-level dev / AI evangelist might claim.
I’ll be cleaning up and properly re-implementing the MVPs that less knowledgeable folk are throwing together, slap dash. For a long while yet. And doing other stuff that AI simply can’t do properly - and quite honestly is quite far from doing.
Your rhetoric betrays your knowledge, and your bravado and insults can’t make up for that in any way.
It’s easy to get enchanted by current generative AI, and believe it far more capable than it is. Particularly if not overly skilled in whatever domain. Particularly if one doesn’t have much of a grasp on how generative AI actually works. Good luck with that.
> you've been a developer for some decades which is why your reality is threatened that your craft is increasingly becoming irrelevant so you had to snoop my profile to find some confirmation that your reality doesn't get shattered
Hahaha - no, that's really not accurate at all. On lots of levels. The ability to read another user's comments is there so that anyone who chooses can actually get a better understanding of who they're talking with, and what that person is about. One doesn't have to feel threatened at all to want to use it, one simply has to be intellectually curious, and interested to find out more...
There's no need to try and portray it as a negative, and make out there's something afoot which isn't actually taking place.
Anyone who's been here on HN for any significant amount of time knows exactly what that feature is for — as well as when it might be best to use it. And people absolutely will use it.
It helps separate the wheat from the chaff.
— Please do try and take care that your wide-of-the-mark unnecessary put-downs and name calling don't violate the HN guidelines! (Just for your own good!)
There's def a lot of gatekeeping going on by the real coders™. The rest of us are just learning and adapting. Personally, I'm glad that it's now easy to build decent looking UIs and quickly tune SQL.
How ironic. I have literally made my career and fortune building the very systems that you’re yapping about.
Edit: see the other comment where you are called out for the lying fake that you are. How delightfully pathetic of you.
lol "fortune" whatever you say. that's why you're desperately snooping my other comments including that lame "gotcha" to find some confirmation I'm lying?
it's ok, all craftsmen who got automated away once thought they were special. you're not the first you won't be the last. you will likely be unemployed soon though.
Open mind here. Spill more details please. We're the 9 good or was their dead weight. Could the 9 to 2 have been done without AI anyway (because less work to do).
Trying to get my head around this. It must mean 90% of what they were doing was writing code. Like not even thinking, architecture, gathering requirements, make sure you built the right thing etc. Just generating syntax.
In my experience it's usually a few devs doing the most of that, and the rest are largely banging out features, debugging, refactoring. There's also just a lot more efficiency when you shrink the team.
So why wouldn't you keep them? If you're able to produce even more with AI enabled engineers, why downsize? To me, it sounds like a startup's dream to be able to output more without increasing headcount.
I'd take strong opinions for/or against with a grain of salt. It's likely you're suffering a bit from baader meinhof.
I could certainly see a possible reduction in engineering team size, but going from 9 to 2 makes me question how much of that reduction was a result of over-hiring in the first place.
I feel exactly the same. On the other hand, the “speed up my work a lot” part is important, and shouldn’t be overlooked. Like, if someone reads this article and figures they don’t need to learn to use AI for their coding job, that’s the wrong conclusion to make.
Agreed, I feel that a developer who refuses to learn to work with AI tools will inevitably fall behind those that do. But I don't see AI being able to replace a developer who can work WITH AI anytime soon (at least on anything non trivial).
The job loss depends on the average speed up, however. If the AI is only effective in 10% of tasks (the basic stuff), then that 3x improvement goes down to 1.3x.
That's such a economical fallacy that I'd expect the HN crowd to have understood this ages ago.
Compare the average productivity of somebody working in a car factory 80 years ago with somebody today. How many person-hours did it take then and how many does it take today to manufacture a car? Did the number of jobs between then and now shrink by that factor? To the contrary. The car industry had an incredible boom.
Efficiency increase does not imply job loss since the market size is not static. If cost is reduced then things are suddenly viable which weren't before and market size can explode. In the end you can end up with more jobs. Not always, obviously, but there are more examples than you can count which show that.
This is all broadly true, historically. Automating jobs mostly results in creating more jobs elsewhere.
But let's assume you have true, fully general AI. Further assume that it can do human-level cognition for $2/hour, and it's roughly as smart as a Stanford grad.
So once the AI takes your job, it goes on to take your new job, and the job after that, and the job after that. It is smarter and cheaper than the average human, after all.
This scenario goes one of three ways, depending on who controls the AI:
1. We all become fabulously wealthy and no longer need to work at all. (I have trouble visualizing exactly how we get this outcome.)
2. A handful of billionaires and politicians control the AI. They don't need the rest of us.
3. The AI controls itself, in which case most economic benefits and power go to the AI.
The last historical analog of this was the Neanderthals, who were unable (for whatever reason) to compete with humans.
So the most important question is, how close actually are we to this scenario? Is impossible? A century away? Or something that will happen in the next decade?
> But let's assume you have true, fully general AI.
Very strong assumption and very narrow setting that is one of the counter examples.
AI researchers in the 80s already told you that AI is around the corner in the next 5 years. Didn't happen. I wouldn't hold my breath this time either.
"AI" is a misnomer. LLMs are not "intelligence". They are a lossy compression algorithm of everything that was put into their training set. Pretty good at that, but that's essentially it.
That assumes a static demand for development services, which has, more or less, never happened since computing became a thing.
Python, and other high level languages made a lot of development much faster, but it never lead to reduced engineering needs. Cloud made deploying services massively easier, and as a result we actually have a lot more people working in infrastructure.
Faster development mostly leads to expanded economic viability for new types of software. The real question is what becomes economically feasible if development costs are halved.
"In 1865, the English economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal use led to the increased consumption of coal in a wide range of industries. He argued that, contrary to common intuition, technological progress could not be relied upon to reduce fuel consumption."
This definitely feels true for tech companies where the prospect of more more productive engineers improves their bottom line. The same sort of companies that have a near infinite appetite for talented engineers.
But there's a lot of coders in industries whose core business isn't technology. Knapheide for example, a truck outfitting company where my brother codes. I'd imagine in those companies, being able to do the same work with fewer engineers and less cost would lead to fewer hires. Technology isn't their core product and they aren't being held back by software.
I actually think we may see the opposite happen with those kinds of companies too.
At the moment, a truck outfitting company building a customer CRM optimized for their workflow is an absurd idea: they would need a team of a dozen developers working for a year before they could even get a feel for if it was a feasible project or not.
Add LLM assistance and maybe a team of three developers could get to an initial working version in three months.
At that point, companies that had previously ruled out custom software development entirely may find that it makes sense for them - growing the demand for software engineers as a whole.
I guess I'm skeptical how much of an impact better software could have on the business success a truck outfitting company? But maybe I'm being overly skeptical. I bet if I really got in the weeds there I'd see tons of opportunities were better/more software could really accelerate things. Thanks for checking my pessimism!
This is what is really interesting. What will they do in 10 years. Will you need to learn mathematics to Phd level to produce code that an LLM cannot produce. Will we all become business analysts (Will AI do that too?). I don't think BA is a step down or up. It is probably interesting I did think of going down that path.
People laugh at coders like we are the only manual loom operators when everyone's job, even PotUS can replaced by the AI we can dream will exist.
My thoughts: buy SPX so you own a sliver of the new overlords.
Now think where we were 5 years ago, and where we will be in the next 5-10 years.
A lot of kids are going to enroll college to study CS, computer engineering, software engineering, etc. - and will not finish their degrees until 3-5 years. They might just find themselves redundant (junior positions, that is)
The only defense of vibe coding I'll make is that LLMs are very good at identifying decent implementations of business logic, such as workflows I may not have otherwise considered or found on StackOverflow. That then becomes a decent starting point for future iteration, but would never trust the "vibe" of the code itself even if that's what all the AI hypesters are doing.
Despite developing LLMs for years I haven't actually used them much in day-to-day work, but asking Claude 3.7 Sonnet my coding questions has been a superior experience to just Googling them (particularly if there are specific functional requirements/constraints)
I feel like a lot of people are forgetting how good llms are at small isolated tasks because of how much better they've gotten at larger tasks. The best experiences I've had with llms all involve sketching out the interfaces for components I need and letting it fill in the implementation. That mentality also rewards choices that lead to good/maintainable code. you give functions good names so the AI knows what to implement. You make the code you ask it to generate as small as possible to minimize the chance of it hallucinating/going off the rails. You stub simple apis for the same reason. And (unsurprisingly) small, well defined functions are extremely testable! Which is a great trait to have for code that you know can very well be wrong.
In time the AI will be good enough design whole applications in this vibe-code-y way... But all of the examples I've seen so far indicate that even the best publicly available models aren't there. It seems like every example I've seen has the developer bickering with the ai about something it just won't get right - often wasting more time than they were slightly more hands on. Until the tech gets over that I'll stick to it being the "junior developer I give a uml diagram to so they can figure out the messy parts".
Vibe Coding is a trigger word for devs who insist it's a pointless exercise because it doesn't do 100% of the job. Devs don't seem to realize that's not the point - the point is you can hire less devs if you're only worried about the remaining 20%.
Currently, AIs emulate a less skilled, junior developer. They can certainly get you up and running, but adding junior developers doesn’t speed up a lot of projects. What we are seeing is people falling into the “mythical man month” trap, where they believe that adding another coding entity will reduce the amount of work humans do, but that isn’t how most projects come out.
To put it simply, it doesn’t matter if AI does 80% of the work if that last 20% takes 5x longer. As long as you need a human in the loop who understands the code, that human is going to have to spend the normal amount of time understanding the problem.
Honestly, I'm not sure if there is any correspondence between an AI and a particular skill level of developer. A junior developer won't know most of the things an AI does; but unlike an AI, they can be held accountable for a particular assignment. I feel like AI is more like "a skilled consultant who doesn't know that much about your situation and refuses to learn more than the bare minimum, but will spend an arbitrary amount of time on self-contained questions or tasks, without checking the output too carefully." Which is exactly as useful yet infuriating as it sounds.
Indeed. My roommate has just been put on a new project at his workplace. No AI involved anywhere. But he inherited a half-done project. Code is even 90% done. But he is spending so much time trying to understand all that existing code, noting down the issues it has which he'll need to fix. It's not just completing the remaining 10%. It's understanding and fixing and partially reworking the existing 90%. Which he has to do, since he'll be responsible for the thing once released. It's approaching a point where just building it from scratch on his own would have been more time efficient.
It seems to me that LLM output creates a similar situation.
Yeah but AI coding does speed up some simple tasks. Sometimes by a lot.
But we have to endure these tedious self-congratulatory "mwa ha well it's still not as good as my code" posts.
No shit. Nobody is saying AI can write a web browser or a compiler or even many far simpler things.
But it can do some very simple things like making basic websites. And sure it gets a lot of stuff wrong and you have to correct it, or fix it yourself. But it's still usually faster than doing everything manually.
This post feels like complaining about cruise control because it isn't level 5 autonomy. Nobody should use it because it doesn't do everything perfectly!
> This post feels like complaining about cruise control because it isn't level 5 autonomy.
It's nothing like that, because cruise control works reliably. There is never a situation where cruise control randomly starts going 90mph or 10mph while I have it set to 60mph. LLMs on the other hand...
This is why I disagree with people who argue (as you did) "it really does speed up simple tasks". No it doesn't, because even for simple tasks I have to check its work every time. In less than the time it takes me to do that, I could've written the code myself. So these tools slow me down, they don't speed me up.
> In less than the time it takes me to do that, I could've written the code myself.
This hasn't been my experience at all. At worst you skim the code and think "nah that's total nonsense, I'll write it myself from scratch", but that only takes a few seconds. So at worst it wastes a few seconds.
Usually though it spits out a load of stuff, which definitely requires fixing up and tweaking, but is usually way faster than doing it all.
Obviously it depends on the domain too. I wouldn't ask it to write a device driver or something UVM or whatever. But a website interface? Sure. "Spawn a process in C and capture its stdout"? Definitely. There's no way you are doing that faster by hand.
Remember that 80% of your time and resources is going to be spent finishing up the last 20% of the project. If the first 80% is borked by LLM code salad, you’re going to need to spend time fixing that code and making it actually work. That might take just as much time, if not more, than only using AI as an assistant (i.e. code completion) instead of the main source of code.
Exactly. I see these threads over and over, and it's just senior devs complaining about how it's the tool's fault, and not that they haven't put the time in to learn the new tool
The cycle of tool and framework re-skilling is constant in industry, and those trying to fight the wave always lose. And this one is a tidal wave. UPDATE YOUR SKILLS FOLKS!
I'm currently 2x to 10x as productive with Cursor. The larger the project, the lower my multiplier.
However, on small tasks and bug fixes, it often fixes the bug before I've even root caused it. It's amazing when I can focus on throwing it information about the bug then have it think in the background while I continue researching. In a surprising number of simpler cases, it one-shots the fix and eliminates any need to root cause (this is a bit easier when it's a feature you understand intimately).
> "Vibe Coding" might get you 80% the way to a functioning concept. But to produce something reliable, secure, and worth spending money on, you’ll need experienced humans to do the hard work not possible with today’s models.
This would have been clear from Karpathy's full statement:
> It's not too bad for throwaway weekend projects, but still quite amusing.
"ever since I started to share how I built my SaaS using Cursor"
random thing are happening,
maxed out usage on api keys,
people bypassing the subscription,
creating random shit on db
as you know
I'm not technical so
this is taking me longer that usual
to figure out
That one is almost a meme on Linked In. For fun I hope it is a long troll (like a long con but for trolling)
And most of linked in (as the algo show me!) is basically this HN post in 100 words or the polar opposite saying how software engineers have had their chips.
Doing something that's not your primary interest is one thing.
Not wanting to learn new things or understand how things work or put in any effort to succeed because you think you can just cheat your way through life is a totally different thing.
And that's what the difference between using AI programming tools responsibly and "vibe coding" is.
Agreed, but you’re your bunching a lot of people into the category of slacker that don’t belong there.
A new tool released that basically lets you design a GUI through guided voice prompts. The 50yr old school teacher can “vibe code” all she wants.
The real problem arises when someone makes false claims they’re a developer when they’re just managing AI generated code. Making it your primary interest and then cheating to make it seem true.
> Or I’m in a different industry and it’s ridiculous to require years of schooling for a skill that’s not my primary interest?
It took me 6 months when I was 10 years old to become technical and create a website. If a 10 years old can do it in 6 months, an adult can do it in 1 month if they work hard.
I think it might be referring to a current lack of experience in programming and debugging.
The situation seems to reflect the issue that Kernighan's Law refers to, which is that debugging code is twice as hard (perhaps more?) as writing it in the first place. I imagine debugging AI-generated code might be even harder.
> ever since I started to share how I built my SaaS using Cursor
> random thing are happening, maxed out usage on api keys, people bypassing the subscription, creating random shit on db
The reference to Claude Plays Pokemon isn't applicable to the discussion of vibe coding, although the suggestion that AI agents can fix the issues with vibe coding is funny in an ironic way given the disproportionate hype around both.
The issues with Claude Plays Pokemon (an overview here: https://arstechnica.com/ai/2025/03/why-anthropics-claude-sti... ) is essentially due to the 200k context window being finite, which is why it has to use an intermediate notepad. In the case of coding assistants like Cursor, the "notepad" is self-documenting with the code itself, sometimes literally with excessive code comments. The functional constraints of code are also more defined both implicitly and optionally explicitly: For Pokemon Red, the 90's game design doesn't often give instructions on where to go for the next objective, which is why the run is effectively over after getting Lt. Surge's badge as the game becomes very nonlinear.
Although, both vibe coding and Claude Plays Pokemon both rely on significant amounts of optimism around the capabilities around LLMs.
Hot take: Vibe coding is going to be the new Excel of technical debt.
Most tech savvy places will avoid it, most good programmers will never encounter it. A bunch or us will make a career out of fixing the mess it makes after it explodes.
My first real job was doing just that at a broker trader which lost 10m on a trade made by an Excel spreadsheet that used a stale yahoo finance API to get exchange rates.
At this point in time, we're following the time corporate got on the outsourcing craze step for step. It had all the hype, hands off, cheaper for the same work, faster to market, every other argument you've all certainly heard. Then the reality hit. The whole discussion around LLM coding agents feels indistinguishable.
My first job in the industry was cleaning up a large codebase created overseas by indian developers. Maybe the new kids today will break into the industry by cleaning up messes that have been generated by AI.
Nah, the magic/promise of AI is that it has positive chance of getting there, so you can keep feeding it dollars until it eventually gets you the thing you want, and that it's still cheaper than having people do it the old-school way.
We're not there yet, but I don't see anything preventing us from getting there in ~5 years.
(Remember: 5 years ago, SOTA in this space was letting a genetic algorithm poke at an AST and hopefully maybe arrive at a trivial program solving a small algorithmic problem.)
I wouldn't bet against it. Self-driving tech benefits directly from the outputs of sudden and continued growth of R&D in AI, fueled by hype-driven investments.
Maybe just like with self-driving cars, trying to hook mechanical precision up to messy human society is going to be fraught and lead to blowback. Meaning that once planes start falling out of the sky from vibe coding Boeing contractors there will be PR and regulatory panics that soften the hype somewhat. Or, the next time Equifax gets mass leaked and they blame their security setup on generative AI. You can’t vibe code your way out of human stupidity and the consequences of production environments.
Maybe, but the same thing could be said about JavaScript and webshit and the world is still there. We can just continue to not use YOLO technologies and culture in safety-critical applications.
Even at its current size, the software outsourcing business is multiple orders of magnitude smaller than the software business itself. While there's money to be made, clearly the hype didn't live up to even remotely what it promised to be.
The market can stay irrational for longer than you can stay solvent.
This is not to say outsourcing can't ever work, but the situations where it does work are much rarer than what every outsourcing vendor would like you to believe.
I bet a previous client's attempt at outsourcing (well into the 6 figures now) is included in that number... yet the expensive onshore devs outsourcing was supposed to replace are still there 2 years later except now they have to also babysit the offshore idiots and fix their messes.
But hey, the vendor got paid, the idiot executive who fell for their pitch wouldn't want to lose face, so it all gets handwaved away as a continuing success and more money gets thrown into the dumpster fire.
FWIW, if you believe that long-term, the market is a good optimizing engine (I think it's a very reasonable and well-proven belief), then this is just a matter of time before things sort themselves out.
The need for companies to get more value out of less spend won't disappear, nor will the comparative advantage of companies in lower CoL areas of the globe. That's two fundamental incentives on both sides that are aligned, driving the market to find the lowest-energy path from here to there. It'll get there, even if it ends up looking strange (like, idk., maybe cutting out management intermediaries but involving a middleman acting as insurance).
That is, if LLMs won't leapfrog it all and end software dev outsourcing before it started to work well.
In my experience, I started my career 15 years ago cleaning up codebases developed by cheap outsourced developers. They were an absolute mess. Today, I work with many very talented developers overseas. People who develop code at my level of quality and above (and I am a stickler for high quality, maintainable code).
The thing is how you research, what you expect to get out of it, and what you're willing to pay. There was absolutely a gold rush on bottom-dollar development by cheap overseas developers by management who had no idea how software really worked, and thought they could build a business on cheap offshore development. These were software farms staffed by unappreciated undertrained people from diploma mills. I saw truly shocking things. I saw code written entirely with gotos instead of loops, because the developer had never learned how to write a while loop. The companies spent way more in the long run trying to iterate, ask for changes, and ultimately having to hire higher quality talent for much more money.
I agree with the GP. The LLMs will get better, maybe people will learn that you need an LLM with a skilled developer, or maybe the agents will get good enough to fully drive themselves properly, or maybe just good enough that a non-technical pilot can get good work out of them. Right now, "vibe coding" is largely non-technical people making messy, unmaintainable, insecure code. Some of these are programmers and non-programmers just playing around, but some people are trying to build money-making businesses off this, and it does feel like a very similar situation.
My father never dissuaded me from the computer science degree I went for (starting in 2007), but later on in life, he told me that, at the time, he was worried about my choice because outsourcing was all the rage and everyone was saying there’d be no programming work in the states-that it was all going to be done in India.
And who cares if it is true? So far programming is one of very few professions when person can set themselves for life in a relatively short period of time. When / if it is gone there will be something else. I have few friends who'd switched to be a handyman. They are doing great from what I see.
> So far programming is one of very few professions when person can set themselves for life in a relatively short period of time.
If you specifically optimize for it. Most people don't - they specialize and expect to be in their line of work for decades.
> When / if it is gone there will be something else.
There will be something else for young people who are just starting. If you're 20 years into a career and then your line of work disappears overnight, of course you can switch to something else - and enjoy your entry-level salary while competing for jobs with people who are 20+ years younger than you and have no meaningful costs or obligations yet.
Also, on what you're optimizing for. If, like many, you're looking for a job that makes sense, for instance (e.g. working to develop technologies or research that you think can change the world for the better), you're probably never going to strike that particular gold.
I think that's a great point. There is a place for outsourcing. Some projects and organizations are well suited for it. Some projects end up only using outsourcing at supplementing some parts of the work. Some can't do it for quality or compliance reasons.
I think we will see something similar with LLMs. There will be areas where it will deliver cheaper and faster. There will be areas where it will deliver nothing but disaster. It'll change the industry but not eat it alive. The folks talking about fully autonomous coding on the near horizon are dreaming.
I’ve seen a number of outsourcing project failures. The two things they all had in common were that the organizations in question were terrible at managing projects but they blamed the developers for management’s inability to plan or make decisions, and they were trying for unrealistic savings – it wasn’t enough to save 30-50% on salary, they wanted 90% even if that was below the market rate for those skills even in India.
The first one is definitely happening with the LLM bubble where companies really want to pretend that the hard part of the job isn’t understanding what to build and how to do so maintainability.
The second one is going to be more interesting: I expect LLMs to put downward pressure on wages in a lot of places but also for smarter companies to realize that nothing short of true AGI is going to replace the need for people who can actually understand what the customer needs. If I’m right, this will swing the pendulum back towards specialists again – the seagull guys who come in, declare that their favorite framework will solve everything, and leave are more vulnerable to being replaced by an LLM than someone who knows how to code but is also bringing actual business-relevant experience and judgement which an LLM can’t have.
> the seagull guys who come in, declare that their favorite framework will solve everything, and leave are more vulnerable to being replaced by an LLM than someone who knows how to code but is also bringing actual business-relevant experience and judgement which an LLM can’t have.
But that's just a continuous variant of the discrete-sounding claim that programming will get eaten by AI soon. After all, the "actual business-relevant experience and judgement which an LLM can’t have" is mostly not related to programming - and the better LLMs get at coding, the less value will the programming parts of the skillset have; take it to the limit, and it's just saying the managers and sales people will stay, while software developers will be gone.
I think that’s a question of how you define jobs. For example, I’ve worked with very few managers who could document their business processes in sufficient detail to build an app. Now, is the person who does a business analyst, architect, senior developer, etc.? Who sits down with the users, gets feedback, but understands the needs of multiple parties well enough to tell which points are traps, which should be developed in a different direction, etc.?
Basically, I’m saying people should stop expecting to get six figures for being able to run create-react-app and deploy a container. The analytical and social parts of the job are where I predict LLMs to make fewer inroads because they require non-generic understanding.
> I’m saying people should stop expecting to get six figures for being able to run create-react-app and deploy a container. The analytical and social parts of the job are where I predict LLMs to make fewer inroads because they require non-generic understanding.
That's a fair take. I do wonder though, how much will those "analytical and social parts of the job" be paying - I imagine you might no longer get six figures for that either, because high tech salaries are fueled by absurd growth of the industry, which manifests in a large part in software that's basically just {framework du jour + basic-level CRUD, that hasn't changed much in 30 years + branding}, and that kind of software I expect to get eaten by LLMs entirely.
Even with cookie-cutter app coders out of the way, the remaining software engineers might see the number of jobs implode, crashing salaries for some time, until (maybe) the growth restarts around new kinds of software, kinds that'll be in high demand and not something that can be made by a few "analytical/social" people herding LLMs. I'd normally say this won't happen, but rather that the software economy will slow down, stabilize, and get boring like everything else - but then, so much of software is driven purely by advertising, and advertising is a negative sum game, so surely they'll invent more bullshit jobs for us.
Yeah, I’m really not sure either with the general backdrop of looming American disinvestment and the entire world reconsidering reliance on American companies. I don’t think reversing the trend of consolidation is going to be enough to balance it out.
It's about those agents being (mis)used in the very specific blind faith approach of "vibe coding", not least due to the hype merchants and grifters picking up the phrase and running with it shorn of the original cautionary notes about it being useful for bringing a bit of fun back into non-serious coding.
Criticizing the idea (and conflating it with the wider field of LLM coding agents) without understanding that original context is not really any better.
Vibe-coding <> LLM coding agents, which - when used properly - are brilliant for use in serious code and are here to stay.
The reality in which people like me get to do work for US/UK for 4x the salary relative to equivalent work locally, and some of this work is actually cleaning up after folks elsewhere, who being cheapest labor available still got 4x their local salary for this work, and the total is still 4x cheaper than what the US/UK company would pay locally? :).
(I'm only half-joking; in a previous life, I worked on a project with this exact development history.)
The outsourcing market is alive and kicking, and offers a whole spectrum of quality and price. The more to the east of US you are, the easier it is to see :).
> The whole discussion around LLM coding agents feels indistinguishable.
Nah, the difference here is, in outsourcing-to-LLMs scenario, there are no people who do the work and benefit from favorable salary/costs-of-living ratio.
The company I worked for 15 years ago outsourced QA to save money. It was sold as paying $15 for a 4080 video card. When they opened the package, instead of a 4080, it was a brick. The salt in the wound was when they realized they overpaid 3x for a $5 brick. If it wasn't for vendor lock-in (they being the vendor), they would be dead.
The local QA person could run through 100 or so scenarios a day. The offshore people could do 2 a day. They never improved. The offshore people who are tops aren't cheap.
There's an art to outsourcing, and - even worse than with LLMs - it's not something you can ever just do and forget, because without active management, you'll eventually end up wasting money and time while getting nothing in return.
QA is a whole other story, too. Outsourcing QA is stupid, but even more stupid and short-sighted is not having QA in the first place, and that unfortunately is becoming a norm.
There's lots of false economy going with jobs, too. Getting rid of QA may save you salaries, but the work doesn't disappear - it just gets dumped on everyone else, and now you're distracting much more expensive engineers (software or otherwise), who do a much worse job at it (not being dedicated specialists) and cost more. On the net, I doubt it's ever saving companies any money, but the positives are easy to count, while negatives are diffused and hard to track beyond overall feeling that "somehow, everything takes longer than it should, and comes out worse than it should, who knows why?".
>Outsourcing QA is stupid, but even more stupid and short-sighted is not having QA in the first place, and that unfortunately is becoming a norm.
Yes, they were moving in that direction. They centralized the QA team over a suite of probably 15 products, which means no one has any expertise. The QA VP would get mad when QA found bugs because "the dev's were supposed to find all the bugs and the QA was just supposed to just certify the release." The amount of people who don't understand how software dev works in high positions is mind boggling.
They ended up firing all the devs except me and this other guy who gave zero shits and wanted to be a manager. "We" maintained 3 products. Two were pretty standard web apps but one was a full blown decision support system (rules engine) that only I knew. I quit after a few months of killing myself. They paid me a whole lot of money a few years later when they were trying to add features to get a very lucrative government contract.
> It had all the hype, hands off, cheaper for the same work, faster to market, every other argument you've all certainly heard.
Like some of the other responses, I'm baffled by your comment. Have you not seen what's happened in the past 5 years or so?
Yes, there was an outsourcing craze to India after the .com bubble burst in the early 00s that largely failed - the timezone, cultural differences, and lack of good infrastructure support made it fail.
The past 2 companies I've worked for offshored the majority of their software engineering work, and there was no quality difference compared to American devs. The offshore locations were Latin America and Europe, so plenty of timezone overlap. The companies are fully remote, so what difference does it make if the dev is in your same city or a thousand miles away?
I think offshoring has absolutely put downward pressure on US dev salaries in the past couple years.
I think you're talking about a different phenomenon, having remote mixed teams is IMHO different from offshoring.
There's at least the crucial difference that you had devs in both western countries and traditional "third world", where the 90s view of offshoring was throwing whole processes abroad and only keep "heads" in-house while the remote teams/companies would deal with all the execution, making it inherently difficult to deal with production monitoring.
PS: to your point offshoring to India has become more common but Indian companies are also not that cheap, so we're past the initial framework. Perhaps the same way outsourcing production to China used to be about sweatshops, when it can now be about unrivaled expertise at a cost.
> For now, they are worth evaluating and discussing, but are not ready for us to delegate the precise task of creating reliable, secure, and scalable software that powers our society.
The good thing about vive coding is it avoids the software development lifecycle completely from the user perspective in a platform that has an integrated SDLC which means from defining idea to ensure visibility in changes to a runtime where the user can see it. In my mind, modifying without a hassle in a controlled environment is what users look for. Software development assisted by AI will be a thing for engineers but Vive coding is aimed for users outside of engineering.
I sadly see only a handful of companies being able to pull this off.
The thing is the SDLC exists to harden software to a point where you can run a business on it. It didn't appear because people were bored. This feels more like a comparison to a Figma or other prototyping tool than something that can produce quality software.
I hate how what is effectively a stupid meme phrase became an actual term in a few days.
> "Vibe Coding" might get you 80% the way to a functioning concept. But to produce something reliable, secure, and worth spending money on, you’ll need experienced humans to do the hard work not possible with today’s models.
The problem is that 80% of the job is a proof of concept at best. 80% is effectively a QA walking into a bar[1].
And that's not even getting into the class of testers which try to order ';--drop table beers;-- beers, <script>alert(1)</script> beers or <![ENTITY q1 "&q0;"><![ENTITY q2 "&q1;&q1;&q1;">&q2; style beers
Makes me wonder how organic or astroturfed the name is. That a bunch of influencers all started using it at the same time makes me think someone is pushing it, perhaps because a focus group (or LLM) decided 'vibe' was a warm and fuzzy way of pushing the latest iteration of 'move fast and break things'.
80% mark means you just finished the happy flow and written 30% of the code bases. Now you need to handle the unhappy parts and need to write extra test code for covering all those edge cases.
Precisely, now you need to finish off the remaining 70%, which is where most of the work that is required truly lies, with or without all the AI bollocks. Whether it takes 2 or 8 days of work to get those 30% done, it's not much of a difference if you need several months(or in some cases years) to get a project to a tolerable "production" state. I'd much rather spend 8, as opposed to an AI-generated codebase which will shoot itself in the head because someone scrolled over it and thought "lgtm".
The alternative to using AI to generate 80% of the project (30% of the code) isn't much better: coding the initial 30%, which is also a challenge (from 0 to 1).
So there is still a productivity gain for senior developers.
> There's a trend on social media where many repeat Andrej Karpathy's words: "give in to the vibes, embrace exponentials, and forget that the code even exists." This belief — like many flawed takes humanity holds — comes from laziness, inexperience, and self-deluding imagination.
I'm going to go ahead and give the author the benefit of the doubt that they aren't literally saying Andrej Karpathy is "lazy and inexperienced", because that claim is obviously absurd.
In general though, I think the author is missing the actual point Karpathy was making! Let's look at his detailed criticisms for the typescript agent run, for example:
> Regularly clones TypeScript interfaces instead of exporting the original and importing it.
> Reinvents components all the time with the same structure without searching the code base for an existing copy of that component.
These are only problems for human codebases. You're not vibing if you are expecting agents to write code the way humans would.
Duplicating interfaces and implementations is inefficient, and would be a nightmare, in a human codebase. But, the code will still work! So if an AI agent is managing the codebase, who cares if it duplicates things all the time?
Maybe it'll see that it did that later and decide to consolidate things, maybe it won't. It doesn't affect the actual outcome of the code, unless you actually look at the code as a human, which is not "vibe coding."
> When told to fix styles with precise details, it will alter the wrong component entirely.
> When told specifically where there are many duplicated components and instructed to refactor, will only refactor the first instance of that component in the file instead of all instances in all files.
> When told to refactor code, fails to search for the breaks it caused even when told to do so.
You're thinking about the code again, gotta stop doing that if you actually want to ~vibe code~. Refactoring code isn't a thing when you're vibe coding, English is your programming language now, the Typescript (or w/e language) is the assembly. You wouldn't spend much time observing the assembly output of your compiler (especially for web dev), so why are you observing the code output of your agent?
If you don't want to vibe code, that's fine, nobody is forcing you to. But if you're going to do it, grade it on the metric that Andrej was actually claiming: that you can get working results on a lot of software projects today by telling coding agents to make some code do something, and then just keep running it with "fix this bug" until it works, and it'll often get to a working result.
He never claimed that the code outputted would be beautiful, from a human perspective, or well formatted, or well architected, or efficient.
And some circles hand wave away all criticism of any new thing as luddism.
This article is a bit more balanced, though, and clearly isn't criticising use of AI in programming, but specifically the "Jesus take the wheel" style of vibe coding. It's the same old "if you write code as cleverly as you possibly can, you are not smart enough to debug it", but to the next level, where people are writing code that they aren't even smart enough to read.
I mean ... most code out there is pretty bad, so LLM assistants contributing pretty bad code just keeps the mean where it is. And obviously it has to be, how can anybody expect an LLM to produce output with quality that's higher than its training input? Expecting that is appealing to magic or some consciousness that doesn't actually exist or just plain anthropomorphising.
If you are working at a place where that quality level is standard -- and let's face it, a large number of companies produce average or below-average quality code (by definition) -- then using an LLM assistant isn't that bad. At least if such an assistant doesn't have some extra flaws beyond producing the best summary of its training data, which is exactly what an LLM does. It actually justifiably replaces developers in such an average-or-below place. But if you are aiming for the top end of the quality scale then there is no way this can be achieved by LLM output. Purely on principle.
This shouldn't even be a controversial opinion. I'm quite surprised every time this is questioned or even just debated.
"Bad" is doing s lot of work in your sentence. Do you mean slow? Or buggy? Or unmaintainable? Or unextendable? Uses patterns the tech lead hates? Hard to read? High cyclomatic complexity? Doesn't meet requirements? Security issues? Uses out of date libraries? Too much reliance on 3rd party code? Too much NIH? ...
I think "one shot ready for production code" is what AI cannot do yet. Which is why I am not worried for another 12 months at least :)
I wrote this because I was worried that "vibe coding" was being misinterpreted to mean "any time an LLM outputs code", as opposed to the intended definition of code where you deliberately don't review the code and see how far you can get.
Judging by the comments, most people couldn't even tell it was satire, which goes to show how absurd the hype is right now (and probably why it was buried).
He works for a company who tries to sell coding agents. He's absolutely trying to pump it up and induce FOMO. If you can't see that because he hides it behind a layer of humor, that's on you.
You can tell this claim is false, because that level of productivity increase would be glaringly obvious to an outside observer; it wouldn't need to be self-reported.
A YC summer batch is 84 days culminating in Demo Day. So a 100x speed improvement would be like a team spending less than 1 day of coding and ending up with something that's on par with Demo Day in terms of functionality. Maybe the design would be wrong, but that wrong design would be just as fully-featured as a Demo Day app.
So if 100x were true, the partners in that video would be talking about how the new batch dynamic is "They get breakfast with a customer, learn something new, have an epiphany, and then later the same day they have their entire app rewritten based on what they learned, and that scratch-rewrite is already at a Demo Day level of functionality." The partners aren't talking about that dynamic because it's not happening. So clearly the self-reported 100x is inaccurate.
Even 10x would result in partners saying "Whoa, in this batch people have a Demo Day-quality app in production by the end of week 1 instead of week 12." The partners have a huge sample size on how much teams get done in what time period, so it would be glaringly obvious to them if this batch were shipping 10x as fast as previous batches.
That external observation would be the headline if it were what the partners were actually seeing. Since that's not the headline, it's clearly not what they're seeing, so 10x can't be the number either.
To be fair if your benchmark is against demo day, at some point Amdahl's law kicks in regardless of how many multiples you have on engineering. Not sure if I believe the multiple of 10x or 100x anyway, but a better metric is “number of customer feedback loops” is a better metric than “can complete one (1) demo day in X time”. My (non YC) impression is that people are hitting more loops.
Also multiples “up” versus “down” are not symmetric. Airplanes are around 10x faster than cars, but that doesn’t mean I’ll be getting to work in 60 seconds.
If you can't do something extremely impressive with the equivalent of hundreds worth of full time engineers then there is something wrong with you as a founder.
Note that real engineers helps you come up with new features and test your product and all that and not just add code, adding code was never a bottleneck on just about any problem ever.
So Amdahl's law applies in terms of the time to add code, not in terms of engineers, they don't do the work of 100 engineers, at best they take 100x less time to add lines of code when they know what they wanna make. But that isn't particularly game changing, as adding code is not the hard or even time consuming part.
I see your problem (at least according to Yegge's theory): the batch applicants are just too senior. If they were more junior, only then would they benefit from the 100x multiplier. The olds are just too far removed from the enlightened way, you see
If you believe in vibe coding, surely you are holding a massive short position in every major software company, no? I mean, surely, any day now, a bored student will vibe code a full replacement for a major software package and destroy the income of the SW giants one by one, right?
Wake me up when someone vibe codes a Chrome replacement, or an iOS replacement, or MS Office...
Except we know this won't happen anytime soon because we all know vibe coding isn't very useful beyond toy projects that leverage complex libraries written by actual developers.
I'll share a new wrinkle that casts more shade on the coding LLMs.
We have a fair number of offshore resources that are used for dev. They developers are fully integrated into the team, are in all the stand-ups, and substitute for the usual role of junior programmers. They don't get the grunt-work shoveled on them, they get the same work as everyone else, they're just expected to not be as fast.
In 6 months 2 out of 4 of them been sacked, and surprise, not because we could replace their work with LLM output, but because their use of LLMs was so unrestrained and scattershot the pull requests they submitted had become nightmares. One thing mentioned in the article about unit test creation was something we saw as well. Perhaps this is partly due to working an existing code base where the LLM loses some of its advantage, and certainly some of it was cultural in that progress was thought more important than actual manageable code. The two sacked fellows where told, literally, from my own mouth, multiple times, "You cannot just ask Copilot to write you code, paste the entire thing into Visual Studio with no thought of what has changed, with the end goal of just compiling and meeting the single set of acceptance criteria on your story. You're breaking other things and introducing bugs." It went on deaf ears, and now they're gone. They were nice people, I didn't know how to get through to them, but they were convinced the LLMs were the way to go.
I use LLMs to help write code every day, and I wouldn't want to be without it, but I'm fairly surgical about it. Most of the time Copilot gives you a page of say, React code, or EF Core queries, you have to be really careful about anything you didn't explicitly ask for. Honestly, there is a time savings, but there is not a quality increase. The benefit is subverted by the time it takes to figure out how to ask correctly, the time to vet the output, and the time to fix the little tiny insidious bugs it can introduce.
So, don't go vibe coding and lose your job, is something to think about. I have to admit that it has worn me down meeting these interesting people from far-flung locations only to watch them flounder and get let go.
I've been contracting for a fairly largish company (around 300 devs split across ~40 teams). The US based company was bought out by private equity about a year ago and many senior/lead engineers were forced out and contracted out to cheaper overseas labor.
The company has been relatively ambivalent about the usage of code assistant AI, but during PR reviews it has become very apparent that its seen widespread adoption among the outsourced dev teams purely because of code duplication. Our company has a fairly large number of repositories and bespoke libs for utility type functionality.
In the past, a programmer might have internally said to themselves, "There's no way that somebody hasn't already written this stupid function X or method Y", and they'd take a few minutes to search or reach out to see if it exists within an organization.
Instead during some of the recent code reviews, there has been a huge uptick in core functionality that is very obviously being spit out by the LLM. At best its just extra unnecessary code. At worst it will introduce new bugs since our custom functions often handle business domain specific edge cases that an LLM simply wouldn't know about.
Totally lines up with my experience as well. We also have the opposite problem of reams of code generated years ago from a period of unsupervised offshore work where we're slowly paying down the debt but the LLMs will attempt to use the old code for new work. Most of it is spaghetti UI code and nearly impossible to reuse effectively but the LLMs give it their best and we have prompt around it.
BTW, Copilot is not the best at coding. With the quality LLM return exponentially grows. Bigger chunks, fewer bugs, less time checking. From my experience LLMs do not impress on complex algorithms and shine on small utilities. They can use libs I even don't want to learn about.
I haven't really noticed that myself. I go "LLM shopping" fairly frequently trying to find which one of the few I'm paying for gives the best result for the current problem. They all seem to have their shortfalls, although I will say Claude is better for Greenfield work.
Well, probably you can try to go down to simpler models to get the idea. (they are almost useless) From my experience better model like Claude or o3 can do things that others simply cannot. At some complexity they start going circles making wrong decisions, forgetting things that are still in context window. But the thing is those complex tasks are usually the most interesting and important.
I think people miss that "vibe coding" is a senior engineering tool. You still have to architect the project. You still have to ensure security and performance are handled (if relevant for the task). You still have to envision edge cases and usage patterns. You just don't have to type it out.
Now non-programmers can fumble forward to a working demo. But junior engineers are walking around with a loaded weapon - if they are not learning from how AI solves a problem or using it like StackOverflow to answer specific questions, they are blowing up their own careers.
The future is we are all product engineers or domain experts. No one is going to want an army of React engineers in 2 years.
I've been messing with this for a few days now so I'm not going to claim to be any sort of expert but as someone who has been coding for more than 20 years I do appreciate the set it and forget it nature of being able to throw q developer or whatever at a relatively simple problem that I'm curious about and let it crank away for half an hour while i'm working on something else. I've tried it on a couple of reasonably small and well defined problems, mainly focusing on python, and it works surprisingly well. It'll run the scripts and fix errors and can suggest prompt improvements. I've also tried it in a large codebase with much less success, so YMMV.
Also it is important to be able to review the code because it could be the case that it looks mostly correct but has some subtle errors in it that can mislead you. For example I was trying a couple of different ways of computing some indices that have a bunch of variables and one way had a mask that made no sense involved. "Vibe coding" without being able to check the work of an LLM is almost certain to go poorly, IOW.
> Cursor has some sort of "concise mode" (archived) that they'll turn on when there is high load where the model will still be rated at the normal price but behaves in a useless manner. This mode will omit details, drop important findings, and corrupt the output that is being produced.
This is a real problem that I have experienced on and off. It's getting to the point where everyone on my team is actively looking for alternatives. Generally, I've found Cursor works correctly after business hours. But, it's increasingly giving absolutely useless responses during business hours.
-----
That being said, I agree with many of the author's observations. However, for me, it's not really a breaker. It's not much different than working with an intern or junior engineer. If you ask them to do too much all at once, they come up with bad solutions. Plus, they have a tendency to make "dumb" decisions.
For me, I've found solutions for nearly all of the listed issue. Much of it comes down to being diligent during code review (like you should). For example, the Typescript issue, I come back later to have it fix it.
Specs are the one that still baffles me. It's absolutely terrible at writing proper specs. In particular, it falls into a really bad cycle whenever there are errors. I don't have a solution for this one.
> Generally, I've found Cursor works correctly after business hours.
Interestingly the times I've experienced the most weirdness were during extremely not normal business hours (from the California perspective). For 3 nights in a row last week, I found myself coding at/after 2:30am during what were apparently periods of excessive load on Claude Sonnet. When asking Cursor to do things, it would fail, tell me about the high load, and encourage me to try again soon. Well, I just kept clicking the button over and over again, thinking it would eventually be able to handle the request properly, and otherwise continue presenting the error. Not the case!
Incorrect/hilarious things Cursor/Claude did at points during those nights:
- repeat the inquiry back to me in full, then do nothing at all after that
- confidently assert it had located the bug I was looking for, then direct me towards the entire codebase
- assert that it had done what I asked, and request that I approve the changes it wanted to make to my code, which were... nothing, none whatsoever
- (possibly the most hilarious) begin to answer questions in borderline leetspeak, randomly substituting numbers in place of letters in words, before eventually devolving into total gibberish
Mostly just annoying due to the wasted time, though it's possible the entertainment value negated it. I don't expect miracles from Cursor to begin with, nor do I give it wide latitude to change very much in my projects, so the risk of damage wasn't really any worse then than at any other time. Of course, I am not a team working against deadlines on critical projects, just a guy screwing around at 2:30am.
Not to mention the fact that those training clusters are not going to supervise themselves (or, maybe I just think that because I haven't had enough koolaid; where's the AWS Console MCP endpoint?)
My, very limited experience with LLM assisted coding is that it depends...
For basic frameworks done in something like Python it is very good, but not perfect, yet. But the iteration cycle to get to where you want to be is still faster than doing the whole job manually and I see this as a big win.
For more esoteric fast changing languages/frameworks it has me chasing my tail in a chain of code updates where each fix breaks something in the n-1th, or n-2th version. Sometimes it's deprecated code, or it halucinates functions that would be valid if your were using a a different language of framework. And sometimes simple coding errors.
But it will get better, a lot better.
The main benefit is that it will let a invested non programmer client build a functional framework prototype and then combine that with a list missing features that a more skilled programmer can flesh out to a first cut solution.
For the first time we 'might' get better requirements with an actual working model instead of having the implementor doing most of the requirements as a first pass from a high level hand wavy requirement. I think we're going to see some amazing tools for this.
What I don't see it doing is creating original algorithms to solve things being done for the first time.
I see statements like this a lot when talking about AI in general. People seem to think it is a foregone conclusion that no limit to LLM model improvement and capability exists. What causes you to believe this and what evidence do you have to back it up?
Because compared to a year ago, it's much better. Compared to two years ago, it almost didn't exist. Compared to three years ago, nobody was actually talking about it.
Like I get the jokes, and I totally agree that they won’t totally replace the humans. But come on, the way an average coder writes anything nowadays has dramatically changed. Especially for web and app stuff. I’ve onboarded some junior/mid-level engineers recently, and it’s such a different experience compared to 5 years ago.
Really? Opinion, based on the fact that there are basic improvements that can be implemented on what we have now, using the skills that we have now. If you don't agree, that's ok.
Now, about your comprehension skills, where is there any mention on my part of there being 'no limit'? In fact I go as far as to speculate on at least one.
311 comments
[ 3.6 ms ] story [ 291 ms ] threadIn the right contexts, I find LLMs can speed up my work a lot. But it's nowhere close to being able to replace what I do.
Devs are just coping so hard around LLMs its hard to watch. OTOH the few engineers who have embraced it are excelling.
Totally believable bro
> I've replaced a product team which had 9 devs 2 years ago with 2 devs with AI
Sure but is everything else the same after that? I doubt it.
We just didn't need them anymore because LLMs and tools like cursor are insanely good.
Our code is better and more robust than it's ever been. Our rate of user-reported bugs have dropped more than 50% since we started "vibe" coding 6-ish months ago.
Product people love the idea of being able to fire their dev teams, but I'm not sure they understand the implications (some of wich may not become clear for years).
It's interesting that you describe yourself as a developer now.
Because just three months ago, in your first post [1] to HN, you said:
> I'm somewhat non-technical but I've been using Claude to hack MVPs together for months now.
Sure: you might feel as though you have now 10x'ed yourself. But, quite honestly, when the reality is that just a few months back you self-described as "somewhat non-technical", it's clear that (a) you're at such an early stage in your learning and understanding of tech, as a developer, that it's relatively easy to experience bigs gains, and (b) you can't actually have much of an objective measure on this, because you are in fact quite new to the field.
I read a lot of your other comments. To me, even before I had confirmation that you were actually "somewhat non-technical", and fairly new to the field — effectively a junior developer by any real measure — this was already quite apparent to me.
Based upon having been a developer for some decades myself already: I can generally spot those that talk-the-talk — and similarly: I can generally spot those who have non-trivial / deeper experience with various fields of tech.
Powering-up with AI tooling doesn't remedy that. Even if it might seem otherwise from your "somewhat non-technical"-but-newly-empowered position.
Good luck with your coding endeavours though, and with your evangelism.
I have no doubts at all that the world is changing — including how software is developed. But I see your posts for what they are.
[1] https://news.ycombinator.com/item?id=42423573
But that’s why I call it out: yes, exactly, it degrades the conversation when someone is preaching about a new tech, and how it’s gonna change development, and claiming they’re a developer themselves - while not being upfront about the fact that they’ve not actually got much real-world experience as a developer at all in general.
And this kind of thing should always be called out when spotted. It’s just plain disingenuous at the end of the day.
I’ve probably been contracted to fix more broken projects (by devs who royally messed up), than the count of MVPs this person has made, or indeed the number of months they’ve been coding.
But at the end of the day, these kinds of folk simply make us more experienced folk more valuable to those that need a professional service in a bail-out scenario. I’ve got decades of real-world coding experience, and a healthy list of successfully published / deployed projects, including some fairly big clients over the years. My CV speaks volumes, particularly when contrast against someone with little experience in the field of software development. I’ve seen languages and tooling come and go. I’ve headed teams and worked solo. I’ve witnessed plenty of folk like this in my time. It’s certainly not my first rodeo!
Unfortunate that someone chose to downvote me, as opposed to engaging me in conversation as to why my view might perhaps be incorrect or maybe shortsighted - as per the HN guidelines. But no real surprise - I guess that in itself is quite telling here.
Karma points might come and go sometimes, but whatever: I’ve been posting on HN (and other sites) for years, on and off. I’ve no need to try and portray myself as something I’m not, nor portray myself to have skills or experience that I don’t have. I generally post to share my knowledge and experience, because real-world experience adds up over time.
you've been a developer for some decades which is why your reality is threatened that your craft is increasingly becoming irrelevant so you had to snoop my profile to find some confirmation that your reality doesn't get shattered
this is nothing new of course. obnoxious neckbeard engineers who don't understand where the world is going have existed since the unix debates on irc. you'll find plenty of people who agree with you on mastodon lol.
Plenty of room for you to 10x many times over then.
Over the years, I’ve met plenty of folk who have dabbled with software development, before deciding it wasn’t for them - then pivoting to something less technical.
Nah, I don’t feel threatened at all by AI. My job is secure. Tools change, sure. But there’s plenty of years left in software development for sufficiently skilled humans. No matter what a junior-level dev / AI evangelist might claim.
I’ll be cleaning up and properly re-implementing the MVPs that less knowledgeable folk are throwing together, slap dash. For a long while yet. And doing other stuff that AI simply can’t do properly - and quite honestly is quite far from doing.
Your rhetoric betrays your knowledge, and your bravado and insults can’t make up for that in any way.
It’s easy to get enchanted by current generative AI, and believe it far more capable than it is. Particularly if not overly skilled in whatever domain. Particularly if one doesn’t have much of a grasp on how generative AI actually works. Good luck with that.
Hahaha - no, that's really not accurate at all. On lots of levels. The ability to read another user's comments is there so that anyone who chooses can actually get a better understanding of who they're talking with, and what that person is about. One doesn't have to feel threatened at all to want to use it, one simply has to be intellectually curious, and interested to find out more...
There's no need to try and portray it as a negative, and make out there's something afoot which isn't actually taking place.
Anyone who's been here on HN for any significant amount of time knows exactly what that feature is for — as well as when it might be best to use it. And people absolutely will use it.
It helps separate the wheat from the chaff.
— Please do try and take care that your wide-of-the-mark unnecessary put-downs and name calling don't violate the HN guidelines! (Just for your own good!)
it's ok, all craftsmen who got automated away once thought they were special. you're not the first you won't be the last. you will likely be unemployed soon though.
So why wouldn't you keep them? If you're able to produce even more with AI enabled engineers, why downsize? To me, it sounds like a startup's dream to be able to output more without increasing headcount.
https://news.ycombinator.com/item?id=43449975
I could certainly see a possible reduction in engineering team size, but going from 9 to 2 makes me question how much of that reduction was a result of over-hiring in the first place.
That's such a economical fallacy that I'd expect the HN crowd to have understood this ages ago.
Compare the average productivity of somebody working in a car factory 80 years ago with somebody today. How many person-hours did it take then and how many does it take today to manufacture a car? Did the number of jobs between then and now shrink by that factor? To the contrary. The car industry had an incredible boom.
Efficiency increase does not imply job loss since the market size is not static. If cost is reduced then things are suddenly viable which weren't before and market size can explode. In the end you can end up with more jobs. Not always, obviously, but there are more examples than you can count which show that.
But let's assume you have true, fully general AI. Further assume that it can do human-level cognition for $2/hour, and it's roughly as smart as a Stanford grad.
So once the AI takes your job, it goes on to take your new job, and the job after that, and the job after that. It is smarter and cheaper than the average human, after all.
This scenario goes one of three ways, depending on who controls the AI:
1. We all become fabulously wealthy and no longer need to work at all. (I have trouble visualizing exactly how we get this outcome.)
2. A handful of billionaires and politicians control the AI. They don't need the rest of us.
3. The AI controls itself, in which case most economic benefits and power go to the AI.
The last historical analog of this was the Neanderthals, who were unable (for whatever reason) to compete with humans.
So the most important question is, how close actually are we to this scenario? Is impossible? A century away? Or something that will happen in the next decade?
Very strong assumption and very narrow setting that is one of the counter examples.
AI researchers in the 80s already told you that AI is around the corner in the next 5 years. Didn't happen. I wouldn't hold my breath this time either.
"AI" is a misnomer. LLMs are not "intelligence". They are a lossy compression algorithm of everything that was put into their training set. Pretty good at that, but that's essentially it.
Python, and other high level languages made a lot of development much faster, but it never lead to reduced engineering needs. Cloud made deploying services massively easier, and as a result we actually have a lot more people working in infrastructure.
Faster development mostly leads to expanded economic viability for new types of software. The real question is what becomes economically feasible if development costs are halved.
"In 1865, the English economist William Stanley Jevons observed that technological improvements that increased the efficiency of coal use led to the increased consumption of coal in a wide range of industries. He argued that, contrary to common intuition, technological progress could not be relied upon to reduce fuel consumption."
(Unless that company somehow has no substantial engineering backlog, which I've yet to encounter anywhere I've ever worked.)
But there's a lot of coders in industries whose core business isn't technology. Knapheide for example, a truck outfitting company where my brother codes. I'd imagine in those companies, being able to do the same work with fewer engineers and less cost would lead to fewer hires. Technology isn't their core product and they aren't being held back by software.
At the moment, a truck outfitting company building a customer CRM optimized for their workflow is an absurd idea: they would need a team of a dozen developers working for a year before they could even get a feel for if it was a feasible project or not.
Add LLM assistance and maybe a team of three developers could get to an initial working version in three months.
At that point, companies that had previously ruled out custom software development entirely may find that it makes sense for them - growing the demand for software engineers as a whole.
I'm increasingly worried that that's not the same bar employers will have.
People laugh at coders like we are the only manual loom operators when everyone's job, even PotUS can replaced by the AI we can dream will exist.
My thoughts: buy SPX so you own a sliver of the new overlords.
A lot of kids are going to enroll college to study CS, computer engineering, software engineering, etc. - and will not finish their degrees until 3-5 years. They might just find themselves redundant (junior positions, that is)
Despite developing LLMs for years I haven't actually used them much in day-to-day work, but asking Claude 3.7 Sonnet my coding questions has been a superior experience to just Googling them (particularly if there are specific functional requirements/constraints)
In time the AI will be good enough design whole applications in this vibe-code-y way... But all of the examples I've seen so far indicate that even the best publicly available models aren't there. It seems like every example I've seen has the developer bickering with the ai about something it just won't get right - often wasting more time than they were slightly more hands on. Until the tech gets over that I'll stick to it being the "junior developer I give a uml diagram to so they can figure out the messy parts".
Also this article is immensely distracting.
To put it simply, it doesn’t matter if AI does 80% of the work if that last 20% takes 5x longer. As long as you need a human in the loop who understands the code, that human is going to have to spend the normal amount of time understanding the problem.
It seems to me that LLM output creates a similar situation.
But we have to endure these tedious self-congratulatory "mwa ha well it's still not as good as my code" posts.
No shit. Nobody is saying AI can write a web browser or a compiler or even many far simpler things.
But it can do some very simple things like making basic websites. And sure it gets a lot of stuff wrong and you have to correct it, or fix it yourself. But it's still usually faster than doing everything manually.
This post feels like complaining about cruise control because it isn't level 5 autonomy. Nobody should use it because it doesn't do everything perfectly!
It's nothing like that, because cruise control works reliably. There is never a situation where cruise control randomly starts going 90mph or 10mph while I have it set to 60mph. LLMs on the other hand...
This is why I disagree with people who argue (as you did) "it really does speed up simple tasks". No it doesn't, because even for simple tasks I have to check its work every time. In less than the time it takes me to do that, I could've written the code myself. So these tools slow me down, they don't speed me up.
This hasn't been my experience at all. At worst you skim the code and think "nah that's total nonsense, I'll write it myself from scratch", but that only takes a few seconds. So at worst it wastes a few seconds.
Usually though it spits out a load of stuff, which definitely requires fixing up and tweaking, but is usually way faster than doing it all.
Obviously it depends on the domain too. I wouldn't ask it to write a device driver or something UVM or whatever. But a website interface? Sure. "Spawn a process in C and capture its stdout"? Definitely. There's no way you are doing that faster by hand.
a) More knowledge than the most senior developers b) Can work at ridiculous throughput 24/7
Please provide evidence to back up your claim here: papers, studies, etc.
Otherwise this claim can really only be dismissed as being exaggerated / untrue / naive.
https://twitter.com/leojr94_/status/1901560276488511759
https://twitter.com/leojr94_/status/1902537756674318347
Good thing this guy wasn't in charge of an actual business, because if he was it would have been killed overnight.
The cycle of tool and framework re-skilling is constant in industry, and those trying to fight the wave always lose. And this one is a tidal wave. UPDATE YOUR SKILLS FOLKS!
However, on small tasks and bug fixes, it often fixes the bug before I've even root caused it. It's amazing when I can focus on throwing it information about the bug then have it think in the background while I continue researching. In a surprising number of simpler cases, it one-shots the fix and eliminates any need to root cause (this is a bit easier when it's a feature you understand intimately).
This would have been clear from Karpathy's full statement:
> It's not too bad for throwaway weekend projects, but still quite amusing.
And most of linked in (as the algo show me!) is basically this HN post in 100 words or the polar opposite saying how software engineers have had their chips.
It sounds like a euphemism for:
I don't want to work hard.
I don't care about the details.
I don't want to learn new things.
I want somebody else to do my homework.
I don't want to put in the effort it takes to succeed.
I cheated my way through school instead of learning from classes.
I've always had everything handed to me on a silver platter, and I expect that to continue.
I want to put more effort into yapping on Twitter and getting followers that actually doing any work.
Or maybe the numbers looked jumbled and they really didn’t enjoy STEM classes?
You sound arrogant.
Have you ever paid for artwork? You may not have said “I’m not artistic,” but the same criticisms apply in reverse.
Not wanting to learn new things or understand how things work or put in any effort to succeed because you think you can just cheat your way through life is a totally different thing.
And that's what the difference between using AI programming tools responsibly and "vibe coding" is.
A new tool released that basically lets you design a GUI through guided voice prompts. The 50yr old school teacher can “vibe code” all she wants.
The real problem arises when someone makes false claims they’re a developer when they’re just managing AI generated code. Making it your primary interest and then cheating to make it seem true.
It took me 6 months when I was 10 years old to become technical and create a website. If a 10 years old can do it in 6 months, an adult can do it in 1 month if they work hard.
The situation seems to reflect the issue that Kernighan's Law refers to, which is that debugging code is twice as hard (perhaps more?) as writing it in the first place. I imagine debugging AI-generated code might be even harder.
This has to be a troll no?
They're basically advertising they have a poorly coded, insecure app.
The issues with Claude Plays Pokemon (an overview here: https://arstechnica.com/ai/2025/03/why-anthropics-claude-sti... ) is essentially due to the 200k context window being finite, which is why it has to use an intermediate notepad. In the case of coding assistants like Cursor, the "notepad" is self-documenting with the code itself, sometimes literally with excessive code comments. The functional constraints of code are also more defined both implicitly and optionally explicitly: For Pokemon Red, the 90's game design doesn't often give instructions on where to go for the next objective, which is why the run is effectively over after getting Lt. Surge's badge as the game becomes very nonlinear.
Although, both vibe coding and Claude Plays Pokemon both rely on significant amounts of optimism around the capabilities around LLMs.
Most tech savvy places will avoid it, most good programmers will never encounter it. A bunch or us will make a career out of fixing the mess it makes after it explodes.
My first real job was doing just that at a broker trader which lost 10m on a trade made by an Excel spreadsheet that used a stale yahoo finance API to get exchange rates.
We're not there yet, but I don't see anything preventing us from getting there in ~5 years.
(Remember: 5 years ago, SOTA in this space was letting a genetic algorithm poke at an AST and hopefully maybe arrive at a trivial program solving a small algorithmic problem.)
Are we talking about the reality where the size of the global software outsourcing market is $618 billion and growing? https://groovetechnology.com/blog/software-development/outso...
This is not to say outsourcing can't ever work, but the situations where it does work are much rarer than what every outsourcing vendor would like you to believe.
I bet a previous client's attempt at outsourcing (well into the 6 figures now) is included in that number... yet the expensive onshore devs outsourcing was supposed to replace are still there 2 years later except now they have to also babysit the offshore idiots and fix their messes.
But hey, the vendor got paid, the idiot executive who fell for their pitch wouldn't want to lose face, so it all gets handwaved away as a continuing success and more money gets thrown into the dumpster fire.
The need for companies to get more value out of less spend won't disappear, nor will the comparative advantage of companies in lower CoL areas of the globe. That's two fundamental incentives on both sides that are aligned, driving the market to find the lowest-energy path from here to there. It'll get there, even if it ends up looking strange (like, idk., maybe cutting out management intermediaries but involving a middleman acting as insurance).
That is, if LLMs won't leapfrog it all and end software dev outsourcing before it started to work well.
The thing is how you research, what you expect to get out of it, and what you're willing to pay. There was absolutely a gold rush on bottom-dollar development by cheap overseas developers by management who had no idea how software really worked, and thought they could build a business on cheap offshore development. These were software farms staffed by unappreciated undertrained people from diploma mills. I saw truly shocking things. I saw code written entirely with gotos instead of loops, because the developer had never learned how to write a while loop. The companies spent way more in the long run trying to iterate, ask for changes, and ultimately having to hire higher quality talent for much more money.
I agree with the GP. The LLMs will get better, maybe people will learn that you need an LLM with a skilled developer, or maybe the agents will get good enough to fully drive themselves properly, or maybe just good enough that a non-technical pilot can get good work out of them. Right now, "vibe coding" is largely non-technical people making messy, unmaintainable, insecure code. Some of these are programmers and non-programmers just playing around, but some people are trying to build money-making businesses off this, and it does feel like a very similar situation.
That reality in fact never materialized.
And who cares if it is true? So far programming is one of very few professions when person can set themselves for life in a relatively short period of time. When / if it is gone there will be something else. I have few friends who'd switched to be a handyman. They are doing great from what I see.
If you specifically optimize for it. Most people don't - they specialize and expect to be in their line of work for decades.
> When / if it is gone there will be something else.
There will be something else for young people who are just starting. If you're 20 years into a career and then your line of work disappears overnight, of course you can switch to something else - and enjoy your entry-level salary while competing for jobs with people who are 20+ years younger than you and have no meaningful costs or obligations yet.
Also, on what you're optimizing for. If, like many, you're looking for a job that makes sense, for instance (e.g. working to develop technologies or research that you think can change the world for the better), you're probably never going to strike that particular gold.
I think we will see something similar with LLMs. There will be areas where it will deliver cheaper and faster. There will be areas where it will deliver nothing but disaster. It'll change the industry but not eat it alive. The folks talking about fully autonomous coding on the near horizon are dreaming.
The first one is definitely happening with the LLM bubble where companies really want to pretend that the hard part of the job isn’t understanding what to build and how to do so maintainability.
The second one is going to be more interesting: I expect LLMs to put downward pressure on wages in a lot of places but also for smarter companies to realize that nothing short of true AGI is going to replace the need for people who can actually understand what the customer needs. If I’m right, this will swing the pendulum back towards specialists again – the seagull guys who come in, declare that their favorite framework will solve everything, and leave are more vulnerable to being replaced by an LLM than someone who knows how to code but is also bringing actual business-relevant experience and judgement which an LLM can’t have.
But that's just a continuous variant of the discrete-sounding claim that programming will get eaten by AI soon. After all, the "actual business-relevant experience and judgement which an LLM can’t have" is mostly not related to programming - and the better LLMs get at coding, the less value will the programming parts of the skillset have; take it to the limit, and it's just saying the managers and sales people will stay, while software developers will be gone.
Basically, I’m saying people should stop expecting to get six figures for being able to run create-react-app and deploy a container. The analytical and social parts of the job are where I predict LLMs to make fewer inroads because they require non-generic understanding.
That's a fair take. I do wonder though, how much will those "analytical and social parts of the job" be paying - I imagine you might no longer get six figures for that either, because high tech salaries are fueled by absurd growth of the industry, which manifests in a large part in software that's basically just {framework du jour + basic-level CRUD, that hasn't changed much in 30 years + branding}, and that kind of software I expect to get eaten by LLMs entirely.
Even with cookie-cutter app coders out of the way, the remaining software engineers might see the number of jobs implode, crashing salaries for some time, until (maybe) the growth restarts around new kinds of software, kinds that'll be in high demand and not something that can be made by a few "analytical/social" people herding LLMs. I'd normally say this won't happen, but rather that the software economy will slow down, stabilize, and get boring like everything else - but then, so much of software is driven purely by advertising, and advertising is a negative sum game, so surely they'll invent more bullshit jobs for us.
Oh no, now I love LLMs.
It's about those agents being (mis)used in the very specific blind faith approach of "vibe coding", not least due to the hype merchants and grifters picking up the phrase and running with it shorn of the original cautionary notes about it being useful for bringing a bit of fun back into non-serious coding.
Criticizing the idea (and conflating it with the wider field of LLM coding agents) without understanding that original context is not really any better.
Vibe-coding <> LLM coding agents, which - when used properly - are brilliant for use in serious code and are here to stay.
The reality in which people like me get to do work for US/UK for 4x the salary relative to equivalent work locally, and some of this work is actually cleaning up after folks elsewhere, who being cheapest labor available still got 4x their local salary for this work, and the total is still 4x cheaper than what the US/UK company would pay locally? :).
(I'm only half-joking; in a previous life, I worked on a project with this exact development history.)
The outsourcing market is alive and kicking, and offers a whole spectrum of quality and price. The more to the east of US you are, the easier it is to see :).
> The whole discussion around LLM coding agents feels indistinguishable.
Nah, the difference here is, in outsourcing-to-LLMs scenario, there are no people who do the work and benefit from favorable salary/costs-of-living ratio.
The local QA person could run through 100 or so scenarios a day. The offshore people could do 2 a day. They never improved. The offshore people who are tops aren't cheap.
QA is a whole other story, too. Outsourcing QA is stupid, but even more stupid and short-sighted is not having QA in the first place, and that unfortunately is becoming a norm.
There's lots of false economy going with jobs, too. Getting rid of QA may save you salaries, but the work doesn't disappear - it just gets dumped on everyone else, and now you're distracting much more expensive engineers (software or otherwise), who do a much worse job at it (not being dedicated specialists) and cost more. On the net, I doubt it's ever saving companies any money, but the positives are easy to count, while negatives are diffused and hard to track beyond overall feeling that "somehow, everything takes longer than it should, and comes out worse than it should, who knows why?".
Yes, they were moving in that direction. They centralized the QA team over a suite of probably 15 products, which means no one has any expertise. The QA VP would get mad when QA found bugs because "the dev's were supposed to find all the bugs and the QA was just supposed to just certify the release." The amount of people who don't understand how software dev works in high positions is mind boggling.
They ended up firing all the devs except me and this other guy who gave zero shits and wanted to be a manager. "We" maintained 3 products. Two were pretty standard web apps but one was a full blown decision support system (rules engine) that only I knew. I quit after a few months of killing myself. They paid me a whole lot of money a few years later when they were trying to add features to get a very lucrative government contract.
Like some of the other responses, I'm baffled by your comment. Have you not seen what's happened in the past 5 years or so?
Yes, there was an outsourcing craze to India after the .com bubble burst in the early 00s that largely failed - the timezone, cultural differences, and lack of good infrastructure support made it fail.
The past 2 companies I've worked for offshored the majority of their software engineering work, and there was no quality difference compared to American devs. The offshore locations were Latin America and Europe, so plenty of timezone overlap. The companies are fully remote, so what difference does it make if the dev is in your same city or a thousand miles away?
I think offshoring has absolutely put downward pressure on US dev salaries in the past couple years.
There's at least the crucial difference that you had devs in both western countries and traditional "third world", where the 90s view of offshoring was throwing whole processes abroad and only keep "heads" in-house while the remote teams/companies would deal with all the execution, making it inherently difficult to deal with production monitoring.
PS: to your point offshoring to India has become more common but Indian companies are also not that cheap, so we're past the initial framework. Perhaps the same way outsourcing production to China used to be about sweatshops, when it can now be about unrivaled expertise at a cost.
The good thing about vive coding is it avoids the software development lifecycle completely from the user perspective in a platform that has an integrated SDLC which means from defining idea to ensure visibility in changes to a runtime where the user can see it. In my mind, modifying without a hassle in a controlled environment is what users look for. Software development assisted by AI will be a thing for engineers but Vive coding is aimed for users outside of engineering. I sadly see only a handful of companies being able to pull this off.
> "Vibe Coding" might get you 80% the way to a functioning concept. But to produce something reliable, secure, and worth spending money on, you’ll need experienced humans to do the hard work not possible with today’s models.
The problem is that 80% of the job is a proof of concept at best. 80% is effectively a QA walking into a bar[1].
[1] https://barrypopik.com/blog/a_software_tester_walks
So there is still a productivity gain for senior developers.
> There's a trend on social media where many repeat Andrej Karpathy's words: "give in to the vibes, embrace exponentials, and forget that the code even exists." This belief — like many flawed takes humanity holds — comes from laziness, inexperience, and self-deluding imagination.
I'm going to go ahead and give the author the benefit of the doubt that they aren't literally saying Andrej Karpathy is "lazy and inexperienced", because that claim is obviously absurd.
In general though, I think the author is missing the actual point Karpathy was making! Let's look at his detailed criticisms for the typescript agent run, for example:
> Regularly clones TypeScript interfaces instead of exporting the original and importing it.
> Reinvents components all the time with the same structure without searching the code base for an existing copy of that component.
These are only problems for human codebases. You're not vibing if you are expecting agents to write code the way humans would.
Duplicating interfaces and implementations is inefficient, and would be a nightmare, in a human codebase. But, the code will still work! So if an AI agent is managing the codebase, who cares if it duplicates things all the time?
Maybe it'll see that it did that later and decide to consolidate things, maybe it won't. It doesn't affect the actual outcome of the code, unless you actually look at the code as a human, which is not "vibe coding."
> When told to fix styles with precise details, it will alter the wrong component entirely.
> When told specifically where there are many duplicated components and instructed to refactor, will only refactor the first instance of that component in the file instead of all instances in all files.
> When told to refactor code, fails to search for the breaks it caused even when told to do so.
You're thinking about the code again, gotta stop doing that if you actually want to ~vibe code~. Refactoring code isn't a thing when you're vibe coding, English is your programming language now, the Typescript (or w/e language) is the assembly. You wouldn't spend much time observing the assembly output of your compiler (especially for web dev), so why are you observing the code output of your agent?
If you don't want to vibe code, that's fine, nobody is forcing you to. But if you're going to do it, grade it on the metric that Andrej was actually claiming: that you can get working results on a lot of software projects today by telling coding agents to make some code do something, and then just keep running it with "fix this bug" until it works, and it'll often get to a working result.
He never claimed that the code outputted would be beautiful, from a human perspective, or well formatted, or well architected, or efficient.
Seems like someone is quite bitter about new stuff.
Or would you argue that NFTs actually did live up to the BS that was ascribed to them in some circles during their hype?
But "some circles" ascribe BS to any new technology.
This article is a bit more balanced, though, and clearly isn't criticising use of AI in programming, but specifically the "Jesus take the wheel" style of vibe coding. It's the same old "if you write code as cleverly as you possibly can, you are not smart enough to debug it", but to the next level, where people are writing code that they aren't even smart enough to read.
If you are working at a place where that quality level is standard -- and let's face it, a large number of companies produce average or below-average quality code (by definition) -- then using an LLM assistant isn't that bad. At least if such an assistant doesn't have some extra flaws beyond producing the best summary of its training data, which is exactly what an LLM does. It actually justifiably replaces developers in such an average-or-below place. But if you are aiming for the top end of the quality scale then there is no way this can be achieved by LLM output. Purely on principle.
This shouldn't even be a controversial opinion. I'm quite surprised every time this is questioned or even just debated.
I think "one shot ready for production code" is what AI cannot do yet. Which is why I am not worried for another 12 months at least :)
I wrote this because I was worried that "vibe coding" was being misinterpreted to mean "any time an LLM outputs code", as opposed to the intended definition of code where you deliberately don't review the code and see how far you can get.
https://news.ycombinator.com/item?id=43446695
Judging by the comments, most people couldn't even tell it was satire, which goes to show how absurd the hype is right now (and probably why it was buried).
For example, here are YC partners quoting a company in a batch claiming "100x speedup" in coding performance compared to the previous month:
https://www.youtube.com/watch?v=IACHfKmZMr8&t=1837s
You can tell this claim is false, because that level of productivity increase would be glaringly obvious to an outside observer; it wouldn't need to be self-reported.
A YC summer batch is 84 days culminating in Demo Day. So a 100x speed improvement would be like a team spending less than 1 day of coding and ending up with something that's on par with Demo Day in terms of functionality. Maybe the design would be wrong, but that wrong design would be just as fully-featured as a Demo Day app.
So if 100x were true, the partners in that video would be talking about how the new batch dynamic is "They get breakfast with a customer, learn something new, have an epiphany, and then later the same day they have their entire app rewritten based on what they learned, and that scratch-rewrite is already at a Demo Day level of functionality." The partners aren't talking about that dynamic because it's not happening. So clearly the self-reported 100x is inaccurate.
Even 10x would result in partners saying "Whoa, in this batch people have a Demo Day-quality app in production by the end of week 1 instead of week 12." The partners have a huge sample size on how much teams get done in what time period, so it would be glaringly obvious to them if this batch were shipping 10x as fast as previous batches.
That external observation would be the headline if it were what the partners were actually seeing. Since that's not the headline, it's clearly not what they're seeing, so 10x can't be the number either.
Also multiples “up” versus “down” are not symmetric. Airplanes are around 10x faster than cars, but that doesn’t mean I’ll be getting to work in 60 seconds.
Note that real engineers helps you come up with new features and test your product and all that and not just add code, adding code was never a bottleneck on just about any problem ever.
So Amdahl's law applies in terms of the time to add code, not in terms of engineers, they don't do the work of 100 engineers, at best they take 100x less time to add lines of code when they know what they wanna make. But that isn't particularly game changing, as adding code is not the hard or even time consuming part.
Wake me up when someone vibe codes a Chrome replacement, or an iOS replacement, or MS Office...
Except we know this won't happen anytime soon because we all know vibe coding isn't very useful beyond toy projects that leverage complex libraries written by actual developers.
We have a fair number of offshore resources that are used for dev. They developers are fully integrated into the team, are in all the stand-ups, and substitute for the usual role of junior programmers. They don't get the grunt-work shoveled on them, they get the same work as everyone else, they're just expected to not be as fast.
In 6 months 2 out of 4 of them been sacked, and surprise, not because we could replace their work with LLM output, but because their use of LLMs was so unrestrained and scattershot the pull requests they submitted had become nightmares. One thing mentioned in the article about unit test creation was something we saw as well. Perhaps this is partly due to working an existing code base where the LLM loses some of its advantage, and certainly some of it was cultural in that progress was thought more important than actual manageable code. The two sacked fellows where told, literally, from my own mouth, multiple times, "You cannot just ask Copilot to write you code, paste the entire thing into Visual Studio with no thought of what has changed, with the end goal of just compiling and meeting the single set of acceptance criteria on your story. You're breaking other things and introducing bugs." It went on deaf ears, and now they're gone. They were nice people, I didn't know how to get through to them, but they were convinced the LLMs were the way to go.
I use LLMs to help write code every day, and I wouldn't want to be without it, but I'm fairly surgical about it. Most of the time Copilot gives you a page of say, React code, or EF Core queries, you have to be really careful about anything you didn't explicitly ask for. Honestly, there is a time savings, but there is not a quality increase. The benefit is subverted by the time it takes to figure out how to ask correctly, the time to vet the output, and the time to fix the little tiny insidious bugs it can introduce.
So, don't go vibe coding and lose your job, is something to think about. I have to admit that it has worn me down meeting these interesting people from far-flung locations only to watch them flounder and get let go.
The company has been relatively ambivalent about the usage of code assistant AI, but during PR reviews it has become very apparent that its seen widespread adoption among the outsourced dev teams purely because of code duplication. Our company has a fairly large number of repositories and bespoke libs for utility type functionality.
In the past, a programmer might have internally said to themselves, "There's no way that somebody hasn't already written this stupid function X or method Y", and they'd take a few minutes to search or reach out to see if it exists within an organization.
Instead during some of the recent code reviews, there has been a huge uptick in core functionality that is very obviously being spit out by the LLM. At best its just extra unnecessary code. At worst it will introduce new bugs since our custom functions often handle business domain specific edge cases that an LLM simply wouldn't know about.
Now non-programmers can fumble forward to a working demo. But junior engineers are walking around with a loaded weapon - if they are not learning from how AI solves a problem or using it like StackOverflow to answer specific questions, they are blowing up their own careers.
The future is we are all product engineers or domain experts. No one is going to want an army of React engineers in 2 years.
Also it is important to be able to review the code because it could be the case that it looks mostly correct but has some subtle errors in it that can mislead you. For example I was trying a couple of different ways of computing some indices that have a bunch of variables and one way had a mask that made no sense involved. "Vibe coding" without being able to check the work of an LLM is almost certain to go poorly, IOW.
This is a real problem that I have experienced on and off. It's getting to the point where everyone on my team is actively looking for alternatives. Generally, I've found Cursor works correctly after business hours. But, it's increasingly giving absolutely useless responses during business hours.
-----
That being said, I agree with many of the author's observations. However, for me, it's not really a breaker. It's not much different than working with an intern or junior engineer. If you ask them to do too much all at once, they come up with bad solutions. Plus, they have a tendency to make "dumb" decisions.
For me, I've found solutions for nearly all of the listed issue. Much of it comes down to being diligent during code review (like you should). For example, the Typescript issue, I come back later to have it fix it.
Specs are the one that still baffles me. It's absolutely terrible at writing proper specs. In particular, it falls into a really bad cycle whenever there are errors. I don't have a solution for this one.
Interestingly the times I've experienced the most weirdness were during extremely not normal business hours (from the California perspective). For 3 nights in a row last week, I found myself coding at/after 2:30am during what were apparently periods of excessive load on Claude Sonnet. When asking Cursor to do things, it would fail, tell me about the high load, and encourage me to try again soon. Well, I just kept clicking the button over and over again, thinking it would eventually be able to handle the request properly, and otherwise continue presenting the error. Not the case!
Incorrect/hilarious things Cursor/Claude did at points during those nights:
- repeat the inquiry back to me in full, then do nothing at all after that
- confidently assert it had located the bug I was looking for, then direct me towards the entire codebase
- assert that it had done what I asked, and request that I approve the changes it wanted to make to my code, which were... nothing, none whatsoever
- (possibly the most hilarious) begin to answer questions in borderline leetspeak, randomly substituting numbers in place of letters in words, before eventually devolving into total gibberish
Mostly just annoying due to the wasted time, though it's possible the entertainment value negated it. I don't expect miracles from Cursor to begin with, nor do I give it wide latitude to change very much in my projects, so the risk of damage wasn't really any worse then than at any other time. Of course, I am not a team working against deadlines on critical projects, just a guy screwing around at 2:30am.
That's morning business hours in Europe and afternoon in Asia.
It’s consistently better during that time.
Similar energy
Everybody can vibe cook. - Vercel
For more esoteric fast changing languages/frameworks it has me chasing my tail in a chain of code updates where each fix breaks something in the n-1th, or n-2th version. Sometimes it's deprecated code, or it halucinates functions that would be valid if your were using a a different language of framework. And sometimes simple coding errors.
But it will get better, a lot better.
The main benefit is that it will let a invested non programmer client build a functional framework prototype and then combine that with a list missing features that a more skilled programmer can flesh out to a first cut solution.
For the first time we 'might' get better requirements with an actual working model instead of having the implementor doing most of the requirements as a first pass from a high level hand wavy requirement. I think we're going to see some amazing tools for this.
What I don't see it doing is creating original algorithms to solve things being done for the first time.
I see statements like this a lot when talking about AI in general. People seem to think it is a foregone conclusion that no limit to LLM model improvement and capability exists. What causes you to believe this and what evidence do you have to back it up?
Now, about your comprehension skills, where is there any mention on my part of there being 'no limit'? In fact I go as far as to speculate on at least one.