Most active commenters
  • cortesoft(3)

←back to thread

129 points Varun08 | 30 comments | | HN request time: 0.608s | source | bottom
1. cramsession ◴[] No.45190469[source]
The trick is that you have to be a good coder to get the most out of "vibe" coding. It works great for me, but I deploy all of the knowledge I've acquired over the decades as a professional developer. You need to know how to architect systems, what data structures and algorithms to ask for, how to design a product, many facets of graphic and user interface design, how to parcel out work, how to parallelize tasks. Even which ideas are worth pursuing is an intuition you build up over years. "Vibe" coding really is magic and I'm highly scaled, but I don't see how it could possibly work for all but the most senior developers. In some sense, it's like writing LISP macros on steroids.
replies(10): >>45190657 #>>45190885 #>>45191035 #>>45191109 #>>45191139 #>>45191169 #>>45191530 #>>45191570 #>>45192419 #>>45196027 #
2. cmrdporcupine ◴[] No.45190657[source]
Absolutely. It's augmentation not automation, it does what I want or it gets the hose again.

You make the framework and it colours in the lines. If you don't draw the pattern first you're going to get a kindergarten mess. There are times I'm amazed by its suggestions but it will also cheat and "lie" and if you're not paying attention, you'll miss it.

But these days many tasks for me consist of: I need this, look how I did it here before, and follow this exact pattern through to the end and write tests, too. And the results are usually exactly what I would have done. Because it is an excellent mimic. But if I hadn't put the work into the framework, it would be awful.

replies(1): >>45190870 #
3. chamomeal ◴[] No.45190870[source]
It’ll cheat a lot when writing unit tests. Particularly “agentic” tools like cursor. It’ll get a test to pass, even if it’s against a laughably incorrect implementation.

I’ve ended up with tests called stuff like “foobar successfully returns impossible value that suggests programmer error” lmao

replies(2): >>45190944 #>>45191745 #
4. cortesoft ◴[] No.45190885[source]
I 100% agree that this is how the experience is right now.

I don't necessarily think it will stay this way, though. The tools are so new, we shouldn't be so sure that the future versions won't allow non-coders to code successfully.

replies(4): >>45190980 #>>45190984 #>>45191033 #>>45192734 #
5. mikeocool ◴[] No.45190944{3}[source]
My favorite thing Claude code has been doing recently is adding second totally separate implementation of whatever I asked it to write tests for, and writing the tests against that.

Conveniently, when it then changes the original implementation, the tests don’t fail!

replies(1): >>45194705 #
6. netsharc ◴[] No.45190980[source]
Isn't it a subset of "understanding".. AI as we have them currently emulates something that understands us. If you ask it to write a program, how would a non-coder know if the output of the emulated understanding is accurate enough as code, or a miss?

Reminds me of the joke:

int getRandom() {

  return 4; // chosen by a dice, guaranteed to be random

}
replies(2): >>45191079 #>>45191128 #
7. dmitrygr ◴[] No.45190984[source]
> we shouldn't be so sure that the future versions won't allow non-coders to code successfully

Care to put some money behind this fantastical claim, in a bet?

replies(1): >>45191002 #
8. cortesoft ◴[] No.45191002{3}[source]
Sure, if you granted me odds commiserate with my statement that "you can't be so sure", meaning I would get like 99-1 odds.

I wasn't saying it will certainly reach the point where non-coders can code, I am saying we can't be certain it won't just because it can't yet

replies(1): >>45191153 #
9. johnnyanmac ◴[] No.45191033[source]
Reality is often disappointing. The reality is that this is sold to people who don't know how to code as a way to code. Even if the theory is that an engineer can make the best use of it (whether or not it helps is another debate).
10. dingnuts ◴[] No.45191035[source]
What you're describing is not vibe coding. I realize some people call anything with an LLM generating code "vibe coding" but it's not and I'm going to die on this hill.

1 it's not the meaning Karpathy used originally, which was for creating software through prompts WITHOUT looking at the source code

2 it's not the meaning people outside programming circles mean, either, which is identical to Karpathy's original definition

the title of the article is talking about 2 and is completely correct.

YOU, on the other hand, are talking about an upgrade to IntelliSense. Use a different term. You're describing regular programming, with a new IDE tool.

If it's not going to replace programmers and allow regular people to create software without looking at the code, it's not vibe coding. Full stop.

replies(1): >>45191118 #
11. latexr ◴[] No.45191079{3}[source]
> Reminds me of the joke

Source: https://xkcd.com/221/

12. captainkrtek ◴[] No.45191109[source]
I think this is spot on and aligns with my experience.

I've seen less experienced devs crash and burn trying to commit massive amounts of vibe coded slop without consideration to: how much of it was necessary? how does it conform with our code base / style? how much does it take advantage of existing code and patterns? and so on.

I think if you are using one of these tools and experienced, it should be difficult to tell you are using one at all. The code I produce looks like stuff I would write, and I understand all it wrote, I don't want to outsource to producing tons of code that I don't even understand.

13. JimDabell ◴[] No.45191118[source]
Amen. The difference is vast when it comes to discussions like this.

If you’re talking about AI-assisted development, then an AI agent being able to do 80% of the work is a fantastic win. The developer can pick up the remaining 20% and come out massively ahead.

If you’re talking about vibe-coding, then an AI agent being able to do 80% of the work is useless. What’s a non-developer going to do with something that still has 20% of the development left to do? It’s not 80% useful, it’s 0% useful.

14. JSteph22 ◴[] No.45191128{3}[source]
>how would a non-coder know if the output if the emulated understanding is accurate

QA for non-AI code is limited at best to begin with, why would AI code be any different?

