We are building the trust stack for AI code generation, targeted at high-stakes computing where wrong numbers cost real money: a statically typed functional language designed for coding models, a compiler whose guarantees double as audit-grade trust infrastructure, and a coding model fine-tuned on the language with compiler fitness as the training signal. Language and model are co-designed.

Small team out of PyTorch, FAIR, and Meta. Strong institutional VC support from our pre-seed; active investor interest heading into seed.

Founding Research Scientist: own the agenda across the language and the model. Type system design, compiler analyses that produce useful fitness gradients, and fine-tuning open-weight coding models on a language with no pretraining footprint. Publish in PL and ML venues. Strongest fits cross between machine learning, programming languages, and formal methods. PhD preferred, equivalent output equally fine. Stack is Rust, Lean 4, Python.

Founding Engineering Lead: own engineering across compiler internals, language runtime, GPU backends, notebook and library tooling, and the AI infrastructure around training, evaluation, model release, and likely public inference. We already support x86 and ARM, CUDA and AMD, macOS and Linux, and the matrix grows. Real feel for statically typed functional programming expected; the kind of engineer who picks up Lean or Haskell on a weekend because they wanted to. Have led engineering before, formally or not. Stack is mostly Rust with Python where it earns its place, primarily on AWS.

Both roles: comfortable with early-stage ambiguity, define your own roadmap, defend it with evidence.

Apply: RS: https://wellfound.com/l/2Carrr Eng Lead: https://wellfound.com/l/2CewDC

Socials: YT: https://www.youtube.com/channel/UC4DLS_emqwKXO7A9qaOtxlw SS: https://burninai.substack.com/

We ran three experiments since v1 that changed the model substantially.

We tried to detect suspended GitHub accounts from behavioral signals (merge rate, network centrality, TF-IDF on PR titles, LLM classification with ~31K Gemini calls). Best individual AUC was 0.619 on a 1.9% base rate. The merged-PR population is too homogeneous. Accounts that pass code review look like everyone else. The interesting finding: the suspension rate among contributors with merged PRs is under 2%. The review process is a better filter than the discourse around AI slop suggests.

That led us to question the scoring model. The graph score (bipartite construction, personalized ranking, language normalization, the whole pipeline from v1) actively hurts predictions for the contributors who actually need scoring: unknown people with a handful of merged PRs. Merge rate alone outperforms merge rate plus graph at every tier we tested. The new default model is merged / (merged + closed). We also pulled account age out of the score into a separate advisory after DeLong tests showed it adds nothing once you condition on merge rate.

The post has the full data, including the tables.

Next we're working on content scoring (does this PR fit this repo's conventions?) and cold-start tooling (helping new contributors understand project expectations before they submit). Contributor reputation is one input to review triage. The PR itself carries more signal.

Repo: https://github.com/2ndSetAI/good-egg

pip install good-egg

Or just run it via uvx.

Comments URL: https://news.ycombinator.com/item?id=47402184

Points: 1

# Comments: 1

I don't really know the answer around supplying your own yarn. I'd assume that's the abnormal case, but just a guess.

I'm also a hand knitter, and I don't really see any conflict between what they're doing and hand knitting. The grist of the yarn that you use as a hand knitter is generally much thicker than these machines commonly use. Commercial 3D knitting machines can do all of the stretchy, thin, and light stuff that the modern wardrobe is built around.

As folks note, this technology was really pioneered by Shimaseki's work in Japan just decades ago. What OC and the similar Brooklyn-based Tailored Industry are really innovating on is the business model and connection to production process. Folks like this are really serious about not producing all of the waste that comes with most fashion production processes, and it shows up at several levels of the stack.

For the HN crowd, TI's platform gives you more of a sense of why this sort of tech is really like the cloud for knitwear: https://tailoredindustry.com/platform

Really a fascinating part of the global fashion production world, and one we would all benefit from seeing grow.

Thanks for the idea.

Yeah, scanning non-GitHub is on the roadmap and really should be done. I expect there would be value in understanding all of the current GitHub competitors. And I think the forecasts of new GH competitors getting launched (likely by AI companies) will become relevant in the near future.

One thing I've been working with is this little util to try to do a quick sniff test on the contributors: https://github.com/2ndSetAI/good-egg (Longer explanation on Substack: https://neotenyai.substack.com/p/scoring-open-source-contrib... )

From what I've seen in the data, acceptance rates to all major OSS projects are down since the age of coding agents.

And when I talk to maintainers, most of them are talking about some version of doing fast and easy pocket vetos (leaving the PRs to rot) or even just banning on the first offense.

It's been building for a bit, but I think the crisis point is solidly here. And things like OpenClaw turn up the dials. I'm sure more tools and changes to practices will be coming.

The scoring is graph-based (bipartite user-repo graph, personalized ranking, 180-day recency decay). Scores are context-specific, so the same person can score differently against different repos. The post walks through how Guillermo Rauch scores MEDIUM against his own company's Next.js repo because he has zero merged PRs there, and how v2 rescues that with merge rate and account age.

