Live data from Hacker News

Vibe engineering

simonwillison.net

451–460 of 759 posts

Re: Vibe engineering

#451

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 same way. It also appears to be a lot more difficult to actually find jobs, though that's probably just the general state of the job market and less specifically AI related. All of it is thoroughly discouraging, demotivating, and every week this goes on the less I want to do it. So for me as well it might be time to try to look beyond software, which will also be difficult since software is what I've done for all my life, and everything else I can do I don't have any formal qualifications for, even if I am confident I have the relevant skills.

It's not even just that. Every single thing in tech right now seems to be AI this, AI that, and AI is great and all but I'm just so tired. So very tired. Somehow even despite the tools being impressive and getting more impressive by the day, I just can't find it in me to be excited about it all. Maybe it's just burnout I'm not sure, but it definitely feels like a struggle.

Re: Vibe engineering

#452

These seem like a lot of great ways to work around the limitations of LLMs. But I'm curious what people here think. Do any career software engineers here see more than a 10% boost to their coding productivity with LLMs? I see how if you can't really code, or you're new to a domain, then it can make a huge difference getting you started, but if you know what you're doing I find you hit a wall pretty quickly trying to…

Yes, most days I’m 2x as productive. I’m using Claude Code to produce extremely high quality code that closely follows my coding standards and the architecture of my app.

Re: Vibe engineering

#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 engineer uses for assistance shouldn’t matter at all, should they?

Re: Vibe engineering

#454

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 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

Re: Vibe engineering

#455

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…

As for flow state managing multiple things, I've found this is a useful skill to train even without AI - if you have a workplace with lots of interruptions and shifting priorities.

I've found two things useful:

1) Keep a personal work log, where you - in short bullet points - can document the progress of the task you were last working on, and can keep track of how many parallel tasks there are currently going on. If you can match it with Jira tickets, all the better, but as this is for personal use only, you can also add tasks that are not tracked in Jira at all.

2) If you cannot avoid context switches, make them explicit: Instead of trying to hold 3 tasks in your head at the same time, decide consciously if you want to switch what you're currently working on. If yes, take a few minutes to "suspend" the current task by saving and committing everything (as WIP commits if necessary) and writing all you need to remember into the worklog.

Re: Vibe engineering

#456

Earlier quoted context omitted.

I'll attempt to provide a reasonable argument for why speed of delivery is the most important thing in software development. I'll concede that I don't know if the below is true, and haven't conducted formal experiments, and have no real-world data to back up the claims, nor even define all the terms in the argument beyond generally accepted terminology. The premise of the argument therefore may be incorrect. Trivial…

>> Your slower to produce, higher quality code puts a boundary on the duration of a single feedback loop iteration. The code you produce can perfectly solve the problem as you understand it within an iteration, but cannot guarantee that your understanding of the problem is not wrong. In that sense, many lower quality iterations produces better software quality as the number of iterations approaches infinity. I'll rep…

Tech debt doesn't accrue because of fast feedback iterations. Tech debt accrues because it isn't paid down or is unrecognized during review. And like all working code, addressing it has a cost in terms of effort and verification. When the cost is too great, nobody is willing to pay it. So it accrues.

There aren't many features that you'll never touch again. There are some, but they usually don't really reach that stage before they are retired. Things like curl, emacs, and ethernet adapters still exist and are still under active development after existing for decades. Sure, maybe the one driver for an ethernet adapter that is no longer manufactured isn't very active, but adding support for os upgrades still requires maintenance. New protocols, encryption libraries and security patches have to be added to curl. emacs has to be specially maintained for the latest OSX and windows versions. Maintenance occurs in most living features.

Tools exist to produce extra productivity. Compilers are a tool so that we don't have to write assembly. High-level interpreted languages are a tool so we don't have to write ports for every system. Tools themselves are abstractions.

Software is abstractions all the way down. Everything is a stack on everything else. Including, even, the hardware. Many are old, tried and true abstractions, but there are dozens of layers between the text editor we enter our code into and the hardware that executes it. Most of the time we accept this, unless one of the layers break. Most of the time they don't, but that is the result of decades of management and maintenance, and efforts sometimes measured in huge numbers of working hours by dozens of people.