15. artursapek ◴[] No.45191139[source]
This has been my experience. I only have 12 years under my belt, but I've had a lot of good results using Claude Code/Cursor agent since this May. You have to know what questions to ask, how to mold the requirements with the agent, what to tell it to do. I treat it like an employee I'm pairing with. My productivity is at a new level.
16. dmitrygr ◴[] No.45191153{4}[source]
1:1 odds, but i'll give you a huge (tech-wise) time horizon of, say, 3 years?
replies(2): >>45192816 #>>45199371 #
17. idopmstuff ◴[] No.45191169[source]
It really depends what you're coding. I'm a former PM who can't code, and I'm currently using GPT-5 in Cursor to write an internal application for my business of acquiring and operating e-commerce brands that sell on Amazon. I'm really vibe coding (just clicking accept without ever reading any of the code changes), and it's working great! I've got a whole dashboard that's retrieving inventory and sales data from multiple Amazon stores, projecting future sales and reorder point, etc. The code might be total dogshit, but it's incredibly useful for me (and also really enjoyable).

That said I might be sort of a weird case, since I am accustomed to designing and documenting product requirements, the fact that it's just for me means architecture doesn't really matter, and I'm competent enough to help it resolve some design problems like the fact that it was obviously hitting the wrong Amazon API that was pulling a report of every single sale as a line item rather than just a report with total sales numbers, etc.

replies(1): >>45193984 #
18. dorcy ◴[] No.45191530[source]
I was able to teach my interns more about architectural designs instead of coding. Teaching them more about DDD instead of going through what’s broken with this function. We might be close to a point where you can teach product people about these basic concepts, packages and saas tools, and have them vibe code a whole app.
19. hellisothers ◴[] No.45191570[source]
“You need to know…” do you need to know though? I agree I need to know the things to work in a mature codebase or make something maintainable in the long run but to bang out a get rich quick project? Probably not.
20. cmrdporcupine ◴[] No.45191745{3}[source]
Yeah, or "bug was pre-existing and not my fault so shrug, here's a TODO and we'll just say it passed" (not those exact words, but close)
replies(1): >>45191961 #
21. csar ◴[] No.45191961{4}[source]
“70% of tests pass. This codebase is ready for production!”
22. actsasbuffoon ◴[] No.45192419[source]
Completely agreed. I’ve got about 20 years of professional software development experience. Tools like Claude Code let me build incredibly quickly when I use a stack I know intimately.

But when I try it with a stack I don’t know, I quickly find myself needing to learn the new stack to get anything done.

Extremely experienced engineers will be able to move quickly with these tools, but specialization will still exist, and I’m not clear on how juniors are going to ramp up on all of this.

It’s funny you should mention LISP macros. Five years ago, I’d have told you that the most efficient way to build something is to get an extremely experienced dev with mastery over a flexible language like LISP, and just let them go nuts. I constantly have to hold myself back from metaprogramming tricks because my coworkers won’t be able to maintain it. But on my personal projects, I really get to flex my muscles.

It occurred to me a few months ago that that’s exactly the same spot in my toolbox where Claude Code is. It’s a tool that allows one person with mastery of a tech stack to build things incredibly quickly. Look at Cursor where a tiny team has over $100M in annualized revenue.

Big companies often find themselves spreading ownership across too many hands. You know exactly how to build what you need, but you’re not allowed to touch 80% of the code involved because it belongs to a different team. But coordinating all of that is a massive amount of overhead that will derail most projects. This is why so little happens at big companies.

But these tools enable a smaller number of experts to do a job that used to take many. I expect the speed improvements to be super-linear as a result.

Of course, that brings concerns about what happens to the employment situation for devs if that happens. I hope it means that 10,000 new startups can build more ambitious products and absorb all the people who will probably be laid off by the huge corps in the next few years.

23. actsasbuffoon ◴[] No.45192734[source]
I disagree, at least for the next 5 years or so.

Even with humans, it’s very common to ask them for something and get something back that’s completely different than what you wanted. Short of reading your mind, AI is going to require a lot of info to get the desired result.

So someone is going to have to gather requirements and break them down into a clear, well thought out set of instructions for the computer. That’s literally what programmers already do. We’re just programming in a different language now.

replies(1): >>45194115 #
24. anon22981 ◴[] No.45192816{5}[source]
Since you are only willing to go for 1:1 odds with a 3 year timeframe, I assume you are in agreement that it might happen? Otherwise I’m sure you would give him better odds with a larger timeframe :)
25. simianwords ◴[] No.45193984[source]
Vibe coding helps people “bring their own UI”
26. sixtyj ◴[] No.45194115{3}[source]
In the past, we depended on editors that were easy to switch. Now coders are becoming dependent on tools that are hard to switch off.

And I’ve realized that even when I try to stay in control, I often don’t read the output code—I just copy and paste.

Metaphorically, it’s like pilots who know how to use the autopilot, but can’t switch back to manual control. That’s the generation of coders we’re raising.

27. queenkjuul ◴[] No.45194705{4}[source]
This is just about the only type of test i see it write lol
28. level09 ◴[] No.45196027[source]
But is it really vibe coding if you’re carefully building step by step and checking everything along the way? I feel like the kind of vibe coding people usually mean is more about blindly iterating until things work and patching bugs as they pop up—where you eventually get an app that runs, but it’s so messy that even a senior dev would struggle to audit or fully understand it.
replies(1): >>45198584 #
29. cramsession ◴[] No.45198584[source]
The truth is I don't check everything along the way! That's part of my high scale, I can now work on a dozen projects instead of a couple because I'm freed up from having to read all of the code. A huge shift in mindset for sure, but it's been working great.
30. cortesoft ◴[] No.45199371{5}[source]
Ha, no I am thinking more like 10-20 years, or maybe even longer. But I know from experience that 10-20 years goes by faster than you think.