Live data from Hacker News

Vibe engineering

simonwillison.net

471–480 of 759 posts

Re: Vibe engineering

#471

Earlier quoted context omitted.

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

And empirical studies on informal code review show that humans have a very small impact on error rates. It disappears when they read more than roughly 200 SLOC in an hour.

Re: Vibe engineering

#472
post #460

Earlier quoted context omitted.

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.

Absolutely but we're talking about structured tools, like a cli, not unstructured non deterministic "agents" that fails to give the same answer twice, ls -la doesn't lie

Re: Vibe engineering

#473

Earlier quoted context omitted.

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

I thought about making some kind of community project where people could contribute their lines to a common file, and even some kind of MCP server or RAG system that automatically selects relevant "rules" given a certain project context. Do you think there would be interest in something like that?

I'm interested. That sounds like quite a valuable resource.

Re: Vibe engineering

#474
post #466
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…

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…

> doesn't work like people developers work with

I don't know.

This is true for people working in an environment that provides psychological safety, has room for mistakes and rewards hard work.

This might sound cynical, but in all other places I see the "lying to cover your ass" behavior present in one form or another.

Re: Vibe engineering

#475

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…

I can definitely see the 10% boost being accurate. Keep in mind, its not about doing everything 10% faster, its about being able to put out 10% more results by leveraging agentic coding when it makes sense.

This week I was able to tackle two long-standing bug fixes I've been noodling on and had a rough idea of what I needed to do but had competing priorities and a lack of time to sit down and really internalize the system to figure them out. I brain dumped the issue and my current thoughts and had claude formulate a plan. It solved each in less than 30 minutes of very light effort on my part. I was able to tack these onto larger work I'm doing basically seamlessly.

The other thing that I've found to be an insane benefit is filesystem-backed context switching. If your agentic workflow involves dumping your plan and progress to files in the filesystem, you can pause and restart work at any time by pointing at those files and saying "continue where you last left off". You can even take a `git diff > that-one-bug.patch` of edits made up to that point, copy that alongside the other files, and have a nice-and-neat folder of a unit of work that is ready to pick back up in the future as time permits.

Re: Vibe engineering

#476

Earlier quoted context omitted.

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?

Another non existing argument, if the agent fails to give the same answer twice i can't even explore his full potential

Re: Vibe engineering

#477

Earlier quoted context omitted.

While this is true, I definitely find that the style of the work changes a lot. It becomes much more managerial, and less technical. I feel much more like a mix of project and people manager, but without the people. I feel like the jury is still out on whether I’m overall more productive, but I do feel like I have less fun.

My lessons so far: 1. Less fun. 2. A lot of more "review fatigue". 3. Tons of excess code I'd never put in there in the first place. 4. Frustration with agents being too optimistic which with time verges on the ludicurous ("Task #3 has been completed successfully with 98% tests failing. [:useless_emojis:]") 5. Frustration with agents routinely getting down a rabbit hole or going in circles, the effort needed to get t…

I reset context probably every 5-10 minutes if not more frequently, and commit even more often than that. If you’re going 5 hours between commits or context resets, I’m not surprised you’re getting bad results. If you ever see “summarizing”’in copilot for example, that means you went way too far in that context window. The LLMs get increasingly inaccurate and confused as the context window fills up.

Other things like having it pull webpages in, will totally blow away your context. It’s better to make a separate context just to pull a webpage down and summarize it in markdown and then reset context.

Re: Vibe engineering

#478
> "If you’re going to really exploit the capabilities of these new tools, you need to be operating at the top of your game. You’re not just responsible for writing the code—you’re researching approaches, deciding on high-level architecture, writing specifications, defining success criteria, designing agentic loops, planning QA, managing a growing army of weird digital interns who will absolutely cheat if you give them a chance, and spending so much time on code review."

I know this paragraph is supposed to be encouraging, but it makes me wonder again what the actual goal of this entire AI enterprise is supposed to be.

