Live data from Hacker News

Vibe engineering

simonwillison.net

751–759 of 759 posts

Re: Vibe engineering

#751

> It’s a lot easier than working with actual people because you don’t have to worry about offending or discouraging them But you have to worry much more about confusing LLMs by introducing contradictory ideas or talking about too many things at once. They will not call you out and they will not recover. You don’t need to reboot your coworkers.

Life would be so much easier if you could reboot your coworkers!

One of the best solutions to most LLM problems is to wipe the context and go back to a clean slate.

Re: Vibe engineering

#752
I work at a FAANG adjacent company as an EM and the 4x engineers who’ve recently been PIPd all went off the deep end using agents to write huge amounts of convoluted or unsuitable code.

One of them has decades of experience coding and even devised our onboarding training for using Cursor and Bedrock at the company but they too were called out for building a wholly unsuitable and unmaintainable service which could have been more simply solved with some common libraries and Docker micro services rather than 10k+ lines of custom code.

We all receive a copy of Cursor and IntelliJ + Copilot on joining and I just keep seeing engineers (surprisingly the more experienced ones so far) footgunning themselves with these tools.

Re: Vibe engineering

#754

Earlier quoted context omitted.

Translation is great to discuss LLMs. Thanks for sharing your experience. On one side translation is not very valued by most people. It is rare that people know who translated a book, for example. It is a pity but people do not read much these days. Additionally, or maybe because of the above, translation is often paid in terms of number of lines or words, even before AI. A bit like software security, it is often sad…

> It is a pity but people do not read much these days. This is a common belief, but it's just not true. The book industry is healthier than ever.

There have been study results published quite recently that suggested otherwise, at least for the U.S.

While I don't recall the actual numbers, the number of people who said they read books pretty much crashed over the past two decades, and more parts of the population are considered to be functionally illiterate than in a long time.

Re: Vibe engineering

#755
post #723

Earlier quoted context omitted.

Software engineers are the translators. We (as a metaphorical community are in denial). Read the 100s of comments on this post: either (AI code is wrong or this isn’t correct or it’s not effective or some other justification). At the end of the day it’s really hard to accept the change.

> Software engineers are the translators. True, recently I started feeling that part of what I had been doing is simply translating natural language to programming languages. Though coding also involves things such as algorithm and data structures, context and background knowledge, but these can all be done in natural language. Once the natural language description is given, what remains is only translation. LLMs hav…

I don't think that's a fair characterisation. I gave these tools the benefit of the doubt and many genuine tries, and still do occasionally. My judgment that they're unfit for the task is based on finding that they objectively don't help me work. There are studies showing that LLM use slows experienced developers down, even as they believe the opposite. I used to be the only one in my immediate work environment who thought LLMs are of jack use in my development work. Over the past year, most devs who used LLMs heavily have now switched over to my view.

Translation is natural language in, natural language out. That has very little to do with programming. Dijkstra knew back in the 70s that the very concept of natural language programming was bullshit, and that fancy new tech is never going to change the fundamental issues with the idea. In my opinion, his argument is as valid as ever.

Edit: I wasn't trying to imply that natural to natural language translation is trivial. The best LLM tools can be pretty shit at that even today, too. Tried using localised Microsoft developer documentation lately. It's unintelligible.

Re: Vibe engineering

#756
post #755
post #723

Earlier quoted context omitted.

> Software engineers are the translators. True, recently I started feeling that part of what I had been doing is simply translating natural language to programming languages. Though coding also involves things such as algorithm and data structures, context and background knowledge, but these can all be done in natural language. Once the natural language description is given, what remains is only translation. LLMs hav…

I don't think that's a fair characterisation. I gave these tools the benefit of the doubt and many genuine tries, and still do occasionally. My judgment that they're unfit for the task is based on finding that they objectively don't help me work. There are studies showing that LLM use slows experienced developers down, even as they believe the opposite. I used to be the only one in my immediate work environment who t…

Thanks for you opinion. I agree with your opinion that current LLMs are less helpful to senior/experienced developers. Of course LLMs can't solve complicated, advanced problems, otherwise we would see great advance in science and technology now.

However, there are a lot of trivial work in software development. For example, the behavior of a button, or editable text. Same to any kind of art, most developers in the industry are doing trivial or ordinary work, and few are solving challenging problems. What I mean is that those who do trivial work will be culled, or liberated, from doing that as a job, while the elite could remain there to solve unique, challenging problems.

Recently I have been working with coding agent to fix bugs and implement new features. I implemented my solution first and let coding agent come up with its own solution. Most of the time, the coding agent came up a better solution than mine. Most of the time, its solution was not worse than mine, and I would keep most of its code and only do some minor improvement. Most probably, I am not an experienced/advanced developer, since I seldom deal with advanced math/algorithms/architecture in my day-to-day work. Thus, it would be natural that we have different feeling to the same thing.

I am interested in Dijkstra's idea about natural language programming you mentioned, is that EWD667?

https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

Re: Vibe engineering

#757

Earlier quoted context omitted.

As a thought experiment, do you think it would be just as fun if you were given access to an infinite database of apps, and you were able to search through the database for an existing app that suit your needs, and then it gave it to you? Or would it no longer be fun, because it no longer feels like creating?

I'll repeat something I said to a sibling comment. I guess my original wasn't particularly clear. > I think there is joy in the act of turning your ideas into something real - creation - not just having something real. Shopping is not building.

No, you were clear. I suppose I was interested to see where you drew the distinction between creating and shopping.

For example, lets say LLMs improve to the point where they can now reliably one-shot entire apps with no more input than the original prompt. Would you no longer consider that creating? What's the difference between that and typing your prompt into an infinite app store?

Re: Vibe engineering

#758

Earlier quoted context omitted.

We tried this as a bit of an experiment - not quite greenfield but a fork and modification of an existing project. I was a solo dev going brrrr with no code review, using Cursor to make pretty sweeping changes and implement full features. I think because it was a fork I was able to go really fast because I could point the coding agent at existing patterns and say, "do this but different". Occasionally I would test ch…

Nice. Sounds like a success? Was the experiment made permanent? If not, why not?

I would say it's a success, yes - it was great for quickly scaling up a theoretical product with a small engineering staff (just me lol).

Now that the product has matured, we've had to slow down significantly since we have a ton of paying users who expect SLAs and less bugs. This means more engineers, which means more testing and review, which means more process around what changes we're making.

Re: Vibe engineering

#759

Earlier quoted context omitted.

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

Earlier than that, Facebook became ascendent because of quality. It was better than MySpace, the only real competitor at the time. The issue here is Facebook is not primarily a software product. It's a community, and the community was better than MySpace because it was restricted to pre-existing networks rather than taking any comer. I don't think Mark did that on purpose as a calculated decision. He just got lucky.…

W. Edwards Deming was partially responsible for Japanese manufacturing QA and was a huge player in WWII manufacturing. He was one of the reasons the United States went from annually manufacturing 3k planes to over 300k+ planes by the end of the war, which is pretty crazy to think about. The US did plenty right in WWII but it gets over looked by historians and (I guess) universities.
Post reply on HN