Well, software is measured over time. The devil is always in the details.
Scaling long-running autonomous coding
71–80 of 112 posts
Re: Scaling long-running autonomous coding
#72Test suites just increased in value by a lot and code decreased in value.
Re: Scaling long-running autonomous coding
#73Earlier quoted context omitted.
Why attempt something that has abundant number of libraries to pick and choose? To me, however impressive it is, 'browser build from scratch' simply overstates it. Why not attempt something like a 3D game where it's hard to find open source code to use?
Assets are very hard to produce and largely unsolved by AI at the moment.
What it should have been willing to do is go off and look for free external assets on the Web that it could download and integrate.
Re: Scaling long-running autonomous coding
#74One of the big open questions for me right now concerns how library dependencies are used. Most of the big ones are things like skia, harfbuzz, wgpu - all totally reasonable IMO. The two that stand out for me as more notable are html5ever for parsing HTML and taffy for handling CSS grids and flexbox - that's vendored with an explanation of some minor changes here: https://github.com/wilsonzlin/fastrender/blob/19bf103…
Any views on the nature of "maintainability" shifting now? If a fleet of agents demonstrated the ability to bootstrap a project like that, would that be enough indication to you that orchestration would be able to carry the code base forward? I've seen fully llm'd codebases hit a certain critical weight where agents struggled to maintain coherent feature development, keeping patterns aligned, as well as spiralling in…
Re: Scaling long-running autonomous coding
#75Although I dissented on the decision, we banned the use of AI. Outside of the project I've been enjoying agentic coding and I do think it can be used already today to build production-grade software of browser-like complexity.
But this project shows that autonomous agents without human oversight is not the way forward.
Why? Because the generated code makes little sense from a conceptual perspective and does not provide a foundation on which to eventually build an entire web engine.
For example, I've just looked into the IndexedDB implementation, which happens to be what I am working on at the moment in Servo.
Now, my work in Servo is incomplete, but conceptually the code that is in place makes sense and there is a clear path towards eventually implementing the thing as a whole.
In Fastrender, you see an Arc> which is never going to work, because by definition a production browser engine will have to involve multiple processes. That doesn't mean you need the IPC in a prototype, but you certainly should not have shared state--some simple messaging between threads or tasks would do.
The above is an easy coding fix for the AI, but it requires input from a human with a pretty good idea of what the architecture should look like.
For comparison, when I look at the code in Ladybird, yet another browser project, I can immediately find my way around what for me is a stranger codebase: not just a single file but across large swaths of the project and understand things like how their rendering loop works. With Fastrender I find it hard to find my way around, despite all the architectural diagrams in the README.
So what do I propose instead of long-running autonomous agents? The focus should shift towards demonstrating how AI can effectively assist humans in building well-architected software. The AI is great at coding, but you eventually run into what I call conceptual bottlenecks, which can be overcome with human oversight. I've written about this elsewhere: https://medium.com/@polyglot_factotum/on-writing-with-ai-87c...
There is one very good idea in the project: adding the web standards directly in the repo so it can be used as context by the AI and humans alike. Any project can apply this by adding specs and other artifacts right next to the code. I've been doing this myself with TLA+, see https://medium.com/@polyglot_factotum/tla-in-support-of-ai-c...
To further ground the AI code output, I suggest telling it to document the code with the corresponding lines from the spec.
Back in early 2025 when we had those discussions in Servo about whether to allow some use of AI, I wrote this guide https://gist.github.com/gterzian/26d07e24d7fc59f5c713ecff35d... which I think is also the kind of context you want to give the AI. Note that this was back in the days of accepting edits with tabs...
Re: Scaling long-running autonomous coding
#76Re: Scaling long-running autonomous coding
#77Test suites just increased in value by a lot and code decreased in value.
Doubt it, code will be generated to pass tests, not the intent behind the tests.
"8 unit tests? Great, I'll code up 8 branches so all your tests pass!" Of course that neglects the fact that there's now actually 2^8 paths through your code.
Re: Scaling long-running autonomous coding
#78I would also love to see the statistics regarding token cost, electricity cost, environmental damage etc. Not saying that this only happens with LLMs, in fact it should be compared against e.g. a dev team of 4-5
The complex thing is that you would need to take into account the energy used to feed the programmers, the energy used for their education or simply them growing up to the age they are working. For the LLMs it would have to take into account energy used for the GPU, the machine building the GPUs, datacenters, engineers maintaining it, their education etc etc. It’s so complex to really estimate these things from botto…
Is it? Use dollar cost of salary and cost for the AI. That wraps up all those things you mentioned.
Re: Scaling long-running autonomous coding
#79I'm a maintainer of Servo which is another web engine project. Although I dissented on the decision, we banned the use of AI. Outside of the project I've been enjoying agentic coding and I do think it can be used already today to build production-grade software of browser-like complexity. But this project shows that autonomous agents without human oversight is not the way forward. Why? Because the generated code make…
That said, it's possible that none of that code even gets executed at run time, and the only code that is actually run is some translated glue code, with the other million lines essentially dead, so who knows.
Re: Scaling long-running autonomous coding
#80Earlier quoted context omitted.
Any views on the nature of "maintainability" shifting now? If a fleet of agents demonstrated the ability to bootstrap a project like that, would that be enough indication to you that orchestration would be able to carry the code base forward? I've seen fully llm'd codebases hit a certain critical weight where agents struggled to maintain coherent feature development, keeping patterns aligned, as well as spiralling in…
Almost no idea at all. Coding agents are messing with all 25+ years of my existing intuitions about what features cost to build and maintain. Features that I'd normally never have considered building because they weren't worth the added time and complexity are now just a few well-structured prompts away. But how much will it cost to maintain those features in the future? So far the answer appears to be a whole lot le…