Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vibe engineering

simonwillison.net

Post reply on HN
Print view View original

401–410 of 759 posts

Re: Vibe engineering

#401

Post by simonw »

input_sh wrote: post #200
simonw wrote: 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…

> Your carefully curated AGENTS.md is only really useful at the very beginning of the conversation, but the longer the conversation gets, the less important those tokens on the top are.

If that's genuinely causing you problems you can restart your session frequently to avoid the context rot.

Re: Vibe engineering

#402

Post by port3000 »

subarctic wrote: post #151

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…

Honestly based on what you've written I don't think you would enjoy sales any more

Re: Vibe engineering

#403

Post by ManuelKiessling »

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 software engineering" as the other-end-of-the-spectrum name opposite of "vibe coding".

Re: Vibe engineering

#404

Post by rhetocj23 »

benterix wrote: post #386
executesorder66 wrote: post #368

Earlier quoted context omitted.

Tell that to Linus Torvalds. His whole job is just doing code review, and I'd argue he's better at coding now than he ever was before.

I'd be careful with extrapolating based on the creator of Linux and Git. His life and activities are not in line with those of more typical programmers.

Yeah exactly… hardly comparable to the median or mean dev

Re: Vibe engineering

#405

Post by eugmill »

bartread wrote: post #347
afro88 wrote: post #316

Earlier quoted context omitted.

At least on a team, the limit is the team's time to review all the code. We've also found that vibe engineered (or "supervised vibing" as I call it) code tends to have more issues in code review because of a false sense of security creating blind spots when self reviewing. Even more burden on the team. We're experimenting with code review prompts and sub agents. Seems local reviews are best, so the bulk of the burden…

Do you have a sense for how much overhead this is all adding? Or, to put it another way, what I’m really asking is what productivity gain (or loss) are you seeing versus traditional engineering?

Isn't the current state of thing such that it's really hard to tell? I think the METR study showed that self-reported productivity boosts aren't necessarily reliable.

I have been messing with vibe engineering on a solo project and I have such a hard time telling if there's an improvement. It's this feeling of "what's faster, one lead engineer coding or one lead engineer guiding 3 energetic but naive interns"?

Re: Vibe engineering

#406

Post by mixologist »

subarctic wrote: post #151

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…

Be mindful of the context these posts are created in. Don't take the current echo chamber to heart.

For decades now, we are trying to lower the barrier to entry in software development. We created Python, web frameworks and mobile development so easily accessible that you can become software developer by completing a short online boot camp. There is a lot of software developers posting here now who, 20 years ago, would not even consider this job because it would be way over their abilities.

This forum is equivalent if you had a forum about civil transportation that gathers airline pilots and uber drivers. Technically, they both do the same work. Just like in that forum, uber drivers would outnumber airline pilots and skew the topics related to their experience, here we get pushed topics about new frameworks, and AI assisted tools.

When I started working professionally 20 years ago, you could only get job in big companies working on big projects. No one else could afford a cost of custom software. Today, we reduced development costs and we have a huge pool of potential customers who can now afford services of software developers. Web shops, gambling sites, porn sites... This is the majority of software development work today. Boring repetitive tasks of gluing some imported modules together.

Serious development work didn't disappear. It is just not talked about here. There is still a need people who know what they are doing.

My advise is that if you want a satisfying development career, steer clear of latest hypes and don't go blindly following techbro lemmings. And most importantly, don't take career advice from anyone who finds his job so unsatisfying and tedious that he is trying to make AI do it for him. That's a major red flag.

Re: Vibe engineering

#407

Post by lossolo »

bartread wrote: post #347
afro88 wrote: post #316

Earlier quoted context omitted.

At least on a team, the limit is the team's time to review all the code. We've also found that vibe engineered (or "supervised vibing" as I call it) code tends to have more issues in code review because of a false sense of security creating blind spots when self reviewing. Even more burden on the team. We're experimenting with code review prompts and sub agents. Seems local reviews are best, so the bulk of the burden…

