Two posts ago, R and D were two roles, two rulebooks, one person switching hats. Last time was D’s story: the loop that made shipping safe. By now the two don’t split cleanly — every decision and every build happen in the same conversation. This round adds a third: QA, an external auditor with no stake in the code already being good, brought in specifically to check R and D’s work from the outside. ...
Everyone has discovered that AI writes code fast. The harder question is when you can trust what it wrote — especially if you weren’t watching while it worked. This post is the playbook I use for that: which tasks go to which AI agents, when work can run in parallel, and why the agent that builds something never gets to declare it done. It’s battle-tested. Twice, this workflow caught AI confidently misreporting its own work — both incidents are below, receipts included. ...
Last time, I split the two weeks of building Omnist into two teams of one: a Research Assistant for conceptualization, a DevOps team for materialization. R and D ran together the whole time. Every cycle was the same: decide, build, decide again. These next two posts split that loop by role, not by time. This one is R — three decisions, and why they went the way they did, before each spec became D’s problem to build. Next time is D: the same three decisions, from the side that answered how. ...
The initial implementation of Omnist, a tested, open-source Python library, came together from a 16-year-old PhD paper in two weeks — one person, part-time. That fact tends to get read as “AI writes code fast.” It doesn’t quite explain it. What actually happened: I ran two teams during those two weeks, not one. I was the only human on either of them. Two layers, two teams Split any R&D project into two layers. Conceptualization: interpreting the idea, deciding what’s true, choosing what to build, naming things so they make sense. Materialization: turning a decision into working code, a test that proves it, a release someone can actually install. ...
Sixteen years ago, in 2010, I published a paper on formalizing schemas for tree-structured data, like XML and JSON. My goal was to move beyond guesswork: could we mathematically decide if a schema change is backward-compatible? I wanted to see if we could prove schema equivalence, or reliably infer schemas from examples. The research offered a solid theoretical framework, though it remained largely academic. For years, I hoped to build something practical from it. But the demands of a full-time job made finding the time nearly impossible. ...