[HN Gopher] "Vibe Coding" vs. Reality
___________________________________________________________________
"Vibe Coding" vs. Reality
Author : birdculture
Score : 153 points
Date : 2025-03-22 20:35 UTC (2 hours ago)
(HTM) web link (cendyne.dev)
(TXT) w3m dump (cendyne.dev)
| Trasmatta wrote:
| The more I work with LLMs and try things like "vibe coding" the
| less worried I am about AI taking my job any time soon.
|
| In 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.
| bobxmax wrote:
| I work at a company relatively well-known in Startup-land and
| I've replaced a product team which had 9 devs 2 years ago with
| 2 devs with AI.
|
| Devs are just coping so hard around LLMs its hard to watch.
| OTOH the few engineers who have embraced it are excelling.
| jgilias wrote:
| After all these years 10x devs have become a reality.
| barbazoo wrote:
| > I've replaced a product team which had 9 devs 2 years ago
| with 2 devs with AI.
|
| Totally believable bro
| bobxmax wrote:
| You're willingly naive and blind if you think this isn't
| happening everywhere around you.
| pton_xd wrote:
| You likely should have replaced those devs years ago. Kudos
| to LLMs helping you figure that out though.
| bobxmax wrote:
| Nope. They were talented devs who all (well, most) landed
| in great companies after.
|
| We just didn't need them anymore because LLMs and tools
| like cursor are insanely good.
| stavros wrote:
| I'd like to come back to this in a year to see how
| maintainable the codebase is.
| bobxmax wrote:
| 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.
| Trasmatta wrote:
| Are you a developer yourself?
|
| 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).
| bobxmax wrote:
| Yes, I'm a developer. LLMs allow engineers to become
| product people themselves.
| cpursley wrote:
| There's def a lot of gatekeeping going on by the real
| coders(tm). 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.
| c0redump wrote:
| Is it already the part of the hype cycle where we just make
| shit up?
| bobxmax wrote:
| Whatever helps you sleep at night, while the rest of the
| world zips past you.
| nextts wrote:
| 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).
| bobxmax wrote:
| They were good... probably a bit bloated. Without AI we
| could probably be 5 devs. With AI we can do it all in 1-2.
| nextts wrote:
| 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.
| vunderba wrote:
| 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.
| bobxmax wrote:
| Probably a bit of both.
| jgilias wrote:
| 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.
| Trasmatta wrote:
| 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).
| varenc wrote:
| Speeding up your work does lead to job loss. If some developers
| can suddenly be 3x as productive than a company doesn't need as
| many engineers.
| cmdli wrote:
| 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.
| toogan wrote:
| > The job loss depends on the average speed up,
|
| 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.
| c0redump wrote:
| Or it just leads to 3x more stuff being made. This conclusion
| isn't nearly as trivial as you're making it out to be.
| AnimalMuppet wrote:
| Only if that company has a finite wish list for their
| software. That is rarely the case.
| dghlsakjg wrote:
| 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.
| jetrink wrote:
| Jevon's Paradox:
| https://en.wikipedia.org/wiki/Jevons_paradox
|
| "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."
| simonw wrote:
| Alternatively: if LLMs make devs 3x productive that means
| companies can get 3x the value out of an engineering hire, so
| they should hire more.
|
| (Unless that company somehow has no substantial engineering
| backlog, which I've yet to encounter anywhere I've ever
| worked.)
| dataflow wrote:
| > But it's nowhere close to being able to replace what I do.
|
| I'm increasingly worried that that's not the same bar employers
| will have.
| hollerith wrote:
| Wait 10 years, though.
| cmdli wrote:
| I heard the same thing about self driving cars. AI
| advancements aren't predictable, and it's easy to understand
| or overestimate.
| nextts wrote:
| 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.
| TrackerFF wrote:
| 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)
| minimaxir wrote:
| 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)
| jevndev wrote:
| 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".
| bobxmax wrote:
| 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%.
|
| Also this article is immensely distracting.
| cmdli wrote:
| 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.
| tibbar wrote:
| 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.
| toogan wrote:
| 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.
| IshKebab wrote:
| 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!
| bigstrat2003 wrote:
| > 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.
| mdaniel wrote:
| I hear you, and actually agree, but never say "never,"
| because it's still just a machine https://duckduckgo.com/
| ?t=ffab&q=toyota+stuck+cruise+control...
| bobxmax wrote:
| This is just silly. LLMs have
|
| a) More knowledge than the most senior developers b) Can work
| at ridiculous throughput 24/7
| do_not_redeem wrote:
| The problem is it's more work to figure out which 20% it did
| subtly wrong, than it is to just do things right in the first
| place.
|
| 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.
| kebokyo wrote:
| 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.
| spoaceman7777 wrote:
| 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!
| SkyPuncher wrote:
| 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).
| mr_mitm wrote:
| > "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.
| softwaredoug wrote:
| Exactly. People have gotten too worked up about this idea
| without reading the original intention.
| musicale wrote:
| "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
|
| - (leo, 2025)
| nextts wrote:
| 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.
| sureglymop wrote:
| Well I checked out the Saas' website and not even the
| navigation on the landing page worked correctly. Very
| confidence inspiring!
| DonHopkins wrote:
| What does "I'm not technical" actually mean?
|
| 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.
| pinkerpell wrote:
| try writing next.js 15 using AI, and you understand how far we
| are away from getting replaced by it.
| 18172828286177 wrote:
| > 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
|
| This has to be a troll no?
| ehutch79 wrote:
| Sadly, there's a good chance it's not.
|
| They're basically advertising they have a poorly coded,
| insecure app.
| minimaxir wrote:
| 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.
| noosphr wrote:
| 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.
| jaza wrote:
| Oh god. Fixing an excel spreadsheet full of crazy macros was my
| first job too. The nightmares still haunt me.
| Etheryte wrote:
| 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.
| booleandilemma wrote:
| 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.
| exe34 wrote:
| the next version of AI will simply make it into a bigger
| mess.
| amarcheschi wrote:
| Now, now, not with this mindset. You have to ask the Ai to
| fix the mess, and if it doesn't, try again!
| mdaniel wrote:
| AIUI one should be sure to include a grandmother dying if
| that div doesn't get centered
| kolektiv wrote:
| As if the person struggling with the mess will have the
| requisite skill levels to even recognise a mess!
| dragonelite wrote:
| Ooh but don't you know we just need an extra language
| with abstractions that can be compiled into prompting
| statements. Maybe something like sql.
| TeMPOraL wrote:
| 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.)
| SJC_Hacker wrote:
| And full self driving is always just 5 years away.
| CharlesW wrote:
| > _Then the reality hit._
|
| 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...
| Etheryte wrote:
| 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.
| Nextgrid wrote:
| 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.
| MyOutfitIsVague wrote:
| 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.
| iamEAP wrote:
| 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.
|
| That reality in fact never materialized.
| matsemann wrote:
| The market where I live is far larger than it was 15-20 years
| ago. So both have grown, the outsourcing didn't kill local as
| predicted.
| TeMPOraL wrote:
| The growth of demand for software development is absurd and
| heavily skews people's expectations. It won't last forever.
| FpUser wrote:
| >" It won't last forever."
|
| 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.
| TeMPOraL wrote:
| > _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.
| stusmall wrote:
| 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.
| acdha wrote:
| 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.
| mellosouls wrote:
| This is not about "LLM coding agents".
|
| 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.
| TeMPOraL wrote:
| > _Then the reality hit._
|
| 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.
| Clubber wrote:
| 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.
| TeMPOraL wrote:
| 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?".
| hn_throwaway_99 wrote:
| > 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.
| makeitdouble wrote:
| 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.
| clvx wrote:
| > 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.
| axegon_ wrote:
| 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].
|
| [1] https://barrypopik.com/blog/a_software_tester_walks
| mdaniel wrote:
| 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
| Mountain_Skies wrote:
| 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'.
| dragonelite wrote:
| 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.
| CrzyLngPwd wrote:
| New silver bullets are the same as old silver bullets, but these
| are easy to fire at your own feet.
| carlosdp wrote:
| Ok first of all,
|
| > 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.
| k__ wrote:
| _" Like the NFT crowd, there is a bubble of unreality they cling
| to justifying their perception of the world."_
|
| Seems like someone is quite bitter about new stuff.
| toogan wrote:
| .. new stuff that quite obviously won't be able to live up to
| its hype. Indeed.
|
| Or would you argue that NFTs actually did live up to the BS
| that was ascribed to them in some circles during their hype?
| k__ wrote:
| Obviously not.
|
| But "some circles" ascribe BS to any new technology.
| MyOutfitIsVague wrote:
| 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.
| toogan wrote:
| 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.
| nextts wrote:
| "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 :)
| simonw wrote:
| Not all AI-assisted programming is vibe coding (but vibe coding
| rocks) - https://simonwillison.net/2025/Mar/19/vibe-coding/
|
| 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.
| sfjailbird wrote:
| This brilliant piece of satire from Steve Yegge got buried for
| some reason:
|
| 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).
| throwaway382948 wrote:
| 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.
| rtfeldman wrote:
| I think the bigger "AI hype vs. Reality" gap is about the
| productivity numbers people casually throw around, like "10x as
| productive" or even 100x.
|
| 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.
| __gcd wrote:
| 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.
| mdaniel wrote:
| 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
| daveguy wrote:
| Not sure if this is a joke, but it's hilarious either way.
| 01100011 wrote:
| 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.
| redleggedfrog wrote:
| 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.
| vunderba wrote:
| 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.
| MoonGhost wrote:
| 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.
| trashtensor wrote:
| 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.
| SkyPuncher wrote:
| > 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.
| dkh wrote:
| > 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.
| Izkata wrote:
| > 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
|
| That's morning business hours in Europe and afternoon in
| Asia.
| brentm wrote:
| I have to say I am extremely sick of this term.
| browningstreet wrote:
| Vibe coding is the new HODL
|
| Similar energy
| nextts wrote:
| Vibe gambling
| benatkin wrote:
| Vibe cooking
|
| Everybody can vibe cook. - Vercel
| Izkata wrote:
| Remember, glue is a great way to keep cheese from sliding
| off pizza!
| DonHopkins wrote:
| Vibe Day Trading
| benatkin wrote:
| Vibe Forex
| vunderba wrote:
| Humans are mostly _" stochastic parrots"_ so I'm utterly
| unsurprised that it's hit a critical mass in the training data
| of people's wetware.
| mentalgear wrote:
| The biggest give-away is: When you look at the companies making
| these claims and their jobs page shows they are actively hiring
| developers.
| mdaniel wrote:
| 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?)
| jocoda wrote:
| 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.
| falkensmaize wrote:
| "But it will get better, a lot better."
|
| 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?
| tokioyoyo wrote:
| 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.
| the_snooze wrote:
| https://xkcd.com/605/
| tokioyoyo wrote:
| 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.
| jocoda wrote:
| 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.
| mellosouls wrote:
| Please can everybody who dislikes LLMs stop conflating "vibe
| coding" (fun, see how far you can get without actually coding but
| _not intended for serious projects_ as per karparthy 's original
| tweet) with the grifter version that sells it without the
| cautionary note, or with LLM tool usage as a whole class.
|
| They are 3 different things, and neither of the first two
| represent anything more than a subset of the capabilities of the
| latter.
|
| If you don't like LLMs that's cool, but at least take some time
| to understand the context here.
| rafaelmn wrote:
| I mean shouldn't Jensen be shitting his pants about this? Vibe
| code the CUDA away and bye bye margins ?
| mdaniel wrote:
| That one would be extra awesome because by the time anyone
| realized there was some subtle stats bug in the resulting
| kernels, it'd have vaporized $10MM in cloud training opex
| mentalgear wrote:
| This should be called "vape coding".
|
| Strongly agree with the article, and happy to see so many lucid
| people, comments and articles on HN that thoroughly deconstruct
| the "vibe coding" illusion.
|
| Also, Andrej Karpathy really disappointed pushing such brittle BS
| as a revolution.
| alecco wrote:
| I think it's a good thing. Let them experience our little hell.
| They'll come out appreciating our craft more once they get
| through :)
| MarkMarine wrote:
| This is the go community saying a computer will never best human
| go players.
|
| We already have examples of a model finding more performant sorts
| [0], given the right incentives and time, and the right system
| for optimizing (LLMs trained on "average code" probably aren't
| it) the computer will best us at creating things for the
| computer.
|
| Is "vibe coding" real today? Not in my experience, with even
| Claude code. My hand has to be firmly on the tiller, using my
| experience and skill to correct its mistakes and guide it. But I
| can see the current trajectory of improvement, and I'm sure it'll
| get there.
|
| [0] https://deepmind.google/discover/blog/alphadev-discovers-
| fas...
| MR4D wrote:
| I think it's partially there:
|
| For creating website (not apps) it absolutely is there. This is
| just the first rung on the ladder though. It's not doing Linux
| kernel development yet, but that time will come eventually. In
| between are all the other rungs. AI will climb them one by one.
| margalabargala wrote:
| Where we are now, I wonder if is similar to the early days of
| compiled languages existing, back when people still somewhat
| commonly wrote assembly by hand and didn't trust compilers.
|
| Sure, things like Roller Coaster Tycoon exist, but but writing
| in a compiled language is so much faster, easier, and more
| broadly accessible than writing in assembly that compilers took
| over.
| oblio wrote:
| My worry about this approach is: there is a reasonably
| popular saying that writing code is hard but debugging it is
| twice as hard (at least), which I think is an accurate
| description.
|
| LLMs will greatly increase code production, will they also
| increase debuggability to match?
| TeMPOraL wrote:
| LLMs don't just make it easy to accumulate code - they make
| it easy to _throw code away and start again_. This already
| enables taking a different approach to debuggability - if
| there 's a bug and it can't be trivially solved, _trash
| that bit of the code and write it again_. It may not be
| broadly viable just yet, but it will be if the models keep
| getting cheaper and better.
|
| This is also implied in the idea of "vibe coding" - don't
| bother understanding the code or debugging it yourself; if
| it doesn't work the way you like, just say it and have the
| model fix it until it gets it right (or you run out of
| money).
| arrowsmith wrote:
| TIL that Rollercoaster Tycoon was written in Assembly.
|
| "[Developer Chris] Sawyer wrote 99% of the code for
| RollerCoaster Tycoon in x86 assembly language for the
| Microsoft Macro Assembler, with the remaining one percent
| written in C." - Wikipedia
|
| What a lunatic.
| jmull wrote:
| Well... to be frank, this is someone not reading TFA.
|
| The article is pointing out real limitations of vibe coding
| today (which you appear to agree with). It does suggest AI
| coding won't be viable in the future. You should probably
| update your comment to say something like, "spot on".
| TeMPOraL wrote:
| Nah, the article is generalizing from a single sample of
| current state, ignoring the larger trajectory (that, for AI
| coding, went from sci-fi to reality in _two years_ ).
|
| Sure, the tools aren't perfect, so there's some art to using
| them now - which the author of TFA seems to be unaware of.
| Take for example:
|
| > _You cannot ask these tools today to develop a performant
| React application. You cannot ask these tools to implement a
| secure user registration flow. It will choose to execute
| functions like is user registered on the client instead of
| the server._
|
| Of course you _can_ ask them to do it. You can literally ask
| them to "write better code" (yes, with this exact phrase;
| see [0]), and you'll get better code. More performant, or
| more secure - it depends on specifics of the case. Or, you
| can ask them specifically to focus on security or
| performance, and you will typically get improvements on those
| axis.
|
| That's today. Next year, people will know how to prompt the
| models away from most common failure modes, and the models
| themselves will be further trained to avoid those same
| failure modes. In bringing specific problems up, TFA isn't
| making a convincing argument against future of "vibe coding"
| - it's literally _helping in making it happen_.
|
| --
|
| [0] - https://minimaxir.com/2025/01/write-better-code/
| dr_dshiv wrote:
| Vibe coding is 100% real. Or maybe we should call it code
| vibing when there is no coding ability. But I just taught 18
| professionals with no coding ability to build functional
| software. Their minds were blown
| mentos wrote:
| Cursor? I finally got around to trying it this week and it
| exceeded my expectations.
| dr_dshiv wrote:
| No, if you have no coding ability and no interest in
| learning but want to just tell the computer what you want:
|
| 1. Lovable
|
| 2. Bolt.new
|
| 3. Replit agent
|
| Or actually, I'd put Claude #1. You can make all kinds of
| cool stuff, just in their UI.
| loloquwowndueo wrote:
| Wait until they have to maintain, debug or secure that
| software. You'll see things really blow at that point.
| SJC_Hacker wrote:
| If its something like "tic-tac-toe in Javascript", thats been
| done 1000x before, I wouldn't find it all that impressive.
| TeMPOraL wrote:
| Most of webdev has been done 1000000x before. Though to be
| fair, Wix and Squarespace already bit a huge chunk out of
| that market.
| jxjnskkzxxhx wrote:
| Making the arguing that these tools have flaws seem like a losing
| battle. Soon those flaws will be fixed[1] and youll have to find
| new flaws to complain about. Eventually hopefully you'll realize
| that you just don't like feeling displaced.
|
| [1] it's unbelievable what a difference in quality 1 year made
| for chat gpt
| id00 wrote:
| Why are you so certain that flaws will be fixed? Seems like
| there is a giant leap between a machine spewing words based on
| probability and actual deep understanding of the code it's
| suppose to write
| oblio wrote:
| Until this knowledge is widespread, a lot of devs better hold
| on to their current good jobs.
| ohgr wrote:
| Vibe coding is my favourite fad so far. Much like the last few
| fads I'm going to make so much money out of cleaning up
| afterwards it's unreal.
|
| Really this whole industry is on another fucking planet. I hate
| it but it's so easy to make money.
| dfps wrote:
| 100x would mean after one month, people'd say 'I just did 10
| years of work.' Is anyone saying that yet?
| d4rkn0d3z wrote:
| "Vibe Coding" might get you 80% the way to a functioning
| concept."
|
| But 80% of the functionality is only 10% of the work. The last
| 20% of the functionality remains and will require 90% of the
| work.
| liendolucas wrote:
| This idea that now everyone with little knowledge can code is
| absurd. For sure everyone can code: with hours of dedication,
| sitting down and trying things out, learning and improving from
| errors and past experineces. There is no other way round. I don't
| know how the next generation of coders is going to be like, but
| my advice still stands: read books, realiable sources, do your
| homework and "vibe coders" will become so irrelevant that will be
| extinguished by their own ignorance. Don't get fooled by number
| crunching programs that seem to "program".
| jfengel wrote:
| I finally gave in and clicked on the article so I could find out
| what "vibe coding" is.
|
| You learn something new every day. Some days that thing does not
| piss you off. Today is not that day.
| jeffreyrogers wrote:
| Most programmers are already doing a form of vibe coding when
| they, for example, let an ORM write their database queries for
| them. I think a decent number of Rails and Django devs probably
| would struggle to write raw SQL queries from scratch. Mostly I
| see vibe coding as an extension of that, and it's not necessarily
| a bad thing since it lets you spend more time focusing on the
| actual problem you're solving rather than on implementing it.
|
| Of course, I haven't seen a single vibe-coded thing that I'd want
| to spend money paying for yet, but that's probably more
| reflective of the difficulty of making something people want than
| whether or not you use vibe coding to do it.
| gooseus wrote:
| I've been "Vibe-TDDing" all afternoon and I'll tell you what,
| vibe tests are better than no tests.
|
| And so long as you have some decent-to-solid understanding of
| coding and testing (this is non-trivial, I've been coding for
| professionally for ~20 years) then you can direct the machine to
| put up decent guardrails first, and then you can kinda go nuts
| and let shit grow, prune it back, repeat.
|
| Basically, if you know what code/tests ought to look and act
| like, then you can significantly reduce the negative
| externalities of having LLMs do your coding for you.
___________________________________________________________________
(page generated 2025-03-22 23:01 UTC)