Do you have a sense for how much overhead this is all adding? Or, to put it another way, what I’m really asking is what productivity gain (or loss) are you seeing versus traditional engineering?

In our experience, it depends on the task and the language. In the case of trivial or boilerplate code, even if someone pushes 3k-4k lines of code in one day, it's manageable because you can just go through it. However, 3k lines of interconnected modules, complex interactions, and intricate logic require a lot of brainpower and time to review properly and in most cases, there are multiple bugs, edge cases that haven't been considered, and other issues scattered throughout the code.

Re: Vibe engineering

#408

Post by simonw »

MintsJohn wrote: post #397
simonw wrote: 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…

Of course the devil is in the details. What you say and the skills needed make sense. It's unfortunately also the easiest aspects to dismiss either under pressure as there is often little immediate payoff, or because it's simply the hard part. My experience with llms in general is that sadly, they're mostly good bullshitters. (current google search is the epitome of worthlessness, the AI summary so hard tries to make…

Google's "AI overviews" are one of the worst LLM-powered features on the market today, they're genuinely damaging the reputation of the whole industry.

Meanwhile I've started using ChatGPT GPT-5 search as my default search engine! A year ago I would have laugher at the idea: https://simonwillison.net/2025/Sep/6/research-goblin/

And Google themselves have an "AI mode" which is a different league of quality from "AI overviews", I wrote about that one here: https://simonwillison.net/2025/Sep/7/ai-mode/

This is new. AI search tools almost universally sucked until OpenAI's release of o3 in April this year.

Re: Vibe engineering

#409

Post by PeterStukalov »

hu3 wrote: post #394

Can anyone suggest solution(s) to create temporary preview environments per branch or Pull Request? For example if someone creates a Pull Request "#2122 feat: User password change" Automation would deploy it to pr_2122_feat_user_password_change.mycompany.com

[dead]

Re: Vibe engineering

#410

Post by justbees »

simonw wrote: post #165
subarctic wrote: post #151

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…

I'm getting really great results in a VERY old (very large) codebase by having discussion with the LLM (I'm using Claude code) and making detailed roadmaps for new features or converting old features to new more useable/modern code. This means FE and BE changes usually at the same time.

I think a lot of the points you make are exactly what I'm trying to do.

- start with a detailed roadmap (created by the ai from a prompt and written to a file)

- discuss/adjust the roadmap and give more details where needed

- analyze existing features for coding style/patterns, reusable code, existing endpoints etc. (write this to a file as well)

- adjust that as needed for the new feature/converted feature - did it miss something? Is there some specific way this needs to be done it couldn't have known?

- step through the roadmap and give feedback at each step (I may need to step in and make changes - I may realize we missed a step, or that there's some funky thing we need to do specifically for this codebase that I forgot about - let the LLM know what the changes are and make sure it understands why those changes were made so it won't repeat bad patterns. i.e. write the change to the .md files to document the update)

- write tests to make sure everything was covered... etc etc

Basically all the things you would normally WANT do but often aren't given enough time to do. Or the things you would need to do to get a new dev up to speed on a project and then give feedback on their code.

I know I've been accomplishing a lot more than I could do on my own. It really is like managing another dev or maybe like pair programming? Walk through the problem, decide on a solution, iterate over that solution until you're happy with the decided path - but all of that can take ~20 minutes as opposed to hours of meetings. And the end result is factors of time less than if I was doing it on my own.

I recently did a task that was allotted 40 hours in less than 2 working days - so probably close to 10-12 hours after adjusting for meetings and other workday blah blah blah. And the 40 hour allotment wasn't padded. It was a big task, but doing the roadmap > detailed structure including directory structure - what should be in each file etc etc cut the time down dramatically.

I would NOT be able to do this if I the human didn't understand the code extremely well and didn't make a detailed plan. We'd just end up with more bad code or bad & non-working code.

Post reply on HN