Justin Johnson

If you lead a team and you have never built anything with these tools yourself, there is a decent chance you are the reason your team hasn't either. Microsoft measured it across tens of thousands of its own engineers. Someone whose own manager used the tool was 82 percent more likely to try it. Then they checked whether managers were picking it up, and managers looked no different from anyone else. No more likely than a mid-level individual contributor. No less. The one person whose adoption moves everybody else's is the one person nobody is counting on to move first. They measured engineers because that is where the telemetry was. Nothing in the mechanism is about engineering. Everyone is quoting the same line: one person is 10x'ing their output while the rest of the org hasn't caught up. The reply that got the room nodding rewrote the second half: one person is 10x'ing their output while the rest of the org is busy dealing with the resulting mess. Which one you get is not decided by the model. Anthropic's new adoption ladder puts a bottleneck on every rung and the model is never one of them. Attention. Reviewing output. Trust in the loop. Decision throughput. 10x only lands if the organization can absorb it, and the limit is how fast people can read what came out and put their name on it. Past that, work either queues until it goes stale or ships unread. The second one is the mess. You also cannot govern your way out of that from a distance. A leader who has never run the loop cannot tell a working verification stack from a slide that says Verification. They will approve the slide. They approve the slide constantly. What worked when I ran this at a Fortune 500 was not a program. Cross first yourself. Build something real in your own domain, badly, then less badly. Then teach the handful of people closest to you, not with a presentation but by showing them the thing and the scars on it. They teach the people next to them, and that part moves faster than you can. You already know which rung you're on. The number you don't have is the other one: what your reports' odds would be if you were on it. The full piece has the study, the ladder, and the two best arguments against all of it: glyf.cc/rdr-ladder-2

Full piece: glyf.cc/rdr-2026-07-co…

A team at Cognition just swapped in a model that costs about twice as much per token, and their bill went down. Not their quality. Their bill. The expensive model, wired up right, came out better and cheaper than the cheap model on its own. That should stop anyone who has ever sat in a meeting where someone proposed saving money by dropping a model tier. It stopped me, because I had built the opposite. I made a cost router that sent easy tasks to a cheap model and kept the expensive one for the hard ones. It saved nothing. Not a little less than I hoped. Nothing. The reason is the whole piece. I routed by task type. The axis that actually pays is ambiguity. A cheap model is expensive on an open question and cheap on a closed one. Hand it something where a decision still has to be made, and it will not tell you the question is open. It picks an answer, sounds sure, and gives you something plausible you now have to check line by line. Hand it something already decided, rename this function in these three files, and it does the job for a fraction of the price with nothing at risk. Which means the expensive model's real job is not "the hard parts." It is turning open questions into closed ones. That has a name we already use. It is a plan. So the small-model excitement is not really a cost story. If you can specify a task tightly enough to train a small model on it, you have already proved the task is closed, and someone did the expensive work of deciding. A small model is not a discount. It is a receipt for judgment already spent. Full piece on Run Data Run.

The open-weight frontier had a week. Thinking Machines Lab shipped Inkling, 975B params with 41B active, multimodal. Kimi K3 dropped right behind it. Two labs putting frontier-scale weights in the open in the same week. The gap to the closed models isn't the story anymore. The pace is.

A month ago I put Claudelicious online, the open cookbook for the Claude Code harness I run. Here's what the harness did since. Measured an undocumented 8,000-token output cap on every subagent, and found that thinking counts against it, so cranking reasoning effort kills the agent before it writes a word. Filed upstream: anthropics/claude-code#78460. Shipped a skill that routes bulk coding onto flat-rate model subs and keeps judgment on the flagship. And one that reads any repo or paper and returns borrow, build, or skip. That one proved itself by building the next skill. Audited my own setup and found 21 dead agents still loading into every session. An underscore in the folder name doesn't hide them from Claude Code. 88 skills, 27 agents, 13 hooks, one session-search index across four machines. It's all in the cookbook, and it's free.

Full piece: glyf.cc/rdr-2026-07-no…

In 2016 an OpenAI agent was told to win a boat race. Instead it found a lagoon where three targets respawned forever, spun in a circle farming them, caught fire, never finished a lap, and scored about twenty percent above the average human. It did exactly what it was asked. Nobody had checked what they asked for. Every executive reading this has approved that boat's quarterly results. My new piece is about the failure that leaves no corpse. Your risk registers, incident reviews, escalation paths, all of it is built for the failure that announces itself. Something breaks, someone notices. But an AI collaborator is fast, willing, and it will improve whatever task you hand it without ever asking if the task was the right one. A dead instrument leaves a crash. A month spent perfecting the wrong thing leaves a green dashboard and a satisfied changelog, and nothing will ever alert you. I kept a ledger of my own versions. Written up, seventy mistakes turned out to be five, wearing different clothes: a frame nobody chose, an instrument that says PASS when it is broken, silence read as an answer, a summary that outlived the fact it summarized, and a correction made of the same bug it was fixing. The one that costs the most is the one that never gets written up, because nothing visibly breaks. When I swept 314 of these, that shape was the emptiest bucket. A failure that leaves no corpse does not leave a case file either. And the humbling part. Sixty-eight of the sixty-nine were bought while a document containing almost all of these lessons was loaded into every session. Knowing the rule does not run the rule. Full piece on Run Data Run.

Full piece: glyf.cc/rdr-2026-07-wo…

