Live data from Hacker News

Vibe engineering

simonwillison.net

541–550 of 759 posts

Re: Vibe engineering

#541
post #522
post #504

Earlier quoted context omitted.

Test-driven development helps protect against wrong code, but it's not code I'm interested in, and it's not wrong code that I'm afraid of (I mean, that's table stakes). What I need is something that would help me generate understanding and do so reliably (even if the performance is poor). I can't exercise high-level knowledge efficiently if my only reliable input is code. Once you have to work at the code level at ev…

Without meaning to sound flippant or dismissive, I think you're overthinking it. By the sounds of it, agents aren't offering what you say you need. What are _are_ offering is the boilerplate, the research, the planning etc. All the stuff that's ancillary. You could quite fairly say that it's in the pursuit of this stuff where details and ideas emerge and I would agree, but sometimes you don't need ideas. You need sol…

I'm well aware that LLMs are more than capable enough to successfully perform straightforward, boring tasks 90% of the time. The problem is that there's a small but significant enough portion of time where I think a problem is simple and straightforward, but it turns out not to be once you get into the weeds, and if I can't trust the tool to tell me if we're in the 90% problem or the 10% problem, then I have to carefully review everything.

I'm used to working with tools, such as SMT solvers, that may fail to perform a task, but they don't lie about their success or failure. Automation that doesn't either succeed or report a failure reliably is not really automation.

Again, I'm not saying that the work done by the LLM is useless, but the tradeoffs it requires make it dramatically different from how both tools and humans usually operate.

Re: Vibe engineering

#542

I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it so…

I feel the opposite. I get to sit down and think about problems, expressing them in words as best I can, and then review the code, make sure that I understand it and it works as it should, all in a fraction of the time it used to take me. I like that I don't have to google APIs as much as I did before, and instead I can get a working thing much faster.

I can focus on actually solving problems rather than on writing clever and/or cute-looking code, which ironically also gives me more time later to over-optimize stuff at my leisure.

Re: Vibe engineering

#543
post #165

I just feel so discouraged reading this somehow. I used to have this hard-to-get, in-demand skill that paid lots of money and felt like even though programming languages, libraries and web frameworks were always evolving I could always keep up because I'm smart. But now with these people like Simon Willison writing about the new way of coding with these agents and multiple streams of work going on at a time and it so…

I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them". I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of too…

What is the other part of your goal?

Re: Vibe engineering

#544
post #168

Earlier quoted context omitted.

Absolutely this. LLM assistance means we can work faster, and that we can build things that previously weren't feasible given the available time and resources. Which makes the hardest problem in software even harder: what should we build ? It doesn't matter how fast you can move if you're consistently solving the wrong problems.

Exactly, I think one of the reasons programers are becoming so depressed over these AI agents is that they’re finally realizing that it was never really about the code, but about the outcome - and btw, this cold hard fact applies to the pre-LLM era. This occurred to me years ago when I was talking to a friend’s wife, who is a very intelligent and accomplished attorney. She was legitimately surprised when I explained…

I do think code-as-craft should be respected in its own right. I'm very much a craftsman coder. It makes sense how I could clock so many hours over all these years.

But what I do "at work" isn't the same as my personal pursuit and embracing that different framing positively has made me more at peace and also better at the work job.

Re: Vibe engineering

#545
post #145

Earlier quoted context omitted.

Disagree, I think vibe coders should become synonymous with no-code and continue to be somewhat of a pejorative. I don't like the term vibe engineer, but do agree there needs to be a term to signifiy the difference. It's also possible in the future just being called a developer/engineer already implies you use coding agents and the people who do it "by hand" will not be the norm.

Seems you can't go anywhere these days without walking into an argument between a descriptivist and a prescriptivist.

Yes, it's not like the ole days when nobody argued semantics

Re: Vibe engineering

#546
post #175

Earlier quoted context omitted.

At $enterprise, we were just looking for a proper term that sets "responsible vibing" apart from "YOLO vibe coding". We landed on "agent assisted coding". It's a bit more technical. And it has a three-letter acronym. Gotta have a three letter acronym.

I really like "agent assisted coding". I think the word "vibe" is gonna always swing in a yolo direction, so having different words is helpful for differentiating fundamentally different applications of the same agentic coding tools.

abbreviation ass.coding.

Re: Vibe engineering

#547

As always, Simon knows what he is talking about and neatly describes the whole situation. However, it's not the "coding" part of "vibe coding" that is the (semantic) problem, it's the "vibe" part. Replacing "coding" with engineering, but keeping the "vibe" part, still conveys the meaning of not really knowing what you do, but now in an even larger surface area. It's a lot more boring, but I'm fine with "AI-assisted s…

Simon is a salesman. Obviously he knows how to phrase things.

Re: Vibe engineering

#548
post #165

Earlier quoted context omitted.

I'm really sorry to hear this, because part of my goal here is to help push back against the idea that "programming skills are useless now, anyone can get an LLM to write code for them". I think existing software development skills get a whole lot more valuable with the addition of coding agents. You can take everything you've learned up to this point and accelerate the impact you can have with this new family of too…

What is the other part of your goal?

Sparking more conversations about practices that work for doing serious production-quality software development with LLMs, especially in larger teams and on larger projects.

Having a good counter to people who use "vibe coding" as a dismissive term for anything where an LLM is used to help product software.

Re: Vibe engineering

#549

As always, Simon knows what he is talking about and neatly describes the whole situation. However, it's not the "coding" part of "vibe coding" that is the (semantic) problem, it's the "vibe" part. Replacing "coding" with engineering, but keeping the "vibe" part, still conveys the meaning of not really knowing what you do, but now in an even larger surface area. It's a lot more boring, but I'm fine with "AI-assisted s…

Simon is a salesman. Obviously he knows how to phrase things.

I wish I was! I'm pretty terrible at sales. It's a skill I respect and do not have.

Re: Vibe engineering

#550
post #136
post #124

Earlier quoted context omitted.

> They choke on anything that isn’t a greenfield project and consistently produce unwanted results. That was true 8 months ago. It's not true today, because of the one-two punch of modern longer-context "reasoning" models (Claude 4+, GPT-5+) and terminal-based coding agents (Claude Code, Codex CLI). Setting those loose an an existing large project is a very different experience from previous LLM tools. I've watched C…

I guess we just have to take your word for this, which is somewhat odd considering most of your comments link back to some artifact of yours. Are you paid by any of these companies?

https://github.com/bodo-run/yek/pull/213

here is an example of mostly automated work. It's a small feature but it was done perfectly

Post reply on HN