Founding Engineer (Full-Stack)

Founding Engineer (Full-Stack)

Full-time · London, hybrid.

About us

Science runs on trust, but the machinery that produces that trust is failing. Peer review is slow, opaque, inconsistent and increasingly gamed, and AI-generated papers are already forcing top venues to ration submissions rather than check them. No one is the credible, independent arbiter of research quality. We think there should be one.

XSci is building that layer: a place where a paper goes first, after it is written and before it goes anywhere else, to be checked by domain experts working with AI. Reviewers are paid, every verdict has a named expert behind it, and reading is free. We are a Delaware public benefit corporation, and our charter commits us to making the evaluation of science as open, as fast and as fairly rewarded as its production.

The evidence is moving our way. A recent Harvard study found journal editors preferred AI-written reviews to human ones in 26 of 30 cases, and proposed that every journal publish an official AI review prompt for authors to check their work against before submitting. Nobody maintains such a thing today. We think it should be open, and we intend to build it. That is one of the first things you would work on.

The role

You will own XSci's open review registry: a public, versioned record of what a review at each journal should check, and the evidence that justifies changing it.

The visible artifact is a prompt per journal. The thing that makes it work is a corpus of recorded disagreements between authors and AI reviewers, adjudicated by editors, because that is what tells you when a prompt is wrong. Prompts are cheap to copy. The evidence is not.

This is a founding role. You report to the founder and work with our Chief Scientist and CTO. Nobody is working on this yet; you are the first person on it, and you will decide what it becomes.

What you'll do

• Build the registry: one page per journal, prompt text, full version history, provenance (auto-generated draft, community-edited, or editor-claimed), and a run log so any review traces back to an exact prompt, model, and tool configuration.
• Design the contribution workflow, closer to a pull request than a wiki. The hard part is the merge criterion: prompt edits should be settled by evidence, not by argument.
• Stand up the evaluation harness. For a given journal, does its prompt reproduce the concerns real reviewers at that journal actually raised? Start with venues that publish open reports (SciPost, eLife, PeerJ, PCI, EMBO) so this is measurable rather than a matter of taste. You design that measurement, not just implement it.
• Capture and publish the disagreement corpus: where an author pushed back on an AI review point and an editor took a view. Build provenance and usage rights into each record from the start.
• Generate first-pass prompts for any journal from its public aims, scope, and author guidelines, labelled honestly as unvalidated, so coverage follows real submissions rather than a preset list.
• Run the community: contribution guidelines, triage, review turnaround, release cadence, and the governance split between editor-controlled prompts and an append-only public case log. This is a real part of the job, not an afterthought.
• Talk to editors. Journals are wary of anything with "AI review" on it, and you are the person who has to be credible to them.

What we're looking for

• Strong full-stack engineer. You can take something from schema to deployed product without a handoff, and you have shipped things people outside your company used.
• You have maintained an open-source project with outside contributors, or run a comparable public community. We want to know how you handled a contribution you had to reject, and what you did when the maintainer burden got heavy.
• Direct experience with academic publishing from the inside: submitting, reviewing, or editing. A PhD is the usual way to have this and is what we expect, though we will take an equivalent track record over the credential.
• Evaluation as a discipline. You know why a naive LLM-as-judge setup is misleading, and you have at some point run a comparison that came out against the thing you had built.
• Senior enough to carry this alone from day one, and willing to report that the premise does not hold if that is what the evidence says.

Nice to have

• Work in or around scholarly infrastructure: preprint servers, OpenAlex, Crossref, PCI, overlay journals, reproducibility tooling.
• Published work on peer review, metascience, or research evaluation.
• Agent orchestration, prompt versioning, or evaluation pipelines in production.

What is genuinely unresolved

We would rather you knew this before applying than after:

• Whether per-journal prompt variation produces reviews that differ in any way an editor would care about. The paper driving this proposal tested a generic prompt against a tuned one, and outside citation retrieval the difference was small. The one dimension that maps to journal fit rested on three submissions.
• Where the line sits between an editor-controlled prompt and a community one, and whether editors get to veto community edits.
• How to name an unofficial prompt without implying the journal endorses it.
• How a public prompt stays useful once authors can iterate against it until they pass, which is both the point of the proposal and its central weakness.
• If those read as interesting rather than alarming, this is probably your kind of problem.

Why this role

• Peer review is one of the few remaining bottlenecks on the rate of science, and the standard everyone is about to depend on does not exist yet. You would be building it in the open, and deciding who gets to say what a review at a given journal is for.

Compensation and how to apply

• Salary plus meaningful equity; this is a founding position and the equity reflects that.
• Location: London, hybrid.
• Visa: we can sponsor work visas for the right candidate.
• To apply: send your CV to recruit.uk@xsci.com, along with a link to an open-source project you have maintained with outside contributors, and a short answer to this:
• Pick a journal you know well. Draft a review prompt for it from its publicly available guidelines, run it on any preprint in scope, and in under 300 words tell us how you would find out whether that prompt is better than a generic one. (The answer to the last part matters more to us than the prompt.)