Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scaling long-running autonomous coding

cursor.com

Post reply on HN
Print view View original

111–120 of 203 posts

Re: Scaling long-running autonomous coding

#111

Post by embedding-shape »

orlp wrote: post #94
trjordan wrote: post #8

This is going to sound sarcastic, but I mean this fully: why haven't they merged that PR. The implied future here is _unreal cool_. Swarms of coding agents that can build anything, with little oversight. Long-running projects that converge on high-quality, complex projects. But the examples feel thin. Web browsers, Excel, and Windows 7 exist, and they specifically exist in the LLM's training sets. The closest to real…

> Long-running projects that converge on high-quality, complex projects In my experience agents don't converge on anything. They diverge into low-quality monstrosities which at some point become entirely unusable.

Yeah, I don't think they're built for that either, you need a human to steer the "convergtion", otherwise they indeed end up building monstrosities.

Re: Scaling long-running autonomous coding

#112

Post by ben_w »

torginus wrote: post #99

I'm kinda surprised how negative and skeptical anyone is here. It kinda blows my mind that this is possible, to build a browser engine that approximates a somewhat working website renderer. Even if we take the most pessimistic interpretation of events ( heavy human steering, relies on existing libraries, sloppy code quality at places, not all versions compile etc)

I'm not too surprised, the way I read a lot of (not all!*) the negative comments is ~"I'm imagining having to work with this code, I'd hate it". Even though I'm fairly impressed with the work LLMs do, this has also been my experience of them… albeit with a vibe-coding** sample size of 1, done over a few days with some spare credit.

The positive views are mostly from people who point out that what matters in the end is what the code does, not what it looks like, e.g. users don't see the code, nor do they care about the code, and that even for businesses who do care, LLMs may be the ones who have to pay down any technical debt that builds up.

* Anyone in a field where mistakes are expensive. In one project, I asked the LLM to code-review itself and it found security vulnerabilities in its own solutions. It's probably still got more I don't know about.

** In the original sense of just letting the LLM do whatever it wanted in response to the prompt, never reading or code reviewing the result myself until the end.

Re: Scaling long-running autonomous coding

#113

Post by satvikpendem »

jkelleyrtp wrote: post #87
tehsauce wrote: post #69

I was excited to try it out so I downloaded the repo and ran the build. However there were 100+ compilation errors. So I checked the commit history on github and saw that for at least several pages back all recent commits had failed in the CI. It was not clear which commit I should pick to get the semi-working version advertised. I started looking in the Cargo.toml to at least get an idea how the project was construc…

WGPU for render, winit for window, servo css engine, taffy for layout sounds eerily similar to our existing open source Rust browser blitz. https://github.com/dioxuslabs/blitz Maybe we ended up in the training data!

I follow Dioxus and particularly blitz / #native on your Discord and I noticed the exact same thing too. There was a comment in a readme in Cursor's browser repo they linked mentioning taffy and I thought, hang on, it's definitely not from scratch, as they advertise. People really do believe everything they read on Twitter.

Great work by the way, blitz seems to be coming along nicely, and I even see you guys created a proto browser yourselves which is pretty cool, actually functional unlike Cursor's.

Re: Scaling long-running autonomous coding

#114

Post by satvikpendem »

ben_w wrote: post #112
torginus wrote: post #99

I'm kinda surprised how negative and skeptical anyone is here. It kinda blows my mind that this is possible, to build a browser engine that approximates a somewhat working website renderer. Even if we take the most pessimistic interpretation of events ( heavy human steering, relies on existing libraries, sloppy code quality at places, not all versions compile etc)

I'm not too surprised, the way I read a lot of (not all!*) the negative comments is ~"I'm imagining having to work with this code, I'd hate it". Even though I'm fairly impressed with the work LLMs do, this has also been my experience of them… albeit with a vibe-coding** sample size of 1, done over a few days with some spare credit. The positive views are mostly from people who point out that what matters in the end i…

The problem I've had with vibe coding is akin the adage of the first 90% of the code taking 90% of the time, and the last 10% taking the other 90% of the time. The LLM can get you to 90% initially but it hits a wall unless you the user know what it's doing and outputting, but that is very difficult when you're vibe coding by its very definition, meaning that you're not looking at the code at all. And then you have to read thousands of lines of code which you don't understand that it's entirely easier to stop and hand code a new version yourself, which is precisely what I've done with some of my projects.

Re: Scaling long-running autonomous coding

#115

Post by satvikpendem »

foota wrote: post #92

