Breaking the spell of vibe coding • Hacker News Board

Re: Breaking the spell of vibe coding

#51

Post by daxfohl » Sat, Feb 14, 2026, 11:18 PM UTC

softwaredoug wrote: post #30

daxfohl wrote: post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

Even within AI coding how people use this varies wildly from one people trying to one shot apps to people being barely above tab completers. When people talk about this stuff they usually mean very different techniques. And last months way of doing it goes away in favor of a new technique. I think the best you can do now is try lots of different new ways of working keep an open mind

Or just wait for things to settle. As fast as the field is moving, staying ahead of the game is probably high investment with little return, as the things you spend a ton of time honing today may be obsolete tomorrow, or simply built into existing products with much lower learning cost.

Note, if staying on the bleeding edge is what excites you, by all means do. I'm just saying for people who don't feel that urge, there's probably no harm just waiting for stuff to standardize and slow down. Either approach is fine so long as you're pragmatic about it.

Re: Breaking the spell of vibe coding

#52

Post by nkmnz » Sat, Feb 14, 2026, 11:18 PM UTC

piker wrote: post #34

nkmnz wrote: post #32

> A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times! It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.

I get caught up personally in this math as well. Is a charitable interpretation of the throwaway line that they were off by that many “percentage points”?

That would be correct, but also useless. It matters if 50pp are 50% vs. 100%, 75% vs. 125% or 100% vs. 150%.

Re: Breaking the spell of vibe coding

#53

Post by mprast » Sat, Feb 14, 2026, 11:18 PM UTC

daxfohl wrote: post #7

I think it all boils down to, which is higher risk, using AI too much, or using AI too little? Right now I see the former as being hugely risky. Hallucinated bugs, coaxed into dead-end architectures, security concerns, not being familiar with the code when a bug shows up in production, less sense of ownership, less hands-on learning, etc. This is true both at the personal level and at the business level. (And astound…

It's very interesting to me how many people presume that if you don't learn how to vibecode now you'll never ever be able to catch up. If the models are constantly getting better, won't these tools be easier to use a year from now? Will model improvements not obviate all the byzantine prompting strategies we have to use today?

Re: Breaking the spell of vibe coding

#54

Post by imiric » Sat, Feb 14, 2026, 11:19 PM UTC

ithkuil wrote: post #8

Kerrick wrote: post #3

> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled , Domain-Driven Design , Imple…

I personally found out that knowing how to use ai coding assistants productively is a skill like any other and a) it requires a significant investment of time b) can be quite rewarding to learn just as any other skill c) might be useful now or in the future and d) doesn't negate the usefulness of any other skills acquired on the past nor diminishes the usefulness of learning new skills in the future

> knowing how to use ai coding assistants productively is a skill like any other

No, it's different from other skills in several ways.

For one, the difficulty of this skill is largely overstated. All it requires is basic natural language reading and writing, the ability to organize work and issue clear instructions, and some relatively simple technical knowledge about managing context effectively, knowing which tool to use for which task, and other minor details. This pales in comparison with the difficulty of learning a programming language and classical programming. After all, the entire point of these tools is to lower the required skill ceiling of tasks that were previously inaccessible to many people. The fact that millions of people are now using them, with varying degrees of success for various reasons, is a testament of this.

I would argue that the results depend far more on the user's familiarity with the domain than their skill level. Domain experts know how to ask the right questions, provide useful guidance, and can tell when the output is of poor quality or inaccurate. No amount of technical expertise will help you make these judgments if you're not familiar with the domain to begin with, which can only lead to poor results.

> might be useful now or in the future

How will this skill be useful in the future? Isn't the goal of the companies producing these tools to make them accessible to as many people as possible? If the technology continues to improve, won't it become easier to use, and be able to produce better output with less guidance?

It's amusing to me that people think this technology is another layer of abstraction, and that they can focus on "important" things while the machine works on the tedious details. Don't you see that this is simply a transition period, and that whatever work you're doing now, could eventually be done better/faster/cheaper by the same technology? The goal is to replace all cognitive work. Just because this is not entirely possible today, doesn't mean that it won't be tomorrow.

I'm of the opinion that this goal is unachievable with the current tech generation, and that the bubble will burst soon unless another breakthrough is reached. In the meantime, your own skills will continue to atrophy the more you rely on this tech, instead of on your own intellect.

Re: Breaking the spell of vibe coding

#55

Post by nkmnz » Sat, Feb 14, 2026, 11:20 PM UTC

softwaredoug wrote: post #36

nkmnz wrote: post #32

> A study from METR found that when developers used AI tools, they estimated that they were working 20% faster, yet in reality they worked 19% slower. That is nearly a 40% difference between perceived and actual times! It’s not. It’s either 33% slower than perceived or perception overestimates speed by 50%. I don’t know how to trust the author if stuff like this is wrong.

Isn't the study a year old by now? Things have evolved very quickly in the last few months.

Yes. No agents, no deep research, no tools, and just Sonnet-3.5 and 3.7 - I’d love to see the same study today with Opus-4.6 and Codex-5.3

Re: Breaking the spell of vibe coding

#56