"Less work" or "easier work" would make superficial sense, but in a society where people are in constant competition and derive both their self worth and their basis for living from work, both are effectively anti-goals. And so we get articles like this trying to offer comfort by saying that work will still be draining and challenging in the future.

So if not less work, then "more productivity", i.e. we can produce more software in a shorter amount of time (but with the same mental load). But as others have said, this was never the bottleneck.

Re: Vibe engineering

#479
post #222

Earlier quoted context omitted.

I appreciate what you're trying to do, but for myself, I'm not depressed because my skills are less valuable. I enjoyed the money but it was never about that for me. I'm depressed because I don't like the way this new coding feels in my brain. My focus and attention are my most precious resources and vibe coding just shatters them. I want to be absorbed in a coding flow where I see all the levels of the system and ca…

Well said! Reading this I feel reminded of the early protests against industrialization and automation in other fields. Checks all the same boxes - insecurity and fear about the future, alienation towards the new tools, ... Not saying AI is similar in impact to the loom or something, it just occured to me how close this is to early Luddite texts.

This is true, but it started way earlier than AI with software development though. A lot of software developers' job is just being ticket monkies, adding small things or fixing bugs for a huge company that nobody cares about. The alienation is real.

This is, of course, an attribute of capitalism.

Like carpenters, gardeners and farmers, there are very few software developers who truly have the luxury to treat their work as a craft and not a factory output.

Re: Vibe engineering

#480
post #53

Earlier quoted context omitted.

Power tools actually increase productivity. LLMs create the illusion of increased productivity and output unworkable messes while atrophying your skills, ergo they decrease productivity. Oh and unlike power tools, for all intents and purposes you can't own them.

That's only true if you don't put effort into figuring out how best to use them. If using LLMs makes you slower or reduces the quality of your output, your professional obligation is to notice that and change how you use them. If you can't figure out how to have them increase both the speed and the quality of your work, you should either drop them or try and figure out why they aren't working by talking to people who…

GGP's sentiment resonates with me. I invest a fair bit of time into LLMs to keep up on how †hings are evolving and I do throw both small and large tasks at them. I'm seeing great results with some small task but with anything that is remotely close to actual engineering I just can't get satisfactory results.

My largest project is a year old, it's full-stack JavaScript, and I consciously use patterns, structures, and diligently add documentations right from the beginning for the code base to be as LLM friendly as possible.

I see great results on refactoring with limited scope, scaffolding test cases (I still choose to write my own tests but LLMs can also generate very good tests if I explicitly point to existing tests of highly related code, such as some repository methods), documenting functions, etc. but I'm just not seeing the kind of quality that people claim that LLMs can do for them on complex tasks.

I want to believe that LLMs are actually capable of doing what at least a good junior engineer can do but I'm not seeing that in my own experience. Whenever we point out these issues we are encountering, we just basically get the "git gud" response with no practical details on what we can actually dp to get the results that people claim to be getting. Then people start blaming our lack of structures, patterns, problems with our prompts, the language, our stack, etc. when we complain about the "git gud" response being too vague. Nobody claiming to be seeing great results seems to want to do a comprehensive write-up or, better still, a stream of their entire workflow to teach others how to do actual, good engineering with LLMs on real-world problems either -- they all just want to give high level details and assert success.

On top of that, the fact that none of the people I know in engineering working in both large organizations and respectable startups that are pushing AI are seeing that kind of results naturally makes me even more skeptical of claims of success. What I'm often hearing from them are mediocre engineers thinking that they are being productive but actually just offloading the work to their colleagues through review, and nobody seems to be seeing tangible returns from using AI in their workflow but people in C-suites are pushing AI anyway.

If just about anything can be "your fault", how can anyone claiming that LLMs are great for real engineering without showing evidence be so confident that what they're claiming but not showing is actually the case.

I feel like every time I comment on anything related to your blog posts I probably came across as belligerent and get down voted but I really don't intend to.

Post reply on HN