A person can write a rudimentary web browser. A person cannot write chrome with all its features today. The effort to do so would be too great to finish. In addition, if finished, it would provide little value to the market, because the original chrome would still exist and have gained new features and maintenance patches that improve its behavior from the divergent clone the hypothetical engineer created.

LLMs output react because react dominates their training data. You have to reject their plan and force them to choose your preferred architecture when they attempt to generate what you ask, but in a different way.

We can have better tooling for sharing apps than the web. First, it needs to be built. This takes effort, iteration, and time.

Second, it needs to be marketed and gain adoption. At one time, Netflix and the tag it implented dominated the web. Now it is a historical footnote.Massive migrations and adoptions happen.

Build the world you want to work in. And use the tools you think make you more productive. Measure those against new tools that come along, and adopt the ones that are better. That's all you can do.

Re: Vibe engineering

#457
post #385

I don't think the issue is with the "code" part, but more with the "vibe" part. The "vibe" part indicates that's more of a "let's just see what happens" kind of approach, which I don't think is true for people using AI generated coding in their professional coding jobs, who very much know what they want to get out of AI coding tools, how to ask for it, and how to assess the quality of the outcome. Maybe something lik…

Right. The more accurate phrase would be "tool" or "machine-assisted development". We don't need new terminology to describe something that has always existed because the tools we use have (arguably) improved. "Vibe coding" is also a misnomer. People who engage in that activity are not "coding". They're using a tool to generate software until they're satisfied with the result. That has also been possible with low-cod…

I get what you're saying. Although I agree that it falls into the same category as "machine-assisted development", it's significantly different from other ways of coding that I would say it deserves its own name.

AI-assisted coding is an absolute game changer, for me, but I would think for everyone who can wield it well. I feel I can direct a (sort-of) small army of junior coders, architects, qa- and req engineers, etc., way different than with e.g. CASE-tooling. It requires creativity, and lots of knowledge & experience in the whole software-development life-cycle to get it well, and it can adapt to any flow you like. That's really new and unique, and way more flexible than the rigid CASE-tooling that was already out there.

"Tool" seems to broad: "What are you doing?" "I'm tooling." :)

Am not highly opinionated on if "code" should be in there. The AI tools do generate code, where some low-code platforms and the likes might not. I guess "development" works as well, although "vibe developing" doesn't really have the same ring to it :)

I do like to be able to differentiate between people generating code but don't care what happens under the hood, and software-professionals that incorporate AI assisted development into their daily work on any level.

Re: Vibe engineering

#458

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…

> that is the kind of mentality that pushed subpar products on the web for so many years

Famously, some of those subpar products are now household names who were able to stake out their place in the market because of their ability to move quickly and iterate. Had they prioritized long-maintainable code quality rather than user journey, it's possible they wouldn't be where they are today.

"Move fast and break things" wasn't a joke; Mark really did encourage people to build faster and it helped cement their positioning. Think of the quantity of features FB shoveled out between 2009-2014 or so, that just wouldn't have been possible if their primary objective was flawless code.

The code isn't the product, the product is the product. In all my years of engineering I've yet to have an end-user tell me they liked my coding style, they've always been more concerned with what I'd built them.

Re: Vibe engineering

#459

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.

> His life and activities are not in line with those of more typical programmers.

Okay sure.

I'll use myself as another example then. When I was a dev I used to write a lot of code. Now I'm a tech team lead, and I write less code, but review significantly more code than I used to previously.

I feel more confident, comfortable, and competent in my coding abilities now than ever before even though I'm coding less.

I feel like this is because I am exposed to a lot more code, and not in a passive way (reading legacy code) but an active way (making sure a patch set will correctly implement feature X, without breaking anything existing)

I feel like this principal applies to any programmer. Same thing with e.g. writers. Good writers read _a lot_ and it makes them better writers.

This is my opinion and not based on any kind of research. So if you disagree, that's fine with me. But so far I haven't seen anything to convince me of the opposite.

Re: Vibe engineering

#460

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

You must be very confident in your own ability if you think you can use any tool to its full potential with no scope for getting better.

I have tools I've been using for 25 years that I still think I could be using better.

Post reply on HN