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

191–200 of 203 posts

Re: Scaling long-running autonomous coding

#191

Post by embedding-shape »

mjmas wrote: post #189
embedding-shape wrote: post #184

Earlier quoted context omitted.

Looks like a bunch of different users (including Google's Jules made one commit) been contributing to the codebase, and the recent "fixes" includes switching between various git users. https://gist.github.com/embedding-shapes/d09225180ea3236f180... This to me seems to raise more questions than it answers.

The ones at *.ec2.internal generally mean that the git config was never set up ans it defaults to $(id -un)@$(hostname)

Indeed. Extra observant people will notice that the "Ubuntu" username was used only twice though, compared to "root" that was used +3700 times. And observant people who've dealt with infrastructure before, might recognize that username as the default for interactive EC2 instances :)

Re: Scaling long-running autonomous coding

#192

Post by nashadelic »

I'm very curious about how much of it is re-using (remixing?) an existing browser implementation it has seen in the while or its trained on. Even in that case, 99% of all code isn't doing anything novel so this copying would still have significant practical use.

Re: Scaling long-running autonomous coding

#193

Post by xpil »

physicsguy wrote: post #123
underdeserver wrote: post #121

Earlier quoted context omitted.

On Twitter people are saying GPT-5.2 is better. That's also what Cursor used in their testing. Maybe try it?

I have Web access for ChatGPT through work, but not API access annoyingly.

Codex plugin (VSCode) allows consuming your "web" (ie non-api) subscription for coding/agentic tasks.

Re: Scaling long-running autonomous coding

#194

Post by polyglotfacto »

wilsonzlin wrote: post #178
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…

Thanks for the feedback. There were some build errors which have now been resolved; the CI test that was failing was not a standard check CI, and it's now been updated. Let me know if you have any further issues. > On twitter their CEO explicitly stated that it uses a "custom js vm" which seemed particularly misleading / untrue to me. The JS engine used a custom JS VM being developed in vendor/ecma-rs as part of the…

> there are real complex systems being engineered towards the goal of a browser engine, even if not there yet.

In various comments in https://news.ycombinator.com/item?id=46624541 I have explained at length why your fleet of autonomous agents failed miserably at building something that could be seen as a valid POC.

One example: your rendering loop does not follow the web specs and makes no sense.

https://github.com/wilsonzlin/fastrender/blob/19bf1036105d4e...

The above design document is simply nonsense; typical AI hallucinated BS. Detailed critique at https://news.ycombinator.com/item?id=46705625

The actual code is worse; I can only describe it as a tangle of spaghetti. As a Browser expert I can't make much, if anything, out of it. In comparison, when I look at code in Ladybird, a project I am not involved in, I can instantly find my way around the code because I know the web specs.

So I agree this isn't just wiring up of dependencies, and neither is it copied from existing implementations: it's a uniquely bad design that could never support anything resembling a real-world web engine.

Now don't get me wrong, I do think AI could be leveraged to build a web engine, but not by unleashing autonomous agents. You need humans in the loop at all levels of abstractions; the agents should only be used to bang out features re-using patterns established or vetted by human experts.

If you want to do this the right way, get in touch: https://github.com/gterzian

Re: Scaling long-running autonomous coding

#195

Post by polyglotfacto »

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)

It's obvious by now that AI can write a whole bunch of code approximating all kinds of things. So there is no reason anymore for this to impress anyone.

A well-architected POC built in a week with a clear path to scaling it to a full implementation down the line would be impressive, but that's not what this is.

The current code output is basically throw-away level quality AI hallucinated BS.

Re: Scaling long-running autonomous coding

#196

Post by polyglotfacto »

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…

> what matters in the end is what the code does, not what it looks like

That is true in a way, although even for agents readability matters.

But the code here does not actually do the right thing, and the way it is written also means it never could.

Web devs do care whether the engine runs their code according to Web standards(otherwise it's early IE all over), and end-users do care that websites work as their devs intended to.

Current state is throw-away level quality.

I've critiqued it at length in the other post, see https://news.ycombinator.com/item?id=46705625

Re: Scaling long-running autonomous coding

#197

Post by polyglotfacto »

sashank_1509 wrote: post #4

Can a browser expert please go through the code the agent wrote (skim it), and let us know how it is. Is it comparable to ladybird, or Servo, can it ever reach that capability soon?

I've done this in the parallel post, see https://news.ycombinator.com/item?id=46705625 (and a couple of other replies in that thread)

TLDR; the code is not a valid POC but throw-away level quality that could never support a functioning web engine. It's actually very clear hallucinated AI BS, which is what you get when you don't have a human expert in the loop.

I actually like using AI, but only to save me the typing.

Re: Scaling long-running autonomous coding

#198

Post by tocsa »

xmprt wrote: post #12
cheevly wrote: post #9

Earlier quoted context omitted.

2029? I have no idea why you would think this is so far off. More like Q2 2026.

You're either overestimating the capabilities of current AI models or underestimating the complexity of building a web browser. There are tons of tiny edge cases and standards to comply with where implementing one standard will break 3 others if not done carefully. AI can't do that right now.

Even though several people seconded the complexity of a browser, I must add one more take and bring up one of my all time favorite blog posts, back from 2000 (I am old), when browsers were already complex, Joel Spolsky's Joel On Software episode "Things You Should Never Do, Part I" https://www.joelonsoftware.com/2000/04/06/things-you-should-... His first example was Netscape browser v6.0, and why there wasn't a v5.0 after v4.0, why it took three years: "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." I think this blog post is very relevant here.

Re: Scaling long-running autonomous coding

#200

Post by [deleted] »

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…

[deleted]
Post reply on HN