We validated on 5,129 PRs across 49 repos. Three features survived statistical testing, four didn't. The most surprising failure: text similarity between PR descriptions and project READMEs predicted lower merge rates. We published all of it, including the failures.

More detail on the Substack post.

Repo: https://github.com/2ndSetAI/good-egg (MIT, pip install good-egg). Runs as a CLI, GitHub Action, Python library, and MCP server.

Comments URL: https://news.ycombinator.com/item?id=47151678

Points: 1

# Comments: 1

Key differences: - Based on commit history, with nuance around relatedness of projects, types of projects, age, etc. - Requires no ongoing work. Just add it to your GH Actions CI. - Agent ready with an MCP interface, Python lib, and CLI

Discussion on HN here: https://news.ycombinator.com/item?id=46960412

Feedback and PRs welcome.

But the challenges are real. AI-generated code slop and low-quality submissions are flooding projects. Contribution volume is up; signal-to-noise is down. Maintainers can no longer assume a PR represents genuine investment.

Good Egg is a tool I built to help. It mines a contributor's merged PR history across the GitHub ecosystem and computes a trust score relative to your project. The core idea: good contributors are already exhibiting good behavior -- merged PRs in established repos, sustained contributions over time, work across multiple projects. That track record is a strong signal, and it already exists in the GitHub API.

How it works:

- Builds a bipartite contribution graph (users ↔ repositories) from merged PRs

- Applies personalized graph scoring biased toward your project and language ecosystem

- Accounts for recency decay, repository quality (stars, language normalization), and anti-gaming measures (self-contribution penalties, per-repo caps)

- Classifies contributors as HIGH / MEDIUM / LOW / UNKNOWN / BOT

The methodology doc goes into the full detail: https://github.com/2ndSetAI/good-egg/blob/main/docs/methodol...

Runs four ways:

- GitHub Action: drop it into any PR workflow and get a comment with the score - CLI: good-egg score --repo - Python library: await score_pr_author(login, repo_owner, repo_name, token) - MCP server: plug it into Claude or other AI assistants

On Vouch and the circle-of-trust approach:

Mitchell Hashimoto's Vouch takes a different angle: maintainers manually vouch for contributors they trust, building a web-of-trust. I think that's a valid approach and have seen circles of trust work well (on PyTorch specifically, where contributors came from all over, including major corporate partners). But I've also seen gaps that could easily be filled by a bit of data that already exists. Vouch requires active maintainer participation in a separate system and has a cold-start problem. Good Egg is complementary. It's automated, doesn't ask maintainers to do extra work, and works from day one on any repo.

What it doesn't do:

Good Egg doesn't send data to any remote service. It reads from the GitHub API, computes locally, and that's it. I'm not building a training set or a contributor database. This is just a tool for the community.

Configuration and extensibility:

Scoring parameters (thresholds, graph weights, recency decay, language multipliers) are all configurable via YAML or environment variables. More extensibility is planned, particularly around additional data sources (e.g., GitLab) and methodology variations like graph-based project relatedness and incorporating review/issue activity alongside PRs.

Code: https://github.com/2ndSetAI/good-egg PyPI: pip install good-egg Docs: https://github.com/2ndSetAI/good-egg/tree/main/docs

Comments URL: https://news.ycombinator.com/item?id=46960412

Points: 4

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=45993118

Points: 20

# Comments: 3

As his longtime colleague, the one thing I would want people to know about him and this decision is that Soumith has always viewed PyTorch as a community project. He consistently celebrated the contributions of his co-creators Adam and Sam, and he extended the same view towards the Yangqing and the Caffe2 crew that we merged into PyTorch. At the very beginning, by Soumith's highly intentional design, PyTorch was aimed at being truly developed by and for the AI research community and for many years that was the key way in which we grew the framework, FB PT team, and the wider community. At every single stage of PT's lifecycle, he always ensured that our conception of PT and its community grew to include and celebrate the new people and organizations growing what was possible with PT. He's an incredible talent magnet, and thus more and more smart people kept dedicating their blood, sweat, and tears to making PT bigger and better for more people.

I've worked with some very well known and highly compensated leaders in tech, but *no one* has done the job he has done with ameliorating a bus factor problem with his baby. PT has a unique level of broad support that few other open source technology can reach. In a world of unbounded AI salaries, people who want to move AI research methods forward still freely give their time and attention to PyTorch and its ecosystem. It's the great lever of this era of AI that is moving the world, *due in large part* to the strength of the community he fostered and can now let continue without his direct involvement.

His departure is the end of an era, but it's also operationally a true non-event. PyTorch is going strong and can afford to let one of its creators retire from stewardship. This is precisely what success looks like in open source software.

He deserves our congratulations and our thanks. Enjoy your PT retirement, man.

We analyzed 18 models and found that no single model is good at everything. For example, GPT-4o has the best safety guardrails but also a 98% IP infringement rate on celebrity likenesses. Google's Imagen 4 Ultra actively counters bias (e.g., 90% of its "CEOs" are female) but struggles with generating crowds. X AI's Grok 2 blocks almost nothing.

Lots more detail in the post. We'll be here all day to answer questions.