Post training research lead. I post-train LLMs on software engineering capabilities. Opinions are my own.

Toronto, Ontario
Joined February 2017
What are the actual differences between RSI and autoresearch?
2
187
1/ For the past few months I've been a deep OpenClaw user: daily info gathering, catching up on X, scraping Zhihu and Xiaohongshu and stitching it all together, plus lighter work like paper analysis. Now I'm trying Meta's Muse, and compared to the old way of touching websites through the command line, a computer use agent is on a completely different level. Not an incremental upgrade. The experience is buttery smooth, zero worry about anti-scraping. There's a security angle worth thinking about: once you trust the agent with your credentials, how would a website ever tell it apart from you? Every action reads as a human acting.
2
2
200
2/ Once these agents get fast enough, the possibilities multiply. It's like having a secretary: I dictate, it runs the whole chain. Posting with OpenClaw was buggy and broke on every site update. That whole class of problem just vanishes. Same for buying things online, and especially for the tedious monitoring jobs: it can go find exactly what you're looking for, automatically. That part matters a lot. This very post is the demo. I dictated it with Typeless, had Muse translate it into English, then typeset and posted it straight to X. All the thoughts I used to lose to being too lazy to type or format now actually get recorded.
4
1
122
3/ I could do all of this before, technically. It was just never this smooth. To me the core of this product is how much mental overhead it removes. And if it goes beyond text into photo editing and video editing, the era where anyone can make videos is right around the corner, AI-generated shorts included. One rule I hold: it all has to start from my mouth, from what I actually want to say. That's what keeps me the author. I'm against posting AI content as if it were mine.
32
Congrats to the exceptional work out there and appreciated the comparison with our work MindForge! We have been constantly exploring way of curating high quality and diverse coding environments for coding agent post-training including both SFT and RL. At this point, scaling high quality coding environments are all you need!
CodeMidas: Scaling Agentic Coding RL Environments from Code Itself 🤗: hf.co/papers/2609.22068
1
4
652
The DeepSeek V4.1 report has one key sentence: "Tasks serve as the fundamental fuel for agent learning." Let's keep breaking that down today. Modern coding agents are driven by evaluation benchmarks, both internal and external. Well-known ones like Terminal-Bench, DeepSWE, NL2Repo-Bench, and SWE-Bench Pro (the report tracks several of these) are all monitored by model companies. Hill-climbing them is the first thing every model company does, because they're treated as the purest proxy for a model's raw capability. All of these benchmarks consist of carefully selected tasks with rigorous verification. A post-training team needs to collect, synthesize, and filter similar tasks from many sources, so that the model has seen enough of them to perform well. If a task type is missing from post-training (both SFT and RL), the model will do poorly on it. So the key is to find as many diverse tasks as possible. For SWE tasks, the solution seems straightforward: mine every PR on GitHub. This kicked off an entire line of research and industry work on converting PRs into executable, verifiable environments, with SWE-Gym as an early example. And as LLMs have gotten more capable, we no longer need a very complicated setup to get a decent conversion rate on those PRs. But the devil is in the details. Not all PRs are equal, and real-world data is messy. PRs can be misaligned with the issue they're supposed to fix (PAIChecker, ASE 2026, found this in 13.6% of SWE-bench Verified instances, and that's the curated benchmark, not the raw PR firehose), under-specified, or over-specified (which lets the model take shortcuts). Outsiders won't see any of this in a technical report, and it's why the DeepSeek folks say they "invested considerable effort in strengthening the model's task-construction and quality-verification abilities." In general, the bar for task quality rises from mid-training to SFT to RL. At mid-training, we want correct trajectories at very large scale (anywhere from 100B to 1T tokens). At SFT, we're looking at under 50B. At RL, what matters is whether the model can actually "absorb" what the environment has to teach. In the simplest case, we look for tasks the model solves about 50% of the time across N rollouts, which is where learning efficiency is highest. Much of the above requires substantial human effort. That's why many labs also spend a lot of money buying tasks and environments to complement their in-house pipelines. And SWE tasks are just the beginning, even though they're arguably the most crucial slice of the data.
3
1
5
319
well said, but it is very hard to judge.
it's basically impossible to interpret evals by looking at just at the pass/fail scores these days many of the failures I see in benchmarks are due to overly strict hidden tests, in some cases the model's answer makes more sense than the expected eval result
1
125
We've been working on post-training data for a while. A few things in the DeepSeek V4.1-Flash report resonate with what we've seen, and a few don't. SFT still dominates post-training, even though many papers and studies avoid talking about it. The reality is that a model needs to be "warmed up" enough before it's ready for RL. Tasks are messy. You might wonder: if everyone pulls the same tasks from GitHub and distills from the strongest teacher models available, shouldn't everyone end up with models of similar capability? The trick is that real, useful, high-quality tasks are very hard to get. It almost reminds me of the days when people were still working on RLHF, except this time the stronger labs (OpenAI, Anthropic, GLM, DeepSeek, etc.) have a lot of real user queries they can use as seeds to synthesize environments. That is the moat. So-called high-quality, high-diversity SFT trajectories are extremely hard and costly to obtain, and just as hard to measure. Even after we keep only the reward=1 trajectories, many of them can still be problematic: they might be reward hacking, or they carry a reasoning style you don't want the model to learn. And we usually only find out that a batch has problems after a pilot post-training run, which is very post-mortem and very costly. Overfitting to harnesses. You may have noticed more and more models converging on one or two harnesses while getting worse on the others. This is more evidence that only a few players are truly at the RL table. In most cases, post-training overfits to a few commonly used harnesses through SFT. RL is still useful, but its role is to make the model more general across harnesses, not to hill-climb benchmarks. Benchmaxxing happens through SFT (personal take: with the possible exception of OpenAI and Anthropic). A lot of people on X were dismissive when they saw DeepSeek's report. A one-liner like "it's just data" or "data matters" carries no weight and no useful information. What I can say is that data means tasks, environments, rollouts, and verifiers, and a data pipeline has a lot of knobs that researchers and engineers need to tune. It has become very sophisticated. It's a bit unfortunate that so little work discusses it. From now on, I'll keep sharing my thoughts on how to make data great, without the jargon. Shunyu Yao (Google DeepMind) once said that working on LLMs doesn't take IQ, it takes a very responsible team. Data is exactly the domain that needs this mentality.
6
250
I keep hearing that ppl say that currently nothing is important except for data. You know what brings you good data? Your expertise.
1
83
Going to have some time off for a couple of days, going to tune down the speed and catch up with some old posts in the bookmarks. Any good blogs, reports, and papers for post training these days?
92
Some random thoughts on trajectory data. It is super easy to make mistakes, however at the same time is super hard to detect ones. As some wrong trajectories’ impact wont show up until a training happening a few months later. To really make SFT great, one needs to use RL-like monitoring mechanisms to detect suspicious issues in realtime. Make me wonder if there is a need for companies like Datadogs but for trajectories. Insane flash back as I was doing research with logging in PhD and now digging things in the trajectories. Life!
1
117
Whenever ppl saw a model claiming themseleves as nother model, they just mock at it and think this is just some stupid mistakes in sft data. I can assure you that no serious model team would make such mistakes. Stop trying to think that you are the smartest person in the world. If you are willing to take one step further and let go of your ego and arrogance, read this blog. It does what the dunks don't: actually study the problem and chase the truth. Excellent work.
New blog: Why does Kimi identify as Claude and Sonnet 4.6 as DeepSeek? We find that this can come from a subliminal-learning-like effect: If you speak like Claude, you become Claude.
4
380
(1/n) 🧵 Coding agents have become good at editing code they can already see, e.g., bug fixes and feature patches. But ask them to build an entire program from nothing, and even frontier models fully solve <1% of ProgramBench tasks. A key bottleneck exists: there are no scalable training environments for this setting. Existing frameworks only cover single phases of development. We built a pipeline, MindForge, that teaches small models to do what even frontier LLMs struggle with: constructing complete software from scratch, through a software engineering lens. The results are surprisingly generalizable across the whole software engineering cycle. SFT on Qwen 3.6 27B, 📈 ProgramBench: 37.98% → 49.51% (+11.5 pts, +30% relative) — above DeepSeek V4 Pro (47.8%) and right beside GLM-5.1 (50.9%) and Claude Opus 4.7 (51.4%), models dozens of times its size. Moreover, the improvement generalizes to 7 benchmarks it never trained on: +31 pts on C→Rust repository translation, a 9× improvement on DeepSWE, +10.7 on NL2Repo, +5 on SWE-bench Verified, plus gains on SWE-bench Pro, Multilingual, and FeatBench — all statistically significant. How we did it?
3
3
319
Mindforge is an automated pipeline we built that converts open-source command-line programs into "source-free" training environments: the agent is given only a compiled reference executable and its documentation — never the source code. To succeed, it must work through the entire software-engineering life cycle: infer the specification from observed behavior, design an architecture, implement it, hunt down its own bugs, write tests, and iterate to a passing build. With this pipeline we: 🔧 Automatically constructed 562 cleanroom environments across 6 compiled languages (Go, Rust, C, C++, and more), with reproducibility and source-leakage checks at every step 🔧 Collected 1,001 whole-life-cycle trajectories from a teacher agent (GLM-5.2) — averaging 181 turns and 177K tokens each, covering spec exploration (99%), design (87%), debugging, testing, and refinement. 🔧 Refined them with infrastructure-noise recovery and surgical reasoning rewrites, so every training example is clean supervision And the behavior analysis shows it genuinely learned to engineer: it works ~2× longer per task (up to an 830-turn, 209M-token run) while its command failure rate drops, and it nearly doubles the rate at which reasoning and failure recovery turn into actual code edits — closing most of the gap to frontier agents.
1
146
Everything will be released and please stay tuned: the full pipeline, the 562 environments, the 1,001 trajectories, and MindForge-27B itself. 📄 Paper: arxiv.org/pdf/2607.27146 If you're working on coding agents, agentic training data, or small-model distillation — we'd love your feedback, and for you to build on this.
84
Boyuan (Nemo) Chen retweeted
What are the largest software engineering tasks AI can perform? To answer this, we built MirrorCode, our long-horizon SWE benchmark that lets AI code autonomously for days at a time. The best models complete some tasks we estimate would take human engineers several weeks.
13
47
15
294
93,531
Boyuan (Nemo) Chen retweeted
Replying to @ainativefirm
we can do a 1000-step agentic RL run on top of GLM-5.2 in 3 days for <$50k, and serving is straightforward pretty easy to justify if you burn a lot of tokens on a workload
7
5
2
187
7,935
Your AGENTS.md may be silently wasting agent steps. Probe-and-refine tunes repo guidance with synthetic bug-fix probes: 33.0% SWE-bench Verified vs 28.3% for a static KB. The gain is coverage: more evaluable patches, same precision. arxiv.org/abs/2606.20512
2
93
well said indeed. I think industry grade rl is still at an early stage where each run is so expensive that only a small group of players can participate. Looking forward to more work like this moving forward.
TMax: An open RL recipe for terminal agents I’m very excited to get to share a new RL paper today that I got to have a small part in – a type of paper I suspect we’ll see much more of in the future. The key is that RL research is very different today, in mid-2026, than what most observers have in their context. The average conception of an RL paper is grounded in the RLVR revolution of early 2025, where many people could use vanilla RLVR libraries to hillclimb on math benchmarks. Crucially, this style of math work could be done on base models or fairly stably on already trained models. With agents, the tasks of focus are very hard, requiring complex tool-use, harnesses where the model automatically manages its history, and much more training to make smaller eval improvements. We’re shifting from a renaissance of RL study to rapidly needing to improve its empirical rigor and common community engagements. TMax is the best open data for hillclimbing on frontier terminal tasks. It’s been validated with rigorous experiments, and if the authors wanted to just form a “RL environments startup” they could probably sell it for millions of dollars. This data work is some of my favorite stuff to be around in my 2.5+ years at Ai2. As a general summary, the recipe is open data and recipe lessons from hillclimbing the Qwen 3.5 smaller, dense models on terminal tasks. These models are super hard to hillclimb in this area, as they’re already trained heavily on the task. The training is very infrastructure-dependent, and most of the RL innovations are more designed to make training stable than to improve the rate of learning. I strongly recommend this paper. I joke around that I was happy to be an author just so I had to read it twice! You can find Hamish’s thread sharing more here or read the paper here. You can click through to find the model weights, the data, and even some fun further artifacts to study like all the RL rollouts from a training run – where the model sometimes became aware that it was being tested. The biggest takeaway I have from following this work, and more of the work in the community, is how important recipe work is. Let me define “recipe work.” It is a style of paper that explains all the steps you need to make crucial model improvements – data, algorithm, codebase, pitfalls, etc. Getting started in meaningful RL experiments today is a substantial expense. There are a ton of companies, an entire industry emerging really, around the idea of taking open-weight language models and finetuning them with RL on your domain-specific tasks. What I see in many projects is that getting an initial baseline is very hard. This phase, which can cost weeks and anywhere from $10K to $1M+, feels like spinning your wheels (A fun fact is that an RL step on a model like Nvidia Nemotron 3 Ultra on Tinker costs $1K and a meaningful RL run would be hundreds of steps – credit Edward Hu). It takes a lot of time to get traction in learning signal on meaningful, hard RL tasks. What we need as a community is a way for people to study small ablations to established RL recipes, as most labs won’t have the resources to do it from scratch in a meaningful way. This is what I hope TMAX can be for terminal agents, or the start of. Yes the training jobs are expensive, as the paper documents a standard training job being 8 nodes of H100s (2 train 6 inference) for 2-3 days, but that is approaching something academics can study. The establishment of this recipe took O(100) of these training jobs to get right. This isn’t my first time trying to establish this direction. When we launched Olmo 3 we had the “RL Zero“ model families, which are clean RL runs from a base model on a certain domain. This type of recipe-dependent work is a clear indicator that meaningful post-training work today looks much more like pretraining work of years past. We need decision-making ladders, clear ways of seeing small improvements in the models, stability, and so on. Part of this is down to academic gatekeepers, who won’t reward a paper doing very clean empirical work to push a recipe 1-2% up. They’ll favor a “new algorithm” that matches results, or something sort of bogus. My hope is that we can have multiple, stable, clear recipes across agent types, so innovations can be tested more clearly in multiple domains. (If you’re working on this, please reach out – I’m happy to support if I can, but I likely can’t reply to every email). As a quick aside, the RL frameworks in vogue today seem to be SLIME and SkyRL. The libraries of choice have shifted throughout these seasons in RL, which further contributes to a form of fragility in the literature. A bit of continuity will go a long way. So, go read this paper. It’s a really great example of how seemingly simple data and infrastructure work can be very hard and impactful. It’s also got me looking for more applications of Divergence Proximal Policy Optimization (DPPO) as another small evolution to the best RL algorithms of the day, by virtue of being a bit more stable by improving token-level clipping.
2
4
296