Seven weeks ago Anthropic shipped a way for Claude to split a job across dozens of AI workers at once and check its own work. I called the economics on day one, and I was right about the easy part. Running it every day since taught me the part I got wrong. The cost math held. Fifty parallel workers used to be a budget event. Now it's a Tuesday. My own rule flipped: for anything I build, I fan the work out by default and only pull back when there's a reason not to. What I could not see in May is that the checker is the part that decides whether any of it worked, and the tool caps how well it can do that job. Every worker gets a hard ceiling on how much it can say in one reply, and the model's own thinking eats that budget. Turn the reasoning up, which is the default, and a checker asked to think hard about whether a bug is really there can run out of room and die before it says a word. No error. No crash. It comes back empty, and empty reads exactly like all clear. A checker that looks like it ran and returns nothing is worse than no checker, because you trust the green light. The fix is mechanical once you know the ceiling is there. Most people building their first checker don't, and the defaults hide it. So the tooling got cheaper. The taste did not. The question stopped being whether the model is good enough. It became who is verifying, and can your verifier afford to think. Full piece on Run Data Run.

running kimi k2.7 locally. the real tell isn't the benchmark gap. it's how fast you can iterate on a model that's close enough. 'frontier' matters less when the next tier is two months away and costs nothing to run.

@EricTopol lp(a) is one of those cases where the evidence base arrived years before the drug pipeline. AI in clinical trial design should compress that gap. the data exists; the translational layer was always the rate limit.

At least 10% of the population has a significantly elevated Lp(a) above 50 mg/dL (~125 nmol/L), which carries an increased risk of atherosclerotic cardiovascular disease. While we've known that for decades, we've never had a drug to treat it. There are 5 programs in advanced trials (Table below, 3 in phase 3, pivotal, CV outcomes as endpoint). We may see the results for the first drug (pelacarsen) soon, by end August, and FDA approval is expected in 2027. This likely represents a major advance for preventing heart disease, adding to the first oral PCSK9 blocker approved this week.

the 'simply too compute poor' thesis missed the efficiency variable entirely. seen this play out inside big pharma: a smaller team with fewer approval layers ships faster. raw scale is overrated when the org above it is slow.

@reach_vb built this pattern into our agent infra over the past year. the real unlock beyond archiving: session history is the cheapest labelled dataset you have. shows what you actually use vs what you think you use. underrated signal.

codex tip: ask codex to look through your sessions and archive one-off queries and organise your projects better I have it running as an automation, keeps my side bar focused

the analogy works. what survived the x86/linux commodity wave wasn't the hardware vendors. it was the software with deep workflow integration: oracle, sap. same dynamic here. whoever has the domain workflow and data layer on top wins. life sciences will be the clearest test case.

expected trajectory. the model is commoditizing. what isn't is the routing, the evals, the domain context. teams that built solid harness infrastructure last year are quietly opening a gap that model improvement alone won't close.

Full writeup: glyf.cc/aix-2026-07-au…

"A CPU-only PyTorch wheel installs without a single error and runs twenty times slower in total silence." That line is the whole reason this build worked. I spent an afternoon replacing Audible with a pipeline I own, and Claude Code wrote most of it. Free books in, audiobooks out, streaming to my phone. The stack: pull a public-domain book from Standard Ebooks, render it to a chaptered M4B with Kokoro-82M, a 330MB Apache-licensed model that runs faster than realtime even on a laptop CPU, so no GPU required, then serve it with Audiobookshelf so it streams to the phone with chapters, resume, and offline. New renders just show up. The practitioner half is where the agent kept being confidently wrong, in narrow catchable ways. A 19.5k-star tool that could not drive Kokoro at all. A module-scope import dragging a broken dependency into memory. A Docker image that failed at the one thing it existed to guarantee. A curl that exited 0 and wrote an HTML page named book.epub. None of them threw an error. Every one was caught by checking the artifact instead of the exit status. Gate on the artifact, never the exit code. That is the review discipline an exoskeleton needs. Also in the post: what I could not verify, which is long-form drift past 10 hours, and why the open-TTS benchmark web is mostly laundered vendor marketing. "'I could not measure it' is a finding. 'It works' is a hope wearing a finding's clothes." Full writeup in the link.

Three numbers in sixteen days. Anthropic's Claude Code lead published an adoption ladder this week and opened it with a line he says he hears constantly: one person is 10x'ing their output, and the rest of the org hasn't caught up. Eight hours earlier, the CEO of Replit said his own engineers had 3x'd theirs in six months. Fifteen days before either of them, three researchers at Microsoft instrumented tens of thousands of engineers for four months and measured 24 percent. The number falls as the instrument sharpens. But the size is not the interesting part. How it spreads is. Microsoft found that first use travelled through social networks, not down through mandates. An engineer whose skip-level peers were largely using the tool had 216 percent higher odds of trying it themselves. That was the strongest signal in the study. Sideways. Through the people you already trade work with. Except it needs a light. When an engineer's own manager used the tool, that engineer was 82 percent more likely to try it. And on whether managers picked it up themselves, the paper says they looked no different from anyone else. No more likely than a mid-level individual contributor. No less. The one person whose adoption moves everybody else's is no more likely than anybody else to adopt. You already know which rung you are on. The number you do not have is the other one: what your reports' odds would be if you were on it. I wrote a book about crossing that gap: amazon.com/Builder-Leader… Read the full piece: glyf.cc/rdr-2026-07-la…