Vibe engineering • Hacker News Board

Re: Vibe engineering

#461

Post by joenot443 » Wed, Oct 08, 2025, 1:08 PM UTC

hollowturtle wrote: post #454

krschacht wrote: post #450

Earlier quoted context omitted.

You aren’t entertaining the possibility that some experienced engineerings are using these tools to produce incredibly high quality code, while still massively increasing productivity. With good prompting and “vibe engineering” practices, I can assure you: the code I get Claude Code to produce is top notch.

I'm experienced, I don't accept the implication that I might not be able to use these tools are their full potential and you won't convince me only because you mention an anecdotical example

Have you used the tools to their full potential?

Re: Vibe engineering

#462

Post by blibble » Wed, Oct 08, 2025, 1:08 PM UTC

simonw wrote: post #392

llamatastic wrote: post #365

Earlier quoted context omitted.

I really don't get the idea that LLMs somehow create value. They are burning value. We only get useful work out of them because they consume past work. They are wasteful and only useful in a very contrived context. They don't turn electricity and prompts into work, they turn electricity, prompts AND past work into lesser work. How can anyone intellectually honest not see that? Same as burning fossil fuels is great an…

> How can anyone intellectually honest not see that? The idea that they can only solve problems that they've seen before in their training data is one of these things that seems obviously true, but doesn't hold up once you consistently use them to solve new problems over time. If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two ext…

> If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two extremely well regarded academic competitions this year: the International Math Olympiad (IMO) and the International Collegiate Programming Contest (ICPC).

it's not a fair comparison

the competitions for humans are a display of ingenuity and intelligence because of the limited resources available to them

meanwhile for the "AI", all it does is demonstrate is that if you have a dozen billion dollar data-centres and a couple of hundred gigawatt hours, which can dedicate to brute-forcing a solution, then you can maybe match the level of one 18 year old, when you have a problem with a specific well known solution

(to be fair, a smart 18 year old)

and short of moores law lasting another 30 years, you won't be getting this from the dogshit LLMs on shatgpt.com

Re: Vibe engineering

#463

Post by simonw » Wed, Oct 08, 2025, 1:10 PM UTC

cbeach wrote: post #439

hi Simon - just a note to say that your link to https://tools.simonwillison.net/ goes to https://simonwillison.net/ Think this might be a typo

Thanks, fixed that.

Re: Vibe engineering

#464

Post by JamesSwift » Wed, Oct 08, 2025, 1:10 PM UTC

Otek wrote: post #453

What’s the point of this kind of division? Should developers who use JetBrains instead of Vim be called something different too? Or if one person uses Google and another relies on a book, are they somehow different kinds of engineers? What are we actually trying to achieve with this distinction? Vibe coder is not engineer because the person doing it doesn’t really interact with the code. But the tools a professional…

The distinction is specifically because its not about the tooling differences, its about the mindset and workflow. "Vibe coding" is a dirty word. It comes with an assumption of YOLO'ing until something maybe kind of works. "Vibe engineering " is the complete opposite side of the spectrum - high-touch, high-engagement management of the AI agents, often with a specific plan or design in mind that you are working toward. I agree we need a different word for it but I dont like "vibe engineering".

Re: Vibe engineering

#465

Post by perlgeek » Wed, Oct 08, 2025, 1:11 PM UTC

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…

It kinda feels like you turn from a software engineer to an offshoring manager.

Offshoring software development means letting lower-payed software developers from somewhere far away do the actual programming, but they have a very different culture than you, and they typically don't share your work context, don't really have a feeling for how the software is used -- unless you provide that.

Now we're offshoring to non-sentient, mostly stateless instances of coding agents. You still have to learn how to deal with them, but you're not learning about a real human culture and mindset, you learn about something that could be totally changed with the next release of the underlying model.

Re: Vibe engineering

#466

Post by pron » Wed, Oct 08, 2025, 1:11 PM UTC

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 not sure that having the patience to work with something with a very inconsistent performance and that frequently lies is an extension of existing development skills. It doesn't work like tools developers use and it doesn't work like people developers work with. Furthermore, techniques of working with agents today may be completely outdated a year from now. The acceleration is also inconsistent: sometimes there's an acceleration, sometimes a deceleration.