Post by skydhash » Sat, Feb 14, 2026, 11:21 PM UTC

bikelang wrote: post #4

Kerrick wrote: post #3

> However, it is important to ask if you want to stop investing in your own skills because of a speculative prediction made by an AI researcher or tech CEO. I don't think these are exclusive. Almost a year ago, I wrote a blog post about this [0]. I spent the time since then both learning better software design and learning to vibe code. I've worked through Domain-Driven Design Distilled , Domain-Driven Design , Imple…

Of those 3 DDD books - which did you find the most valuable?

Not GP, but the most impactful one I read was Learning DDD from O’Reilly

https://www.amazon.com/Learning-Domain-Driven-Design-Alignin...

It presents the main concepts like a good lecture and a more modern take than the blue book. Then you can read the blue book.

But DDD should be taken as a philosophy rather than a pattern. Trying to follow it religiously tends to results in good software, but it’s very hard to nail the domain well. If refactoring is no longer an option, you will be stuck with a non optimal system. It’s more something you want to converge to in the long term rather than getting it right early. Always start with a simpler design.

Re: Breaking the spell of vibe coding

#57

Post by skydhash » Sat, Feb 14, 2026, 11:22 PM UTC

claudeomusic wrote: post #48

I think a big part of this discussion lost for a lot is a lot of people are trying to copy/paste how we’ve been developing software over the past twenty years into this new world which simply doesn’t work effectively. The differences are subtle but those of us who are fully bought in (like myself) are working and thinking in a new way to develop effectively with LLMs. Is it perfect? Of course not - but is it dramatic…

What are such new ways? You’re being very vague about them.

Re: Breaking the spell of vibe coding

#58

Post by samename » Sat, Feb 14, 2026, 11:22 PM UTC

logicprog wrote: post #42

samename wrote: post #28

The addiction aspect of this is real. I was skeptical at first, but this past week I built three apps and experienced issues with stepping away or getting enough sleep. Eventually my discipline kicked in to make this a more healthy habit, but I was surprised by how compelling it is to turn ideas into working prototypes instantly. Ironically, the rate limits on my Claude and Codex subscriptions helped me to pace mysel…

Isn't struggling to get enough sleep or shower enough and so on because you're so involved with the process of, you know, programming, especially interactive, exploratory programming with an immediate feedback loop, kind of a known phenomenon for programmers since essentially the dawn of interactive computing?

Using agents trigger different dopamine patterns, I'd compare it to a slot machine: did it execute it according to plan or did it make a fatal flaw? Also, multiple agents can run at once, which is a workflow for many developers. The work essentially doesn't come to a pausing point.

Re: Breaking the spell of vibe coding

#59

Post by ncruces » Sat, Feb 14, 2026, 11:23 PM UTC

fnordpiglet wrote: post #9

altcunn wrote: post #6

[dead]

Fascinating - I find the opposite is true. I think of edge cases more and direct the exploration of them. I’ve found my 35 years experience tells me where the gaps will be and I’m usually right. I’ve been able to build much more complex software than before not because I didn’t know how but because as one person I couldn’t possibly do it. The process isn’t any easier just faster. I’ve found also AI assisted stuff is…

> I’ve found also AI assisted stuff is remarkable for algorithmically complex things to implement.

AI is really good to rubber duck through a problem.

The LLM has heard of everything… but learned nothing. It also doesn't really care about your problem.

So, you can definitely learn from it. But the moment it creates something you don't understand, you've lost control.

You had one job.

Re: Breaking the spell of vibe coding

#60

Post by atleastoptimal » Sat, Feb 14, 2026, 11:23 PM UTC

reppap wrote: post #49

atleastoptimal wrote: post #44

That AI would be writing 90% of the code at Anthropic was not a "failed prediction". If we take Anthropic's word for it, now their agents are writing 100% of the code: https://fortune.com/2026/01/29/100-percent-of-code-at-anthro... Of course you can choose to believe that this is a lie and that Anthropic is hyping their own models, but it's impossible to deny the enormous revenue that the company is generating via th…

One thing I like to think about is: If these models were so powerful why would they ever sell access? They could just build endless products to sell, likely outcompeting anyone else who needs to employ humans. And if not building their own products they could be the highest value contractor ever. If you had midas touch would you rent it out?

Well there are models that Anthropic, OpenAI and co. have access to that they haven't provided public API's for, due to both safety, and what you've cited as the competitive advantage factor. (like Openai's IMO model, though it's debatable if it represented an early version of GPT 5.1/2/3 or something else)

https://sequoiacap.com/podcast/training-data-openai-imo/

The thing however is the labs are all in competition with each other. Even if OpenAI had some special model that could give them the ability to make their own Saas and products, it is more worth it for them to sell access to the API and use the profit to scale, because otherwise their competitors will pocket that money and scale faster.

This holds as long as the money from API access to the models is worth more than the comparative advantage a lab retains from not sharing it. Because there are multiple competing labs, the comparative advantage is small (if OpenAI kept GPT-5.X to themselves, people would just use Claude and Anthropic would become bigger, same with Google).

This however may not hold forever, it is just a phenomena of labs focusing more on heavily on their models with marginal product efforts.