Live data from Hacker News

Vibe engineering

simonwillison.net

231–240 of 759 posts

Re: Vibe engineering

#231

Earlier quoted context omitted.

If you're using LLMs for a large number of arithmetic calculations, you're exactly the problem GP is talking about. If you absolutely must use AI get it to generate code that will perform the calculations instead, so that you can actually verify the result.

You're straining very hard to make your position sound reasonable, but your assumption that I both can't verify the values of the winning combination and wouldn't verify those values is simply not true. In the example I cited, verifying a ratio isn't the hard part. It's running the dozens of permutations (smart) or hundreds of permutations (naive) that an LLM can do in 90 seconds that saves me hours of boring work. I…

> I both can't verify the values of the winning combination and wouldn't verify those values is simply not true.

You have not met my cow orkers...

Re: Vibe engineering

#232
post #180

Earlier quoted context omitted.

I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this: 1. Collaborate on a detailed spec 2. Have it implement that spec 3. Spend a lot of time on review and QA - is the code good? Does the feature work well? 4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar That last step is t…

I don't buy your last sentence at all. AGENTS.md is just a place to put stuff you don't want to tell LLMs over and over again. They're not magical instructions LLMs follow 100% of the time, they don't carry any additional importance over what you put into the prompt manually. Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the les…

We really should be sharing wisdom about AGENTS.md files here.

Re: Vibe engineering

#233

Earlier quoted context omitted.

Can we all agree that "mentoring" LLMs is actually a waste of time, please? The reason we invest this time in Junior devs is so they improve. LLMs do not

> Can we all agree that "mentoring" LLMs is actually a waste of time, please? Sorry, we can't. While it's true that you can't really modify the underlying model, updating your AGENTS.md (or whatever) with your expected coding style, best practices, common gotchas etc is a type of mentoring.

Maybe we need an Ask HN to share AGENTS.md files.

Re: Vibe engineering

#234

Earlier quoted context omitted.

Can we all agree that "mentoring" LLMs is actually a waste of time, please? The reason we invest this time in Junior devs is so they improve. LLMs do not

"AI" has been so inconsistent. On one day it anticipates almost every line I am coding, the next day it's like we've never worked together before.

I see you've never dated twins.

Re: Vibe engineering

#236
post #145
post #134

I think we should just accept that vibe-coding has now semantically shifted to mean all AI-assisted coding. Actually, it makes sense to me even when a human is interacting directly with the code, because it feels a lot like pair-programming. As such, I really am "vibing" with the AI. But then the original meaning of vibe-coding -- as in, "Take the wheel, LLama of God" -- does need a new term, because that will also b…

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.

Re: Vibe engineering

#237
post #180

Earlier quoted context omitted.

Can we all agree that "mentoring" LLMs is actually a waste of time, please? The reason we invest this time in Junior devs is so they improve. LLMs do not

I had a fascinating conversation about this the other day. An engineer was telling me about his LLM process, which is effectively this: 1. Collaborate on a detailed spec 2. Have it implement that spec 3. Spend a lot of time on review and QA - is the code good? Does the feature work well? 4. Take lessons from that process and write them down for the LLM to use next time - using CLAUDE.md or similar That last step is t…

Totally agree on this. It has delivered a substantial value for me in my projects. The models are always going to give back results optimized for using minimal computing resources in the provider's infrastructure. To overcome this I see some using/suggesting, running the AI in self correction loops, the pro being least human intervention.

However, personally I have got very good results by taking the approach of using the AI with continuous interaction and also allowing implementation only after a good amount of time deliberating on design/architecture. I almost always append 'do not implement before we discuss and finalize the design' or 'clarify your assumptions, doubts or queries before implementation'.

When I asked Gemini to give a name for such an interaction it suggested 'Dialog Driven Development' also contrasted it against 'vide coding'. Transcript summary and AI disclaimer written by Gemini below

https://gingerhome.github.io/gingee-docs/docs/ai-disclaimer.... https://gingerhome.github.io/gingee-docs/docs/ai-transcript/...

Re: Vibe engineering

#238
post #195

Earlier quoted context omitted.

So my development skills are still relevant because I need to use my managerial skills?

Managers with development skills are almost always better, because they can dive into the details if there's ever a problem.

That’s true, however the current vibe coding ecosystem is clearly not written in this mindset. You will have a hard time to dive into anything if you previously generated 2k LOC/hour, which is absolutely possible. Typing was never the bottleneck, understanding, and knowing that you did something well was always the real bottleneck. LLMs make this even worse. You can move Jira tickets to done faster with it, but even bad developers can do that many times compared to better ones, because for example they mindlessly copy-paste StackOverflow answers whose half of the code is absolutely not necessary, but they don’t care, because “it works”… until it doesn’t.

Re: Vibe engineering

#240
> One of the lesser spoken truths of working productively with LLMs as a software engineer on non-toy-projects is that it’s difficult.

I mean, the AI companies have an incentive to make it easier, right? The next iteration of coding agents will be better at working with their human PHBs to divine intent and turn vague specifications into something workable - a key skill of human engineers.

Is this really any different from how Google learned to understand search queries?

Post reply on HN