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

501–510 of 759 posts

Re: Vibe engineering

#501

Post by angelmm »

redhale wrote: post #424
ridruejo wrote: post #383

This matches our experience developing with agents. In particular, as we wanted to use multiple agents in the background to do tasks, we had to really invest in different areas so they would not go in wild directions or have to ask continually for feedback, defeating the purpose of working in the background. First, we needed to provide relevant context on how to do the task (some of it is "generic" like Svelte docume…

Thanks for sharing! The problem with every single tool in the category that I've come across (e.g. Conductor, Sculptor) is that they assume a single repository. Very rarely in my career working on enterprise software have I been in a situation where all my work was constrained to a single repo. Usually a story or feature spans several repos (whether split between frontend/backend, or a repo-per-service). As an engine…

Hey! Angel from Endor / Rover :)

Thanks for your feedback! I faced this in the past. As you mentioned, monorepos are more common these days, but multi-repo is an established approach in many teams. The way I "solved" this situation was to move all the related projects into a single folder with a parent AGENTS.md file (CLAUDE.md, etc.). Then, I run Rover / Claude / Gemini on this folder.

However, this is not ideal. Due to the amount of code, it usually misses many things to do. We are currently exploring specific workflows for these use cases, trying to help agents to prepare a complete plan.

Another similar case we are working on is to support spawning the same task across different repositories. This would help teams to apply refactor or changes in different projects at the same time.

Re: Vibe engineering

#502

Post by jncfhnb »

globular-toast wrote: post #224
dboon wrote: post #154

Earlier quoted context omitted.

Yeah I couldn't put it better myself. It's obscene how much more productive you become in new domains. And sure, you eventually hit a wall where you gotta understand it for real. But now you have a working example of your project, plus a genius who will answer unlimited questions and clarifications. And you can do this for anything

> And you can do this for anything Anything that's been done before. Otherwise we'd probably start with making nuclear fusion work, then head off into the stars... You've always been able to read books. What you're talking about is skipping the slow learning step and instead generating a mashup of tons of prior art. I don't think it helps you learn. It sounds like it's for things you specifically don't want to learn.…

Nah. We’re literally on “hacker news”. Frankly a lot of the hacking ethos has always been cobbling stuff together building upon the works of others that you don’t really understand.

Learning by getting something to work and tweaking it is massively more effective than grinding against a wall of impassable errors while you’re just trying to get started. You don’t become a good programmer by reading a book.

Re: Vibe engineering

#503

Post by Huppie »

lukevp wrote: post #477
benterix wrote: post #278

Earlier quoted context omitted.

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…

The 'best' trick I learned from someone over here when working with Claude Code is to very regularly go back a few steps in your context (esc esc -> pick something a few steps up) and say something like "yeah, I already did this myself, now continue and do Y"

It results helps keep the context clean while still keeping the initial context I provided (usually with documentation and initial plan setup) at the core of the context.

Now that you say this, I did notice webpages blow context but didn't think too much of it just yet, maybe there's some improvement to be found here using a subagent? I'm not a big fan of subagents (didn't really get proper results out of them in my initial experiments anyway) but maybe adding a 'web researcher' sub agent that summarizes to a concise markdown file could help here.

Re: Vibe engineering

#504

Post by pron »

schwartzworld wrote: post #494
pron wrote: post #466

Earlier quoted context omitted.

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…

> incredibly impressive and completely unreliable. There have been methods of protecting against this since before AI, and they still apply. LLMs work great with test driven development, for example. I would say that high-level knowledge and good engineering practices more important than ever, but they were always important.

Test-driven development helps protect against wrong code, but it's not code I'm interested in, and it's not wrong code that I'm afraid of (I mean, that's table stakes). What I need is something that would help me generate understanding and do so reliably (even if the performance is poor). I can't exercise high-level knowledge efficiently if my only reliable input is code. Once you have to work at the code level at every step, there's no raising of the level of thought. The problem for me isn't that the agent might generate code that doesn't pass the test suite, but that it cannot reliably tell me what I need to know about the code. There's nothing I can reliably offload to the machine other than typing. That could still be useful, but it's not necessarily a game-changer.

Writing code in Java or Python as opposed to Assembly also raises the level of abstract thought. Not as much as we hope AI will be able to do someday, but at least it does the job reliably enough. Imagine how useful Java or Python would be if 10% of the time they would emit the wrong machine instructions. If there's no trust on anything, then the offloading of effort is drastically diminished.

Re: Vibe engineering

#505

Post by d--b »

The corollary to that is that keeping a shitty legacy codebase will keep you employed longer, since AI won't find its way through it, and screw everything up every time it touches anything.

This is making me like the written-by-math-grad-school-interns python mess I inhereted!

Re: Vibe engineering

#506

Post by simonw »

blibble wrote: post #496
simonw wrote: post #493

Earlier quoted context omitted.

Google already released the Gemini 2.5 Deep Think model they used in ICPC as part of their $250/month "Ultra" plan. The trend with all of these models is for the price for the same capabilities to drop rapidly - GPT-3 three years ago was over 1,000x the price of much better models today. I'm not yet ready to bet against that trend holding for a while longer.

> GPT-3 three years ago was over 1,000x the price of much better models today. right, so only another 27 years of moores law continuing left > I'm not yet ready to bet against that trend holding for a while longer. I wouldn't expect an industry evangelist to say otherwise

I'm a pretty bad "industry evangelist" considering I won't shut up about how prompt injection hasn't had any meaningful improvements in the last three years and I doubt that a robust solution is coming any time soon.

I expect this industry might prefer an "evangelist" who hasn't written 126 posts about that: https://simonwillison.net/tags/prompt-injection/

(And another 221 posts about ethical concerns with how this stuff works: https://simonwillison.net/tags/ai-ethics/)

Re: Vibe engineering

#507

Post by lossolo »

agentultra wrote: post #471
lossolo wrote: post #407

Earlier quoted context omitted.

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.

Interesting, do you have a link to the study? Our experience is different, at least when reviewing LLM generated code, we find quite a few errors, especially beyond 200 LOC. It also depends on what you're reviewing, 200 LOC != 200 LOC. A boilerplate 200 LOC change? A security sensitive 200 LOC change? A purely algorithmic and complex 200 LOC change?

Re: Vibe engineering

#508

Post by spyckie2 »

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…

Sales isn’t easy either!

Re: Vibe engineering

#509

Post by spyckie2 »

maplethorpe wrote: post #331
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…

Come to game dev. I'm yet to see anyone make anything good with AI. Like, where are all the amazing vibe-coded games we were promised? These guys should be eating my lunch, but they're not.

There are a ton of them already in game dev but they produce unfun games so you don’t hear about them. The hard part of game dev is designing actually fun experiences.

Re: Vibe engineering

#510

Post by spyckie2 »

muldvarp wrote: post #399
cpursley wrote: post #317

Earlier quoted context omitted.

My father runs a commercial landscaping company with 15 employees. His truck fleet insurance went up 35% just this year. His light industrial facility that he operates out of property taxes went up 55% last year. All of his commercial clients are cheaping out on all the little things that used to make extra money (pine straw, seasonal flowers, etc.). He’s having to deal with poorly educated staff who are constantly b…

No one is claiming that any of the alternatives are better jobs than software engineering has been for the last 20 years. We don't live in the last 20 years anymore and software engineering is either becoming a different (worse) job or simply vanishing.

But it’s necessary to get confirmation against the hope that the grass is indeed not greener on the other side.
Post reply on HN