Jay Baxter
Where to hear and read about Jay Baxter1 episode or test
Jay Baxter is the founding ML engineer on X's Community Notes, where he built the algorithm that shows a note only when people who usually disagree rate it helpful. The most useful lesson from him is to let real data reveal the actual problem before locking in an algorithm, then keep the system lean enough to stay open and trusted.
deleting code is more important than writing it a lot of the time.
An inside look at X’s Community Notes | Keith Coleman & Jay Baxter
Jay Baxter: the story and the lessons
1Who Jay Baxter is and why he joined Community Notes
Baxter is the founding ML engineer behind Community Notes. Keith Coleman leads the product and Baxter built its machine learning. The system has survived four leaders and been adopted by Meta.
The original team was about five people: backend, client, ML, design and research.
Baxter gave up a safe project to join the team. He left a low-risk push-notification project that lifted daily users to work on Community Notes.
Nobody was assigned to the team. People reached out or applied, and Coleman's team interviewed every one, so everyone had bought into the mission.
2How Baxter built the Community Notes algorithm
Baxter's first production algorithm was a PageRank variant built to resist manipulation. It filters voting rings well, but it can amplify bias when one side has more users.
Voting rings turned out not to be the main attack anyway.
Pilot data showed polarization, not manipulation, was the real problem. Bridging was chosen only after real pilot data came in. The idea had roots in Chris Bail's list of accounts liked by people on both sides, which Coleman found.
Baxter's approach was to keep one engineer on the problem while requirements were unclear, then add more once the goal was clear.
Baxter ran a Kaggle-style bake-off to find the best bridging approach. Once bridging was the goal, he set up an internal competition and brought in other engineers to compete on it.
In his words: "basically I set up a bake-off. Kind of a Kaggle competition or something."
The algorithm shows a note only when past disagreers both find it helpful. A simple majority vote would produce biased or inaccurate notes, so it looks for agreement across divides. It bootstrapped with no fact-checker labels.
In 2020 a room of ML engineers would have predicted an open system would be manipulated and would need ground truth labels. Raters who keep rating bad notes helpful stop being counted.
The 0.4 cutoff is a model artifact, tuned conservatively against user feedback. It sits on an arbitrary scale from matrix factorization fit with gradient descent. On a polarized topic it means a sizable majority on both sides finds the note helpful.
The team picked it by sharing many notes and watching where feedback moved from questionable to clearly helpful. Only about 8% of proposed notes show, because showing a bad note is the worst mistake.
Baxter's team modeled the Messi versus Ronaldo debate as it modeled politics. Raters split into diehard fans of each player, much like on politics, so the team estimated each person's opinion on that debate.
Users invented this use, along with flagging spam, and the team responded by modeling it.
3Baxter's case for deleting code
Baxter says deleting code often matters more than writing it. A one-month A-B test hides the long maintenance cost of a small win, and promotion incentives push engineers to keep adding features.
Small wins keep costing upkeep until the feature is turned off.
After the layoffs the team audited its systems and cut what cost too much. They removed features whose upkeep cost more than they gained, and they did not rewrite everything.
The systems became leaner and workable by fewer people.
4What the system Baxter helped build has shown
The code and data are open, so anyone can rerun the system. The full algorithm runs in about a day on one machine with about 500 GB of RAM. Vitalik Buterin reran it to verify it.
Matrix factorization is normally trained once and served from a separate service. Here it had to run as a script on downloaded data, which forced unusual architecture.
There is no admin override, so a bad note means a flawed system. The company has no button to change a note's status. A problem bad enough to act on means redesigning the system.
Staff were unsettled by this at first, but it is central to why the product is trusted.
The team shipped speed and coverage features weeks before the Israel-Hamas surge. Image and video matching and a speed-up that cut three hours off time to go live launched before the October 2023 conflict. About 500 notes appeared in the first three days, with a median of five hours from post to note.
Typical fact checks take two to four days.
Notes cut reposts sharply without any ranking change. Likes and reposts fell 30 to 40% in A-B tests, and outside studies found total reposts drop 50 to 60%. Authors are 80% more likely to delete a noted post.
Whether a post was noted is not used in the core ranking algorithm. In 2024 about 95,000 notes were seen about 30 billion times.
An inside look at X’s Community Notes | Keith Coleman & Jay Baxter
Community Notes shows how a tiny, opt-in team with one decision-maker, a bridging-based algorithm and strict principles of openness and trust can build an internet-scale information system. Notes were seen about 30 billion times in 2024, cut reposts by 50 to 60%, and Meta has since adopted the approach.
Baxter is the founding ML engineer behind Community Notes. Keith Coleman leads the product and Baxter built its machine learning. The system has survived four leaders and been adopted by Meta.
The original team was about five people: backend, client, ML, design and research.
Baxter gave up a safe project to join the team. He left a low-risk push-notification project that lifted daily users to work on Community Notes.
Nobody was assigned to the team. People reached out or applied, and Coleman's team interviewed every one, so everyone had bought into the mission.
Baxter's first production algorithm was a PageRank variant built to resist manipulation. It filters voting rings well, but it can amplify bias when one side has more users.
Voting rings turned out not to be the main attack anyway.
Pilot data showed polarization, not manipulation, was the real problem. Bridging was chosen only after real pilot data came in. The idea had roots in Chris Bail's list of accounts liked by people on both sides, which Coleman found.
Baxter's approach was to keep one engineer on the problem while requirements were unclear, then add more once the goal was clear.
Baxter ran a Kaggle-style bake-off to find the best bridging approach. Once bridging was the goal, he set up an internal competition and brought in other engineers to compete on it.
In his words: "basically I set up a bake-off. Kind of a Kaggle competition or something."
The algorithm shows a note only when past disagreers both find it helpful. A simple majority vote would produce biased or inaccurate notes, so it looks for agreement across divides. It bootstrapped with no fact-checker labels.
In 2020 a room of ML engineers would have predicted an open system would be manipulated and would need ground truth labels. Raters who keep rating bad notes helpful stop being counted.
The 0.4 cutoff is a model artifact, tuned conservatively against user feedback. It sits on an arbitrary scale from matrix factorization fit with gradient descent. On a polarized topic it means a sizable majority on both sides finds the note helpful.
The team picked it by sharing many notes and watching where feedback moved from questionable to clearly helpful. Only about 8% of proposed notes show, because showing a bad note is the worst mistake.
Baxter's team modeled the Messi versus Ronaldo debate as it modeled politics. Raters split into diehard fans of each player, much like on politics, so the team estimated each person's opinion on that debate.
Users invented this use, along with flagging spam, and the team responded by modeling it.
Baxter says deleting code often matters more than writing it. A one-month A-B test hides the long maintenance cost of a small win, and promotion incentives push engineers to keep adding features.
Small wins keep costing upkeep until the feature is turned off.
After the layoffs the team audited its systems and cut what cost too much. They removed features whose upkeep cost more than they gained, and they did not rewrite everything.
The systems became leaner and workable by fewer people.
The code and data are open, so anyone can rerun the system. The full algorithm runs in about a day on one machine with about 500 GB of RAM. Vitalik Buterin reran it to verify it.
Matrix factorization is normally trained once and served from a separate service. Here it had to run as a script on downloaded data, which forced unusual architecture.
There is no admin override, so a bad note means a flawed system. The company has no button to change a note's status. A problem bad enough to act on means redesigning the system.
Staff were unsettled by this at first, but it is central to why the product is trusted.
The team shipped speed and coverage features weeks before the Israel-Hamas surge. Image and video matching and a speed-up that cut three hours off time to go live launched before the October 2023 conflict. About 500 notes appeared in the first three days, with a median of five hours from post to note.
Typical fact checks take two to four days.
Notes cut reposts sharply without any ranking change. Likes and reposts fell 30 to 40% in A-B tests, and outside studies found total reposts drop 50 to 60%. Authors are 80% more likely to delete a noted post.
Whether a post was noted is not used in the core ranking algorithm. In 2024 about 95,000 notes were seen about 30 billion times.