One of the things I find really helpful about servo (as a casual user) is the breadth of pre-built releases they have. It makes it much more feasible to actually use on a day-to-day basis, especially on android
I think the sweet spot is not allowing vibe-coded contributions past a certain line count. At least, that's my policy. If you use an LLM to track down some bug that's a few lines to fix; that's fine. But if it's a new feature that needs 100s of lines; just make a feature request and if I agree, I can spin up my own clanker.
That was my thought as well. You'd imagine a known quantity like a browser should be easy to make now. I know it sounds ridiculous to anyone who hasn't tried the new models, but idk what to tell you. Photoshop used to be impossible to clone, too. I asked Opus 5.5 to add SSGI to an open source game and it did it in an afternoon. I don't know anything about graphics programming. This is nuts.
I dearly wish this was the own you think it is. You know how Wile E. Coyote doesn't notice the cliff and runs over it and hangs in the air? That's my career and yours right now.
Ladybird seems to be embracing vibe coding, so I think there's a great opportunity to compare them. After a couple of months of vibe coding what do you people here think about Ladybird's progress?
>> With the advances in AI, I'd expect the Servo project to go a lot faster ...
>> Do they allow vibe-coded contributions?
With an official automated test suite that they aim to pass, someone could probably set Claude loose on closing out those bugs and feature gaps. Assuming AI can figure out why tests fail (it probably can) I'd give it about a day to finish. Actually maybe a week since it'd be compiling RUST. Would the resulting code be of the same quality? Probably not. Would it be good? Maybe.
IME, agents are generally capable of passing the tests autonomously. But not with code you'd actually ever want to use. Both because of the quality, and because it will have awful performance/memory/security issues.
The progress on Servo is impressive. UI polish is required in order to be more usable. Things like keyboard shortcuts to focus the address bar are required to make it feasible for more daily driving use
> For now, we’re taking a cautious approach to these tools due to their effects — both unknown and observed — on project health and maintenance burden. This field is evolving quickly, so we are open to revising this policy at a later date, given proposals for particular tools that mitigate these effects.
seems entirely reasonable reason and approach, and I see no reason to force everyone approach LLM in the same way
my read is that with the right guidance, implementing the vast amount of the CSS spec for example, could be done easily with some AI assistance, the spec is incredibly well defined. just comparing the layouting and styling in blitz[0] (which does use agents), servo is lacking quite a bit, and the implementation of various features don't follow the spec exactly.
that being said, i entirely respect their decision of course, perhaps they will revisit at a later point in time!
My experience is that it varies greatly by feature.
Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.
More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.
Yes, this was how I did it in Azul[1], which is „reverse engineered from the W3C spec“. But it still took a lot of „agentic debugging“ to get the same visual layout as Chrome[2]. It wasn‘t „easily“ done however and it‘s not yet stable.
It’s kind of a wink wink situation. Language like this simply encourages vetting code written by AI thoroughly to avoid the obvious slop. But as maintainers we (I don’t work on servo, but other projects) know that obviously people use AI anyway.
The AI policy for Servo, which prohibits AI contributed code (but allows you to use AI to inspect and learn about the codebase), was written in early-mid 2025, which seems like an eternity ago.
But even in June 2026 they reiterated this ban and added CI checks to automatically reject AI-coauthored patches [1].
> For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).
It's heartening to see a large group of people working (mostly) for free on a passion project. Makes me optimistic about the resilience of intrinsic human drive.
Servo is really great: Rust seems like a no brainer choice for a modern web engine, and its clean, performance-focused design from the ground up is wonderful.
But it seems really hard for it to get anywhere just based on occasional contributions from volunteers. I was actually quite surprised that basic functionality like <progress> and the :checked attribute were not even supported prior to this release.
Servo got 527 commits, while Chromium has over 20,000 commits.
> Can I submit a PR that includes code generated by AI tools?
> No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf.
For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant https://github.com/servo/servo/blob/main/components/layout/f...) to just those already familiar with the code.
A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.
> > No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf
Based on the tool listed here, you can probably know when this policy was first written. For instance, Windsurf is long gone and Cursor is not tier 1 anymore.
Crazy to think how much the space of AI coding agent has evolved in less than 2 years.
I get what you’re saying, but LLMs really aren’t great at writing code for use in “key” codebases where every line needs to be clear and clear easy to review, not adding to the maintenance burden any more heavily than necessary.
Now reviewing code, finding flaws? They’re great at that. Prototyping new ideas, and suggesting potential solutions? Amazingly useful. Writing lots of code solving problems in projects focused on having the features not on being long term secure and easy to extend? They seem to do this very well.
But the actual code going into a web browser engine needs to be very carefully produced.
So I’d compare it more to how c++ going into safety critical systems cannot use any of the “cool” features of c++. Code going into a web browser cannot be generated without a human hand tightly on the tiller.
You can see how Ladybird is "progressing" right now because of AI. I think it's a shame because now AI would just be using parts from chromium or Firefox, and they're going to encouter eventually an unmaintainable codebase. How a new browser engine helps here then?
It is not like they are fully vibe coding the browser. And Ladybird was not built with a prompt. They already had a more or less fully functioning browser before they introduced the use of AI.
The design of Ladybird follows the web standards closely as well. It is going to be quite different from older engines.
My biggest gripe with Ladybird is that they adopted some pretty large components written by Google. You cannot really use Skia and say that you do not rely on Google as an example.
Not relying on Google was their big selling point, since every other browser is Google-dependent.
why would the middle ground be betterf itqs not as if that code needs to be reviewed any less. a coder reviewing their own code is pretty useless, so this would still occupy revewers on ai slop
Language choice has next to nothing to do with browser performance. Servo's "performance-focused" design currently suffers from a 10x gap between it and Chrome on the same platform.
I think the benchmark is for layout performance not JavaScript execution, but v8 is fast because it emits assembly more so than because of the language it is implemented in. That said, I would be very surprised if there is not hand tuned assembly routines for performance critical routines.
My point was that while you can implement any performant program (be it V8 or Spidermonkey, Blink or Servo) in any language, the effort required to reach a certain performance level differs between the languages.
>v8 is fast because it emits assembly
It emits machine code afaik. And secondly, do you _really_ want to implement the intermediate layers of a JIT in assembly?
I take your point that code organization in assembly is hard, and not worth the performance gains over higher level languages. It’s true, we don’t write much complex software completely in assembly.
However the point I was trying to make is still relevant I think, which is that machine instruction abstraction layer (whether binary or text serialized) remains a critical piece of what makes high performance software fast even today.
There is a recurring myth I see on HN that suggests abstraction layers are progressive, as though humanity had evolved past the assembly/machine instructions abstraction layer to C to higher level languages leaving lower abstraction layers behind completely. That is simply untrue, and a project like V8 is actually a great example of this, since it not only will have hand tuned assembly routines, but also needs to ship a bespoke compiler which will emit machine instructions.
So even though it’s true we don’t organize our software with assembly language, it remains a key to performance. It could be a custom JIT compiler, hand tuned SIMD code (eg to handle string parsing), or even just checking the compiled assembly (eg in compiler explorer). Machine instructions remain key to high performance.
You don't seem to know where the machine code are generated from. A big part of a compiler is optimizing intermediate representations of the source code.
> Rust seems like a no brainer choice for a modern web engine
Well, I mean Servo was the original catalyst and production use-case for Rust back in 2012. Both are products of the work of various folks at Mozilla around the time.
> Rust seems like a no brainer choice for a modern web engine,
Why? Beacuse of memory safety?
It's a shame that there aren't other memory safe low-level options that don't come with the rest of the baggage of rust, or try out different paradigms, for example: not defaulting to malloc (and having other allocator options that aren't painful), not using trait-based shared behavior, not using macros, no turbofish, object orientation (for those who partake), etc.
73 comments
[ 0.23 ms ] story [ 78.2 ms ] threadDo they allow vibe-coded contributions?
feel free to make one
are there serious projects welcoming vibe-coded PRs?
With an official automated test suite that they aim to pass, someone could probably set Claude loose on closing out those bugs and feature gaps. Assuming AI can figure out why tests fail (it probably can) I'd give it about a day to finish. Actually maybe a week since it'd be compiling RUST. Would the resulting code be of the same quality? Probably not. Would it be good? Maybe.
Feels like a missed opportunity where we could take a giant leap forward.
seems entirely reasonable reason and approach, and I see no reason to force everyone approach LLM in the same way
that being said, i entirely respect their decision of course, perhaps they will revisit at a later point in time!
[0]: https://github.com/dioxuslabs/blitz
My experience is that it varies greatly by feature.
Something like border styles, the agent was able to do pretty effectively. Although it still took a few hours iterating on it to get the performance characteristics and edge cases right.
More complex features like hoisting position absolute nodes and other layout features still take days to weeks of iterating to get something usable that isn't so fragile it'll blow up the next time you touch something.
[1] https://azul.rs/ui
[2] https://azul.rs/ui/reftest
But even in June 2026 they reiterated this ban and added CI checks to automatically reject AI-coauthored patches [1].
> For developers of Servo itself, please note that per project policy, you must not use the output of large language models or other generative AI tools in your contributions. To help us enforce that, we now have CI checks that reject AI agents as coauthors (@SimonSapin, @delan, #44723).
[1] https://servo.org/blog/2026/06/30/may-in-servo/
how sad.
But it seems really hard for it to get anywhere just based on occasional contributions from volunteers. I was actually quite surprised that basic functionality like <progress> and the :checked attribute were not even supported prior to this release.
Servo got 527 commits, while Chromium has over 20,000 commits.
> Can I submit a PR that includes code generated by AI tools?
> No. This includes (but is not limited to) all generative AI tools like Claude, Codex, ChatGPT, Cursor, Gemini, and Windsurf.
For something like a browser, this de facto limits the set of people who can contribute to something that touches the layout engine (e.g. the ineffable but brilliant https://github.com/servo/servo/blob/main/components/layout/f...) to just those already familiar with the code.
A much better middle ground IMO would be to quarantine first-time committers behind an AI-generated-PRs-will-not-be-reviewed policy, but to allow those who understand and respect the cycle enough to get PRs accepted, to begin using AI to give the team leverage. Without some kind of policy like that, Servo's sadly going to fall behind literally any other open-source project that people could dedicate their time towards.
Based on the tool listed here, you can probably know when this policy was first written. For instance, Windsurf is long gone and Cursor is not tier 1 anymore.
Crazy to think how much the space of AI coding agent has evolved in less than 2 years.
Now, in 2026 I’m excited by LLMs because the combo of Rust+AI is literally an unstoppable force..
It’s a shame they’re building the Lamborghini of rendering engines but refuse to source parts unless it’s delivered on horseback
Now reviewing code, finding flaws? They’re great at that. Prototyping new ideas, and suggesting potential solutions? Amazingly useful. Writing lots of code solving problems in projects focused on having the features not on being long term secure and easy to extend? They seem to do this very well.
But the actual code going into a web browser engine needs to be very carefully produced.
So I’d compare it more to how c++ going into safety critical systems cannot use any of the “cool” features of c++. Code going into a web browser cannot be generated without a human hand tightly on the tiller.
By the time you understand it you shouldn't need AI to write changes. First-time committers are the ones most likely to use AI.
The design of Ladybird follows the web standards closely as well. It is going to be quite different from older engines.
My biggest gripe with Ladybird is that they adopted some pretty large components written by Google. You cannot really use Skia and say that you do not rely on Google as an example.
Not relying on Google was their big selling point, since every other browser is Google-dependent.
- Servo b88af263d11e12288ff3eca0848aaa675d6a52f0: 21.4
- Chrome 157: 60.9
- Safari 27.2: 59.2
- Firefox 159: 41.0
So between 2x and 3x slower than the current "big 3".
>v8 is fast because it emits assembly
It emits machine code afaik. And secondly, do you _really_ want to implement the intermediate layers of a JIT in assembly?
However the point I was trying to make is still relevant I think, which is that machine instruction abstraction layer (whether binary or text serialized) remains a critical piece of what makes high performance software fast even today.
There is a recurring myth I see on HN that suggests abstraction layers are progressive, as though humanity had evolved past the assembly/machine instructions abstraction layer to C to higher level languages leaving lower abstraction layers behind completely. That is simply untrue, and a project like V8 is actually a great example of this, since it not only will have hand tuned assembly routines, but also needs to ship a bespoke compiler which will emit machine instructions.
So even though it’s true we don’t organize our software with assembly language, it remains a key to performance. It could be a custom JIT compiler, hand tuned SIMD code (eg to handle string parsing), or even just checking the compiled assembly (eg in compiler explorer). Machine instructions remain key to high performance.
I am not going to waste my time with you.
Well, I mean Servo was the original catalyst and production use-case for Rust back in 2012. Both are products of the work of various folks at Mozilla around the time.
Why? Beacuse of memory safety?
It's a shame that there aren't other memory safe low-level options that don't come with the rest of the baggage of rust, or try out different paradigms, for example: not defaulting to malloc (and having other allocator options that aren't painful), not using trait-based shared behavior, not using macros, no turbofish, object orientation (for those who partake), etc.
https://mojolang.org/
Maybe, hopefully, Rust allows to maintain a more safe browser at less than 20,000 commits per month.
We will see the maintenance effort after achieving 100% WPT. And whether they can close the performance gap by Rust-enabled safe concurrency...