Part of this, as others have noted, is due to: https://book.servo.org/policy/ai-usage.html

> 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.

> 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.

There are not just volunteer contributions, but also people working full time on Servo: some at Igalia, and some at Huawei at least.

Even with that many commits, the WPT pass percentage increases at a good rate: https://servo.org/wpt/

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...

> 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.

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.

wow! they already have android apk? Awesome!

My understanding is that the main focus is on the engine and building a good embedding API so that folks can build browsers (and apps and web drivers etc...) with it.

i've been hacking on my own browser using servo as a library! its lovely to interface with.

i have been hacking on my own servo-based browser using gpui for macos: https://tangled.org/oppi.li/meridian/

Currently they do not: https://book.servo.org/policy/ai-usage.html

> Contributions must not include content generated by large language models or other probabilistic tools, including but not limited to Copilot or ChatGPT. This policy covers code, documentation, pull requests, issues, comments, and any other contributions to the Servo project.

> 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.

The references to ChatGPT and Copilot suggest it was authored before the Codex and Claude Code revolution. I wonder if they'll revise it at some point soon.

Update: looks like that language was originally added in July 2024: https://github.com/servo/book/commit/5afb80d5b08b259ca359cfe...

I found a discussion about changing it in April 2025, but they decided to keep it the same at that point: https://github.com/servo/servo/discussions/36379

> Do they allow vibe-coded contributions?

are there serious projects welcoming vibe-coded PRs?

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?

About ready to switch to Servo as my daily driver on desktop.

Have been using it as the render backend on an experimental tablet OS and its quite capable once you fix the font rendering.

Would gladly upstream contributions but I dont type anymore.

>> 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.

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.

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 mid-2024, 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).

[1] https://servo.org/blog/2026/06/30/may-in-servo/

> 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!

[0]: https://github.com/dioxuslabs/blitz

Giant leaps aren't typically the way to steady progress

It’s kind of a wink wink situation. Language like this simply encourages developers to vet code written by AI thoroughly to avoid being caught with obvious slop.

But as maintainers we (I don’t work on servo, but other projects) know that obviously people use AI anyway.

If you believe AI isn't still involved in contributions to Servo, I have a bridge in Brooklyn to sell you.

it is great that different projects take different approaches