Being well read is a pillar of good science, but the volume of new papers makes it nearly impossible. The python code we used to keep up to date over the years, we’ve now made usable for everyone. Feel free to fork, copy, improve: https://t.co/tMBYdqFN3L
One of the things that made the Mythos release hard to interpret is that Anthropic held back details on most vulns they found, to give defenders time to patch.
1 month later, info from orgs with access to Mythos is starting to trickle out, e.g. this post from Mozilla today:
Science is about to get absolutely nuked.
Unless we get extremely strict about providing and opening up code and data and documenting lab experiments rigorously, a torrent of credible-looking but fraudulent papers is upon us.
Made a campaign promise tracker for the Tisza government. Keeping Péter Magyar on his toes.
https://t.co/orp8daA3L1
Repurposed our python based RSS reader code for tracking new scientific papers for tracking the news on promises kept / broken 😀
found the original 4k+ resolution artemis ii moon photos rather than the compressed 1080p ones official government accounts have been posting and the details are absolutely spectacular
https://t.co/NUGiefdfzK
Built an agentic workflow for paper-firehose. Ask "papers about organic solar cells from last week", it searches and ranks by semantic similarity, and can summarise any arXiv paper with Paper-QA. All conversational, all from the CLI. https://t.co/tMBYdqFfed
@InnaVishik Except maybe rhombohedral (ABC stacked) graphite. It's kind of like a "ladder" material, being 1D enough to be squeezed into DMRG calculations and can handle the X rays and anything else.
@ClaesBackman Made an update to this Claude Skill, for use in condensed matter research. Specifically in scanning tunneling microscopy, spectroscopy, etc
https://t.co/GL5X4l4ewt
@InnaVishik Just use your favourite coding agent to clean up your messy code and share the analysis as well. Here's an example, from one of our recent papers. The python code hosted on github, and the data is linked from Zenodo. https://t.co/0fJwFJYgEc
@InnaVishik Data sharing should be the norm, but that just a necessary condition to reproducibility. Why not share the data analysis as well? So that it's as frictionless as possible to actually look at the data. It's so easy to remove friction.
On DeepWiki and increasing malleability of software.
This starts as partially a post on appreciation to DeepWiki, which I routinely find very useful and I think more people would find useful to know about. I went through a few iterations of use:
Their first feature was that it auto-builds wiki pages for github repos (e.g. nanochat here) with quick Q&A:
https://t.co/DQHXagUwK0
Just swap "github" to "deepwiki" in the URL for any repo and you can instantly Q&A against it. For example, yesterday I was curious about "how does torchao implement fp8 training?". I find that in *many* cases, library docs can be spotty and outdated and bad, but directly asking questions to the code via DeepWiki works very well. The code is the source of truth and LLMs are increasingly able to understand it.
But then I realized that in many cases it's even a lot more powerful not being the direct (human) consumer of this information/functionality, but giving your agent access to DeepWiki via MCP. So e.g. yesterday I faced some annoyances with using torchao library for fp8 training and I had the suspicion that the whole thing really shouldn't be that complicated (wait shouldn't this be a Function like Linear except with a few extra casts and 3 calls to torch._scaled_mm?) so I tried:
"Use DeepWiki MCP and Github CLI to look at how torchao implements fp8 training. Is it possible to 'rip out' the functionality? Implement nanochat/fp8.py that has identical API but is fully self-contained"
Claude went off for 5 minutes and came back with 150 lines of clean code that worked out of the box, with tests proving equivalent results, which allowed me to delete torchao as repo dependency, and for some reason I still don't fully understand (I think it has to do with internals of torch compile) - this simple version runs 3% faster. The agent also found a lot of tiny implementation details that actually do matter, that I may have naively missed otherwise and that would have been very hard for maintainers to keep docs about. Tricks around numerics, dtypes, autocast, meta device, torch compile interactions so I learned a lot from the process too. So this is now the default fp8 training implementation for nanochat
https://t.co/3i5cv6grWm
Anyway TLDR I find this combo of DeepWiki MCP + GitHub CLI is quite powerful to "rip out" any specific functionality from any github repo and target it for the very specific use case that you have in mind, and it actually kind of works now in some cases. Maybe you don't download, configure and take dependency on a giant monolithic library, maybe you point your agent at it and rip out the exact part you need. Maybe this informs how we write software more generally to actively encourage this workflow - e.g. building more "bacterial code", code that is less tangled, more self-contained, more dependency-free, more stateless, much easier to rip out from the repo (https://t.co/iKJUoHiIpl)
There's obvious downsides and risks to this, but it is fundamentally a new option that was not possible or economical before (it would have cost too much time) but now with agents, it is. Software might become a lot more fluid and malleable. "Libraries are over, LLMs are the new compiler" :). And does your project really need its 100MB of dependencies?