Generative AI is at the same time incredibly impressive and completely unreliable. This makes it interesting, but also very uncertain. Maybe it's worth my investment to learn how to master today's agents, and maybe I'd be better off waiting until these things become better.

You wrote:

> Getting good results out of a coding agent feels uncomfortably close to getting good results out of a human collaborator. You need to provide clear instructions, ensure they have the necessary context and provide actionable feedback on what they produce.

That is true (about people) but misses out the most important thing for me: it's not about the information I give them, but about the information they give me. For good results, regardless of their skill level, I need to absolutely trust that they tell me what challenges they've run into and what new knowledge they've gained that I may have missed in my own understanding of the problem. If that doesn't happen, I won't get good results. If that kind of communication only reliably happens through code I have to read, it becomes inefficient. If I can't trust an agent to tell me what I need to know (and what I trust when working with people) then the whole experience breaks down.

Re: Vibe engineering

#467

Post by rhetocj23 » Wed, Oct 08, 2025, 1:11 PM UTC

oblio wrote: post #435

rhetocj23 wrote: post #369

Earlier quoted context omitted.

Very curious to hear responses about this too

The problem with this is that software engineering is a very unorganized and fashion/emotion driven domain. We don't have reliable productivity numbers for basically... anything. I that I'm more productive with statically typed languages but I haven't seen large scale, reliable studies. Same with unit tests, integration tests, etc. And then there are all the types of software engineering: web frontend, web API, mobil…

Yeah I agree.

A controlled experiment done with a representative sample would be lovely. In the long-run it comes down to the financial impact that occurs incrementally because of LLMs.

In the short-run, from what I see, firms are trying to play-up the operational efficiency gains they have achieved. Which then signals promise to investors in the stock market, for which, investors then translate this promise into expectations about the future which are then reflected in the present value of equity.

But in reality it seems to be reducing head-count because they over-hired before the hype and furore of LLMs.

Re: Vibe engineering

#468

Post by simonw » Wed, Oct 08, 2025, 1:11 PM UTC

throw219080123 wrote: post #432

simonw wrote: post #392

Earlier quoted context omitted.

> How can anyone intellectually honest not see that? The idea that they can only solve problems that they've seen before in their training data is one of these things that seems obviously true, but doesn't hold up once you consistently use them to solve new problems over time. If you won't accept my anecdotal stories about this, consider the fact that both Gemini and OpenAI got gold medal level performance in two ext…

> consider the fact that both Gemini and OpenAI got gold medal level performance Yet ChatGPT 5 imagines API functions that are not there and cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub.

Which is why you run it in a coding agent loop using something like Codex CLI - then it doesn't matter if it imagines a non-existent function because it will correct itself when it tries to run the code.

Can you expand on "cannot figure out basic solutions even when pointed to the original source code of libraries on GitHub"? I have it do that all the time and it works really well for me (at least with modern "reasoning" models like GPT-5 and Claude 4.)

Re: Vibe engineering

#469

Post by JamesSwift » Wed, Oct 08, 2025, 1:11 PM UTC

cadamsdotcom wrote: post #120

A better term is agentic coding, agentic software engineering, etc. rather than being vibe based. My process starts from a Claude Code plan, whose first step is to write a spec. I use TDD, and enforce my "unspoken rules of code quality" using a slew of generated tools. One tiny tool blocks code which violates our design system. Another tool blocks code which violates our separation of layering - this forces the HTTP…

I spent some time trying to think of a better term because I also think "vibe" detracts from the intent, and I think you nailed it with "agentic coding". Ill do my part by using that term now, hopefully it catches on : D

Re: Vibe engineering

#470

Post by athrowaway3z » Wed, Oct 08, 2025, 1:15 PM UTC

hollowturtle wrote: post #294

I don't get the obsession some tech people have to push the idea that this stuff accelerate your coding, increase your productivity. It's all about fast and faster output. In my experience LLMs have mostly produced gibberish oververbose code, surely faster than me, but my lower speed usually produce better code. I don't like this present state of things where we need to chat faster to quickly get out results and go f…

You see a large % of failures, but you're drawing an unsupported conclusion.

We all agree, the people that _feel_ the most productivity spike are the sub-par engineers. That shouldn't be controversial, and it's even predictable. But their volume can't be taken as an argument one way or the other.

The question is, are there _any_ good engineers that don't just feel more productive, but objectively are.