Super cool work. I love seeing this direction taken all the way to hardware.
I'm a big fan of KANs. The really seem like the start of something big and new. We've got a couple of papers out and in the works on KANs. The most relevant to OP's is this one: https://arxiv.org/abs/2512.15742v2
Searching around github and found someone has put up a github repo with a Julia implementation of the article here including FPGA implementation of a KAN MNIST classifier in Verilog. https://github.com/philtomson/KAN_LUT
I played a somewhat unusual role in this whole story. I was the guy who acquired in the original Papers with Code and managed them after they joined Facebook/Meta.
It was super sad to see FB/M abandon the original mission of what PwC was building towards and let the original community resource rot. During the good times, we always talked about how PwC related to HF. So, I think there is a sort poetry to PwC winding up as part of HF, where they probably always belonged. No company is perfect, but HF has been a better than average steward of open source and community resources.
For the younger folks on this thread, you probably have no real feel for just how frustratingly inefficient AI/ML research used to be before people like Robert and Ross of PwC came along to start to bring structure, sanity, and reproducibility to the information needed to work of this kind. And of course, Clem, Julien, and Thomas of HF kicked off an even bigger effort to tame the previously scattered workflow of open AI research into some sort of sane stack.
It's clear that, in 2026, what PwC could be is something much more evolved than what we were able to do back in the day. LLMs + PwC is a huge design space. I hope nielz_r and friends at HF are able to make something truly useful for the community. AI research has both gotten way easier and much harder. e.g. We have a Fable, but Anthro won't let us use it forward our science. Community resources for research are still very much needed.
"Son of PwC" sure sounds like a compliment :) Let me know if you want to get in touch to discuss a bit more in-depth, I would be curious to hear some stories from the past!
To be fair PwC is a very well established initialism. It would be like saying HTTP but actually referring to something other than the well understood meaning of that thing.
I just don't see how you could have read the title (and comments) and not figured out that PwC was Papers With Code as a human, especially as it's mentioned in the comment with that acronym.
Burnin (London or NYC) | Founding Research Scientist + Founding Engineering Lead | Hybrid (Some on-site) | Full-time
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.
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.
I interviewed these guys for an article on the use of seaweed in yarn and fabric. And I bought the 3D knit seaweed sweater. Great team, with a lot of heart and good intentions.
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.
I have a small sweater line I’m looking at doing in china right now but I have a long lasting fascination with the shima seki machines. If you were doing a short fashion run would TI be appropriate? How does one get their preferred yarn over to someone like TI?
They definitely are a powerful option for smaller scale runs. Very much optimized to have the unit economics and turnaround time work for smaller brands.
I don't really know the answer around supplying your own yarn. I'd assume that's the abnormal case, but just a guess.
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.
It will maybe solved soon if we train yet another neural network on scanning GitHub activities; but by also adding other forges like codeberg, gitlab, self-hosted forgejo, etc... to not lock non-github users out
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.
Jeff, the author, here. We built a tool that scores PR authors by mining their contribution graph from the GitHub API. Every input is a merge/reject decision a human maintainer already made. It doesn't look at PR content or try to detect AI usage. It just answers: has this person gotten code accepted into projects before, and how relevant is that history to your project?
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.
I think this is really a key problem to solve, but I couldn't convince myself that it was the right solution. So, I put up my alternative proposal, Good Egg: https://github.com/2ndSetAI/good-egg
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
I'm a big fan of KANs. The really seem like the start of something big and new. We've got a couple of papers out and in the works on KANs. The most relevant to OP's is this one: https://arxiv.org/abs/2512.15742v2
And we just put up a general primer on KANs on YT: https://youtu.be/wgcSsJ69x1c?si=fiUl1YGTgaTt_bn9 Fun stuff if you want to get into the weeds.
And if you are really interested in KANs, you should really check out Ziming (KAN creator)'s blog: https://kindxiaoming.github.io/blog/