I've always liked the idea of intelligence in the autonomous ships of the Revelation Space universe. Little agents reporting to progressively more intelligent and higher level ones.

That's essentially all life from the sub-cellular level on up

Re: Scaling long-running autonomous coding

#116

Post by askl »

embedding-shape wrote: post #109
snek_case wrote: post #68

Earlier quoted context omitted.

I found the codebase very hard to navigate. Hundreds (over a thousand?) tiny files with less than 200 lines of code, in deeply nested subdirectories. I wanted to find where the JavaScript engine was, and where the DOM implementation was located, and I couldn't easily find it, even using the GitHub search feature. I'm not exactly sure what this browser implements and how. Even their README is kind of crappy. Ideally y…

> It's impressive that they got such a big project to be built by agents and to compile But that's the thing, it doesn't compile, has a ton of errors, CI seems broken since long... What exactly is supposed to impressive here, that it managed to generate a bunch of code that doesn't even compile? What in the holy hackers is this even about? Am I missing something obvious here? How is this news?

> What in the holy hackers is this even about? Am I missing something obvious here?

It's about hyping up cursor and writing a blog post. You're not supposed to look at or use the code, obviously.

Re: Scaling long-running autonomous coding

#117

Post by satvikpendem »

tired_and_awake wrote: post #52
icedchai wrote: post #32

Earlier quoted context omitted.

This is how we wound up with non-technical "engineering managers." Looks good to me.

I think this misses the point, see the other comments. Fully scaled agentic coding replaces managers too :) cause for celebration all around

No, it becomes only managers, because they are the ones who dictate the business needs (because otherwise, what is the software the agents are making even doing without such goals), and now even worse with non technical ones.

Re: Scaling long-running autonomous coding

#118

Post by physicsguy »

I have been trying Claude Code a lot this week. Two projects:

* A small statically generated Hugo website but with some clever linking/taxonomy stuff. This was a fairly self-contained project that is now 'finished' but wouldn't hvae taken me more than a few days to code up from scratch. * A scientific simulation package, to try and do a clean refresh of an existing one which i can point at for implementation details but which has some technical problems I would like to reduce/remove.

Claude code absolutely smashed the first one - no issues at all. With the second, no matter what I tried, it just made lots of mistakes, even when I just told it to copy the problematic parts and transpose them into the new structure. It basically got to a point where it wasn't correct and it didn't seem to be able to get out of a bit of a 'doom loop' and required manual intervention, no matter how much prompting and hints I gave it.

Re: Scaling long-running autonomous coding

#119

Post by keepamovin »

simonw wrote: post #3

"To test this system, we pointed it at an ambitious goal: building a web browser from scratch." I shared my LLM predictions last week, and one of them was that by 2029 "Someone will build a new browser using mainly AI-assisted coding and it won’t even be a surprise" https://simonwillison.net/2026/Jan/8/llm-predictions-for-202... and https://www.youtube.com/watch?v=lVDhQMiAbR8&t=3913s This project from Cursor is the s…

That makes a lot of sense for massive-scale efforts like a browser, using coordinated agents to push toward a huge, well defined target with existing benchmarks and tests.

My angle has been a bit different: scaling autonomous coding for individual developers, and in a much simpler way. I love CLI agents, but I found myself wasting time babysitting terminals while waiting for turns to finish. At some point it clicked: what if I could just email them?

Email sounds backward, but that’s the feature. It’s universal, async, already collaborative. The agent sends me a focused update, I reply with guidance, and it keeps working on a server somewhere, or my laptop, while I’m not glued to my desk. There’s still a human in the loop, just without micromanagement.

It’s been surprisingly joyful and productive, and it feels closer to how real organizations already work. I’ve put together a small, usable tool around this and shared it here if anyone wants to try it or kick the tires: https://news.ycombinator.com/item?id=46629191

Re: Scaling long-running autonomous coding

#120

Post by ben_w »

nl wrote: post #53

Remember when 3D printers meant the death of factories? Everyone would just print what they wanted at home. I'm very bullish on LLMs building software, but this doesn't mean the death of software products anymore than 3D printers meant the death of factories.

Perhaps, but I don't think that's a good analogy, there's too many important differences to say (3d printing : all manufacturing) : (vibe coding : all software).

The hype may be similar, if that's your point then I agree, but the weakness of 3D printing is the range of materials and the conditions needed to work with them (titanium is merely extremely difficult, but no sane government will let the general public buy tetrafluoroethylene as a feedstock), while the weakness of machine learning (even more broadly than LLMs) is the number of examples they require in order to learn stuff.

Post reply on HN