Tuesday, 13 October 2026
Kent Beck argues that the claim "AI is better at coding than humans" is nonsense: LLMs (which he calls "the genie") produce plausible code that often doesn't actually work, so programmers and buyers now need an adversarial posture toward AI-generated software. His central model is a tradeoff between features (visible progress) and futures (optionality to change), and he says the real skill is pausing between features to restore optionality rather than racing to the zero-option mess that AI now lets you reach in a week instead of a decade. He dismisses spec-driven development as rebranded waterfall, explains why formal methods still leave a gap, and closes by warning that lines of code and PR counts measure effort and output, never mission.
- Beck calls the claim that AI is better at coding than humans "boulderdash": the genie produces syntactically correct, plausible programs that frequently don't work, citing the $10,000-in-tokens "C compiler" that can't actually compile hello world.
- Trustworthiness you used to be able to infer from code — built-by-construction correctness, whole classes of bugs being impossible — can no longer be assumed, so you must take a cynical, adversarial stance toward AI output.
- The craft activities Beck wrote three books about (naming, decomposition, structuring for human readability) have lost much of their leverage, though readable systems are still preferable because the genie can explain code faster.
- His core model: every project trades futures (options for change) for features; keep spending futures and you reach zero optionality — a state that used to take 100 people 10 years and now takes one person one week.
- The fix is alternating rhythm — implement a feature, then refactor, remove duplication, or throw the work away and redo it to rebuild futures — because "you can't wipe the knife while you're cutting."
- Spec-driven development is waterfall under a new name; Royce's original paper said on the same page that it doesn't work, and the people excited about one-shot specs "don't sound like they've ever had a billion users."
- Formal methods have two problems for Beck: they feel one-shot and discourage change, and there's still an unbridged gap between a verified specification and a running implementation.
- Measuring effort (lines of code) or output (PR count) is by definition not measuring mission, and Goodhart's law is worse than advertised — people distort the system and lose actual mission progress, not just visibility.
- The best software he's worked on came from maximizing learning and throwing off software as a side effect, illustrated by Ward Cunningham switching off the computer and the pair rebuilding an afternoon's work in 15 minutes the next morning.
The sharpest framing of the features-versus-futures model and the clearest statement of how AI accelerates the wrong thing.
It used to take us a hundred people 10 years to get to this absolute zero state where we can't make any changes without breaking something else. And now with AI, I can do this in the privacy of my own office. One person, one week, and I can make a complete mess.
Beck connects today's hottest AI workflow to a failure mode the industry already documented and forgot, including what Royce's own paper said.
There's such a temptation in spec-driven development to go down the path of I'm going to write a spec and the genie is going to produce the software and if the spec is good enough, the software is going to be good enough. And there's a word for that. That's exactly waterfall development.
I call it the genie because it grants your wishes, but it ends up not being what you really wanted.
Genie is really good at plausible, but actually working, no.
You can't wipe the knife while you're cutting.
Anything which is a measure of effort or a measure of output is per definition not a measure of mission.
This is a learning process that throws off software as a side effect.
Stop Using AI For This
Kyle Cook argues that developers are wrapping deterministic logic in English prompts and AI "skills" when they should just write a program. He uses Gary Tan's G stack skills as an example: a markdown-to-PDF skill that is essentially code and if-statements written out in prose, fed into a non-deterministic machine. His fix is to generate a CLI tool or small scripts once, let the AI call them, and isolate AI to the genuinely ambiguous step "- like transcription in his own video editor "- so one hallucination doesn't break an entire chain.
- Many AI "skills" are just programs in disguise: blocks of code plus if-statements written in English, which means deterministic logic is being run through a non-deterministic system that can hallucinate.
- A better pattern is to encapsulate that logic in a single command-line tool or several small scripts, and let the AI decide which tool to call rather than carrying out all the steps itself.
- Every invocation of a long skill costs tokens twice "- the AI must read all the text and then think and output "- whereas writing the code once and calling it is effectively free thereafter.
- Cook frames this as caching: we cache generated HTML to avoid regenerating it per request, yet we've forgotten the same principle with AI and burn tokens re-deriving the same result.
- In his own video editor, AI only produces a transcript written to a JSON file; the JavaScript program reads it, lets him edit, and calls FFmpeg with no AI involved.
- Chaining AI through multiple steps means a single mistake anywhere breaks the output and forces a rerun from the start; isolating the AI step means you only rerun that step.
- Using AI to write the deterministic code is encouraged "- what's wasteful is using English instructions to make AI perform the deterministic task itself.
- He acknowledges agents are the right call when the task is genuinely ambiguous, but not for spelled-out procedures like git commit and push.
This is the core argument, delivered with the concrete PDF-skill example in front of him, plus the proposed fix of a single CLI tool.
It sounds like a program to me. It sounds like code. It sounds like something that should run deterministically the exact same way every single time. And instead... we're feeding it into a non-deterministic machine that can sometimes hallucinate.
A sharp reframing that turns an abstract complaint about tokens into a familiar engineering principle.
We have learned that caching is an incredibly important thing to do as you want to scale out your application... We've essentially completely forgotten that when it comes to AI.
Do you know what that sounds like? It sounds like a program to me.
Instead of creating a program which does what we want us to do, the caching portion, we're instead forcing the AI to burn tokens and energy and power every time we want to do something.
I guarantee you at some point along that chain it's going to make a single mistake and if it does, everything in that chain is essentially broken.
Rob compares three popular Claude/agent skill packs: Addy Osmani's newly open-sourced set (25 skills plus four reviewer personas, built around a six-stage define/plan/build/verify/review/ship lifecycle), Matt Pocock's small composable skills focused on upfront alignment, and Lauren Tan's PStack focused on verification and evidence. His conclusion: Osmani's pack is the most team- and enterprise-friendly because it follows the conventional SDLC with no new metaphors to learn, Pocock's is best for fuzzy design problems, and PStack is best for gnarly bugs, migrations and long autonomous runs. The bigger argument is that you shouldn't install everything everywhere — ceremony should match the stakes, and extra skills bloat context and auto-trigger when you don't want them.
- Addy Osmani (ex-Google Chrome DX/web performance, now at Anthropic) open-sourced his agent skills and the repo hit roughly 100,000 stars, making it one of the most popular AI repos on GitHub.
- His pack is structured as a six-stage lifecycle — define, plan, build, verify, review, ship — each with a slash command, deliberately mapping to the standard software development lifecycle rather than inventing new vocabulary like Pocock's 'grilling'/'fog of war' or PStack's 'potato mode'/'arenas'.
- Notable commands include /build auto (approve the plan once, then every task runs autonomously but stays test-driven, self-committing, and halts on failure), /constraints (interviews you about your quality bar and writes constraints.md), /web-perf, and /code-simplify.
- Every skill contains an 'anti-rationalization table' listing the excuses an agent makes to skip steps ('this is too simple to test', 'I tested it manually') paired with the rebuttal.
- 'Doubt-driven development' spins up a fresh context whose only job is to doubt a non-trivial claim — adversarial review during the build rather than only at the end.
- The skills encode classic engineering principles: Hyrum's law for API design, the Beyoncé rule for testing, Chesterton's fence for simplification, trunk-based development, small atomic commits.
- Positioning: Pocock asks 'do we agree on what we're building', PStack asks 'can you prove it works' (no planning skills; 'the best spec is the code'), Osmani asks 'did we follow the process' — and he's the only one covering CI/CD, observability and deprecation, installable into ~70 agents.
- Rob's practical advice: prune your agents.md and skill files because models are already strong, match effort to stakes (just change the button vs. full security review for irreversible production work), and treat these packs like textbooks to steal from rather than religions to adopt wholesale.
The single most transferable idea in the pack — pre-writing an agent's excuses alongside rebuttals — and it's trivially copyable into anyone's own skills.
Every skill has what Addy would call an anti-rationalization table. It's a list of the excuses an agent will make to skip past a step... 'this is too simple to test' or 'I tested it manually.' If you've worked with agents or you've worked with juniors, you've heard all of these excuses before.
This is the video's actual thesis — a concrete tiered model for when to use heavy process versus just shipping, backed by Osmani's own gradual-rollout advice.
If you're just changing a button color, you don't need a PRD, a task breakdown, a five-axis arena review from PStack, or a security auditor. You just need to change the button and look at it.
Honestly, if you never install this, just reading through the skills is a better software engineering course than most.
It's not that they're actually borrowing from each other, it's just that software engineers converge on how to build software.
More skills doesn't necessarily mean a smarter agent.
Don't treat any of these packs as a religion. Treat them like an O'Reilly textbook — steal what works and build your own skills on top.
Anthropic shipped "mods" for Claude Code (released Oct 1), small add-ons that change how Claude Code itself looks and works by listening to events and watching, modifying, or handling them. The video walks through nine mods worth trying — Savvy Progress, Claude Skins, You Should Know, File Tree, Cache Tax, Blast Radius, Reflect, Terminal Browser and Replay Theater — and explains how mods differ from skills and MCP connectors. Building one is just a matter of describing it to Claude, which has a built-in "plugin authoring" skill; mods are temporary by default until you ask Claude to save them as an installed plugin.
- Mods differ from skills and connectors: a skill tells Claude how to do a job and a connector plugs Claude into another app, while a mod runs inside Claude Code and changes the interface itself — extra buttons, side panels, even a minigame.
- Mods work in the Claude Code terminal and the desktop app's code tab, but were not yet available in the VS Code extension at recording time; you need version 2.1.287 or newer.
- Technically, Claude Code emits an "event" whenever it does something, and a mod is code that listens for those events and can watch, change, or handle them — Savvy Progress uses all three to draw a progress bar and a live sub-agent panel showing model, progress and API cost.
- Cache Tax targets wasted spend: the prompt cache goes cold after roughly an hour on a normal subscription, forcing Claude to reread the whole conversation, so the mod estimates that cost before you send and offers a /keepwarm command that pings the session before the cache expires.
- Blast Radius, built by Anthropic, intercepts risky commands like deleting a folder, lists exactly which files would be removed and requires a human to press proceed — a response to real cases where frontier models wiped entire projects.
- Reflect acts like micro-scale RLHF: when you type feedback with trigger words like "no" or "I wish we'd done it this way," a banner offers to save that correction as a permanent rule in your CLAUDE.md or skill file.
- Most mods run on deterministic code and cost no extra tokens, but ones like "You Should Know" run a second agent in the background and draw on your normal Claude usage.
- Several mods are useful outside coding — File Tree can track which tax documents Claude opened and changed, and Replay Theater can step through edits Claude made to an article draft.
It's the clearest explanation of the underlying mechanism, which makes every other mod in the list make sense.
Every time Claude does something like running a command, Claude Code actually sends out a little signal called an event. And a mod is just a small piece of code that listens for those events so that when one comes through, the mod can do one of three things. It can watch that event, it can change it, or it can handle it itself.
A concrete, money-saving explanation of prompt caching plus the /keepwarm trick that most users won't know about.
After a while, usually about an hour on a normal Claude subscription, it goes cold. And once that prompt cache is cold, the next prompt that you send actually makes Claude reread your entire conversation, which can really eat into your usage limits.
If you can describe a feature that you wish Claude Code had, it can now build that feature into itself.
You might not think that your agent would ever delete your files, but I've seen so many edge cases already where even a smart frontier model would wipe out someone's entire project.
A mod that Claude builds for you is temporary by default. So when you find one that you like, ask Claude to save it as a plugin and install it.
The creator uses an anecdote from Bill Bryson's A Short History of Nearly Everything — about an amateur astronomer who hunts supernovas by eye rather than by computer — as an analogy for developers who still write code by hand in the AI era. His point: AI is a tool that can be used in different doses, and if you genuinely enjoy writing code, there's no obligation to hand it over to Copilot. He also notes the astronomer's line that he 'still beats them sometimes,' suggesting manual work occasionally catches what automation misses.
- The framing comes from Bill Bryson's A Short History of Nearly Everything, specifically a passage about a man who scans the night sky for supernovas using a telescope, his eyes, and memory instead of a computer.
- Asked why he doesn't automate, the astronomer says he enjoys doing things manually too much — a line the creator sees mirrored in developers' attitudes toward AI.
- AI can now write code, organize ideas, and build whole features, and some developers have shifted into a manager role overseeing tools like Copilot.
- The creator doesn't criticize that choice ('good for them'), but argues it isn't the only valid path.
- His central claim is that AI, like any tool, can be used in different doses rather than all-or-nothing.
- The astronomer's remark that he 'still beats them sometimes' is offered as evidence that manual work can still catch things automated systems miss.
- The video closes as reassurance to developers who code by hand that they aren't alone, framing AI as something trying to take away a hobby people enjoy.
The core analogy of the whole video, delivered in one clean stretch.
He looks through a telescope, scans the sky with his own eyes, and relies on memory. And when something changes, he notices... 'Oh, no. I enjoy doing things manually too much.'
States the actual argument and pairs it with the punchline that manual work sometimes outperforms the machine.
AI, like all tools, can be used in different doses... And there is one more thing the man in the book says that really matters: I still beat them sometimes.
Oh, no. I enjoy doing things manually too much.
AI, like all tools, can be used in different doses.
I still beat them sometimes.
The big lie about AI coding
A rant against what the host calls the "Markdown Industrial Complex" influencers packaging prompt files, "skills," and agent stacks as proprietary AI-coding methodology. His claim: there is no special skill in AI coding beyond picking a reasonable effort level and putting in long hours, and the people shipping huge volumes of PRs are just working 10-12 hour days. He argues the tricks people distribute are usually AI-generated themselves, address problems newer models already solved, and that real capability gains come from labs post-training the models, not from your prompt folder.
- The trend started with a widely-starred repo of Markdown files (referred to as "G stack," credited to Y Combinator's Gary Tan) that instruct an AI to act like a software engineer, CEO, etc. now imitated by many others, including Matt Pocock's "skills."
- The influencer who claimed 2,500 PRs shipped to production in a month did it by working 10-12 hours a day, not by using a secret workflow; the host says that volume is normal for full-time agent use.
- He cites Dax (opencode) on the core inversion: models improve faster than tinkerers, so elaborate custom setups usually solve problems that no longer exist, and someone naively using vanilla Codex is more likely to be on the state of the art.
- Token-saving "prompt of the day" optimizations may shave a tool call but won't change the big-O of your work and often waste tokens.
- He defends DHH for saying two frontier agents know Elixir better than he does, calling that an honest admission rather than an abdication of responsibility.
- Skills files are often generated by asking the model to write up whatever it just did and then redistributed "rain dances and superstition wrapped in a Markdown file"; the changelog prose itself reads as AI-written.
- What actually teaches agents to work like real engineers is lab post-training, not a skill file; a weak model won't be transformed by one.
- Beginners bookmark these repos assuming hidden utility, which inflates star counts and feeds the cycle his advice is to stop bookmarking and just prompt more and work harder.
This is the argumentative core of the video the clearest reason elaborate agent setups go stale, plus the meme contrast between stacked markdown files and professionals just opening a chat window.
A weird inversion with LLMs is the models improve faster than the tinkerers. When I see people with custom workflows and setups, they're all addressing problems that don't exist anymore. The person naively using vanilla codex is more likely to be experiencing state-of-the-art.
Defends DHH's "two frontier agents know Elixir better than me" position and then states the video's thesis in one line, including how skill files actually get made.
The only real skill in AI coding is knowing which effort level to use. Everything else is influencer propaganda... It's just rain dances and superstition wrapped in a markdown file.
Let me tell you how Lauren shipped 2,500 PRs to production. She worked 10 to 12 hours a day. That's it.
Anytime you get impressed that an agent did something, it's not because you prompted it in a special way. It's because the agents are just impressive now.
The thing that teaches agents how to work like real software engineers is the labs doing post-training on the models.
Fireship recaps a chaotic week in the open-weight model race: Mistral released Mistral Large 4, a trillion-parameter mixture-of-experts model with a million-token context window, one day after US startup Reflection AI finally shipped Beam, a 501B-parameter model trained on $6.3 billion worth of GPUs that Mistral promptly out-benchmarked. Meanwhile Moonshot AI closed a round at a $50 billion valuation while its Kimi K3 model already does what both Western labs are chasing. The underlying argument: privacy, surveillance, and sovereignty are why every government wants an open model of its own.
- Mistral Large 4 is a mixture-of-experts model with roughly a trillion parameters but only ~49 billion active per token, giving trillion-parameter knowledge at roughly the cost of a model 20x smaller — the same trick DeepSeek used.
- Reflection AI, backed by Nvidia and raising $4.6 billion on the premise that the best open model should come from the West, shipped Beam: 501B parameters, base model trained in under 4 weeks on ~24 trillion tokens, plus 4 weeks of post-training for code, tools, and long agent tasks.
- Beam benchmarked itself against an already-outdated Chinese model and was out-benchmarked by Mistral within 24 hours; it still requires an invite and the weights aren't released.
- Mistral's reported numbers are self-provided, the model isn't finished training, and weights arrive later this month under a custom license — so the claims are provisional.
- Because Beam's weights aren't out, the best open American model is arguably still Google's Gemma 4, released under Apache 2.0 in April.
- The privacy case for open weights: proprietary prompts go to a data center, get scanned by classifiers, potentially read by safety teams, and used for training — with examples of users facing police attention after chats with Claude.
- Governments face the same problem at scale: analyzing something like a national power grid with a foreign proprietary model means handing over private schematics, which is why countries want models they own or can trust.
- Kimi K3, Moonshot's 2.8 trillion-parameter open model from July, was popular enough to exhaust their GPUs; Microsoft, Amazon, and Google have all been negotiating to host it, and Moonshot went from a $4B to a $50B valuation with China's state AI fund involved.
It's the clearest statement of the actual stakes behind the open-model race, moving from individual privacy to national infrastructure security.
Even if you're not planning on committing a felony with proprietary models, you're still sending every prompt to a data center, which is scanned by a classifier, but potentially read by a safety team, and then used in whatever way the lab wants.
A compact explanation of mixture-of-experts economics immediately followed by a sharp caveat that Mistral's benchmarks are self-reported on an unfinished model.
You get a trillion parameters worth of knowledge for roughly the cost of running a model 20 times smaller, which if that sounds familiar, it's probably because it's the same trick DeepSeek used last year to tank Nvidia.
It was trained on 6.3 billion dollars worth of GPUs. It benchmarked itself against an already outdated Chinese model. And 24 hours later, it got out-benchmarked itself by Mistral.
The catch is the numbers really are, trust me, bros, because they were provided by Mistral and they actually haven't finished training yet.
If all you've got is a gaming PC, go with Gemma 4 and get your money up.
Turbopuffer, the vector search vendor behind Cursor, Notion, and Anthropic, is demoting the vector index in its v3 engine from the center of the system to just one index among keyword search and filters. The video walks through the three alternatives competing for that center slot s agentic search loops, live MCP connectors, and pre-compiled knowledge files s with benchmark numbers and costs for each. The conclusion: vector DBs aren't dead, just demoted, and for most new builds the default should be an agent with cheap search tools, keyword search first.
- Turbopuffer's v3 gives every document a plain ID and makes the vector index one index among many, instead of storing documents at the address of their vector; v3 isn't in production yet, so it's partly marketing from a company running search over 10 billion Notion documents.
- On Google's FRAMES benchmark (824 questions, 12,000 Wikipedia articles), Pipeshub's agentic search scored 92.7% versus 78.9% for the best of 18 fixed RAG pipelines, and only a third of a point below being handed the exact right articles.
- The agent loop costs about 3x more per question, the slowest answer took 134 seconds versus 54 for the pipeline, and 7% of questions consumed 37% of the budget; an independent LREC study found 3x input tokens, 50% more time, and a plain reranker beating the agent at ranking.
- On Enterprise RAGBench (half a million documents from Slack, Gmail, Jira, Confluence, GitHub), BM25 keyword search answered 68.8% correctly versus 51.4% for vector search, because embedding models trained on public text don't know internal code names, acronyms, and ticket numbers.
- Vectors still win in places: GPT-5 as a search agent scored 70.1% on BrowseComp Plus with an embedding retriever versus 55.9% with BM25, and Cursor reports 12.5% better accuracy adding semantic search on top of grep.
- MCP connectors skip the index and query apps live; Microsoft's federated Copilot connectors index nothing, Anthropic's Claude marketplace opened September 23rd with 2,000+ connectors, and OpenAI now restricts app syncing to admins while Slack bans bulk exports.
- Live access is slow and expensive: Glean measured Claude co-work on live connectors at $2.98 per task against $0.58 for Glean's index with more than 3x the tokens s though Glean also added 182 live MCP server templates on September 22nd.
- The compiled-knowledge approach (Google's Open Knowledge Format) lost its own test: an August study found the wiki spent about 21x more tokens per query, so no break-even point exists, though it cited far better (40% of claims held up versus 19% for RAG); the OKF repo's last commit was August 21st.
The clearest cost-versus-accuracy tradeoff in the video, with the specific benchmark numbers that justify choosing an agent loop or not.
The agent got 92.7% right. The best of 18 fixed pipelines got 78.9... The agent costs about three times as much per question. The slowest answer in 20 took 134 seconds against 54 for the pipeline and 7% of the questions ate 37% of the budget.
A counterintuitive result with a memorable one-line explanation of why embeddings fail on internal enterprise documents.
BM25 answered 68.8% correctly, and vector search got 51.4. Vectors even lost on the questions written to favor them because embedding models trained on public text don't know your code names, acronyms, and ticket numbers... Customer IDs need equality, not a soulmate.
Customer IDs need equality, not a soulmate.
The loop wins the hard questions, but you pay for every lap.
Before you pay for another vector index, give your agent a keyword search tool.
Dexter Horthy (CEO of Human Layer) argues that although coding agents got much better at solving problems in 2026, they did not get better at keeping codebases maintainable, so the "lights-off" software factory where nobody reads the code doesn't work yet. He backs this with SlopCodeBench, a University of Wisconsin benchmark that reveals models' code degrades as features accumulate (GPT-5.5 scored 14.8%), plus industry data showing code review quality down and incidents/bugs per PR up. He then lays out ~9 practices for an agentic "software factory" — plan before building, align visually, give agents back pressure, feed user feedback and pager alerts straight into PRs — and sketches the buy-or-build layers (compute, dev environment, harness, control plane) that Human Layer is targeting.
- A report cited from May showed that since teams adopted Opus 4.5, code review quality dropped, PRs increasingly skip review, and incidents and bugs per developer rose — which Horthy says is a tooling problem, not a skill issue.
- The software factory concept dates to 1968; the agentic version swaps the human builder for an agent, which compresses build time to minutes while review still takes hours or days, making review the new bottleneck.
- Core thesis: unattended models will not maintain or improve codebase quality over time, because telling a model what to fix requires understanding the codebase — which means it isn't unattended.
- Maintainability has no fast oracle, so reinforcement learning can't reward it; benchmarks reward passing tests, not good architecture, and the cost of bad architecture only shows up months later.
- SlopCodeBench discloses a problem in pieces and makes the model add features incrementally, mirroring real development; GPT-5.5 scored 14.8% on it while saturating other coding benchmarks near 95%.
- Steve Yegge, who spent a year telling people that reading code would leave them behind, now warns that unattended models write slop so complex they can't debug it themselves.
- Practical recommendations include planning proportional to expected pain, the open-source "show me" skill for visual alignment, giving agents browsers/curl to test their own work, Dylan Mulroy's ~100 TypeScript anti-slop rules, and attaching a candidate fix PR to every 3 a.m. page.
- Horthy frames "loops" as just forward pressure (what triggers new work) plus back pressure (feedback the agent can hill-climb on without a human), and proposes a centralized system of record for sessions, plans, and prompts.
A concrete, unsaturated benchmark result that directly contradicts the "coding is solved" narrative from terminal-bench style scores.
Instead of telling the model the whole problem to solve up front, it gives the model the challenges... in bits and makes it write the code and then do another feature and then do another feature, which maps much more closely to how everyone in this room builds software... GPT-5.5 was the best model on the market. It got a 14.8%.
A sharp reversal from one of the loudest voices for unattended coding, paired with the numbers showing maintainability gains are only a point or so per model generation.
Not only did he build Gas Town, he went around the internet telling people for a year that if you're still trying to read the code, you are going to fall behind... and here he is last week: if you don't pay attention to the models, they're going to write slop code. They're going to build something so complex that they themselves can't debug it.
Unattended models will not improve or maintain your code base quality over time.
Maintainability has no fast oracle. We don't find out that the code was ugly until two months later when someone is paged at 3:00 in the morning.
You would say, the code is slop, but that'll be GPT-7's problem. Folks, we're at GPT-6, and I don't think we've gotten that much better at this.
i use AI wrong (and you should too)
Lars Faye explains why he deliberately rejects the "AI-native, agents-first" workflow and instead treats models as a delegation layer rather than an abstraction layer: he states the intent, the model handles the how, and he still reads and owns the code. He delegates along four buckets — rote work, refactors, research, and reinforcement (self-taught tutorials) — and demos each with Zed as his editor and OpenCode's cheap open-weight models (GLM, Kimi, MiMo) on a $10/month plan. Examples include pulling formulas out of an Excel spreadsheet into PHP, swapping a browser alert for a custom modal in a years-old codebase, and using a model as an interactive Laravel tutor. His closing point: code generation solved the typing problem, not the thinking problem.
- He frames AI models as a delegation layer, not an abstraction layer — with abstraction you start with the how and get a result; with delegation you start with intent and the model figures out the how, like handing work to another developer.
- His delegation criteria are four buckets: rote work, refactors, research, and reinforcement (learning/tutorials).
- He moved from Cursor to Zed because Cursor swapped heavily toward an agent-first interface; he still wants to see directories, files, and code, with agent chat available on the side.
- The most valuable use of these models to him isn't code generation but "interactive documentation" — conversing with your own codebase and learning from it, like a dynamic tutorial generator.
- He uses OpenCode's $10/month Go plan with open-weight models (GLM, Kimi, MiMo), says they handle everything he throws at them because his requests are isolated and surgical, and calls open-weight models badly slept on.
- Demo 1: MiMo 2.5 Pro extracted solar-calculator formulas from an Excel sheet into PHP functions, kept the original calculations as comments, and wrote verification scripts against the spreadsheet values — but put them in the wrong file because he wasn't explicit enough.
- Demo 2: replacing a browser alert with his existing custom modal component in his years-old Wallaby platform; he gave the model the file locations up front to reduce wandering and burned tokens, then hand-tweaked the copy and Tailwind classes himself rather than re-prompting.
- Demo 3: he had a model generate a structured Laravel crash course that quizzes him and tells him where to write code, warning that you are both tutor and student, so "what you ask for, you will certainly receive."
- His conclusion: code generation solved the typing problem that snippets, autocomplete, and frameworks have chipped at for decades, but logic, creativity, strategy, and critical thinking are all still required.
This is the conceptual spine of the whole video and the clearest articulation of his alternative to agents-first workflows.
I do not feel that these models are an abstraction layer. I think that they are a delegation layer. With an abstraction layer, you begin with the how and you end up with your intended result. With a delegation layer, you start with your intent and the model handles the how.
A counterintuitive take that reframes what these tools are actually for, and it sets up his Laravel tutoring example later.
Ironically, it's the code generation aspect of these models that is not even the most useful and impressive to me, but it's this almost interactive documentation nature of them and the ability to converse with your code that I find to be by far the most transformative and useful aspect.
I'm not trying to get away from looking at code. I'm not trying to get out from under just writing code.
You are both the tutor and the student at the same time. You are generating your own lesson plan. So what you ask for, you will certainly receive.
Code generation has certainly solved the typing problem... The part that required all the logic, creativity, strategy, problem-solving, critical thinking, all of that is still there just with less typing.
Mario Zechner and Armin Ronacher talk through Pi Durable, a new release of the Pi agent harness that lets an agent survive a process crash and pick up exactly where it left off. Mario explains the design in detail: instead of event sourcing, everything in the harness is an "effect sandwich" (record intent → run the effect, ideally idempotently → persist the result), paired with a small versioned document store for application state that can be rewound alongside the conversation. The rest of the conversation covers where coding models have genuinely gotten better (anything with an oracle: tests, fuzzing, emulators, reverse engineering) versus where they haven't (architecture, because the act of designing software was never written down to train on), plus Earendil's plans to build non-coding-agent products and the unsolved security problems of extensible web UIs for agents.
- Pi Durable's core promise: if the process dies, you restart it and the agent continues from exactly where it stopped, with no lost tool results or streamed output and no need to type "continue" — essential for long-running agents like Slack bots that live for years.
- It also removes Pi's old limitation of loading the entire conversation tree into memory, which breaks down once an agent accumulates years of history.
- The architecture deliberately avoids event sourcing. Every operation is a task shaped as an "effect sandwich": persist the intent and inputs, execute the effect (using idempotency keys when the external system supports them, as with GitHub Actions), then persist the result. Tasks can spawn and await other tasks, and that nesting is the whole mechanism.
- Application state lives in a small custom document store where documents are versioned against positions in the transcript, so rewinding the conversation can either restore the old version of a to-do list or drawing, or keep the latest — you choose per document. They rejected JSON Patch as too generic and use a JavaScript proxy to record mutations.
- Both agree models have improved dramatically wherever an oracle exists — test suites, fuzzing, emulator ports, reverse engineering — but not at architecture. Mario's explanation: cyber, front-end and reimplementation tasks all have abundant training data, while the process of designing and architecting software is almost never written down anywhere.
- Mario describes a model reverse-engineering the native memory structures inside a JVM to read bytecode out of process memory, bypassing protections he believed no human reverser would have broken; Armin similarly had a model crack a Chinese CarPlay dongle's firmware protection unaided.
- Pi Durable is roughly 12,000 lines and deploys to Vercel, Cloudflare Durable Objects, E2B, a laptop or a phone. Mario has already built "PIM", a phone-first Pi that runs everything locally except the LLM and can use remote machines as execution environments.
- Earendil's stated direction is products that are not coding agents, plus infrastructure others can build agents on; the hardest open problems they name are multiplayer/shared sessions, secure extensible web plugin UIs (XSS and cookie exfiltration, iframes ruining UX), and onboarding non-engineers who don't yet have the instinct to just ask the model.
The clearest, most compact statement of what Pi Durable actually does and why long-running agents need it.
Agent starts up in a process, agent calls tools, process dies. What you want is restart the process, agent continues exactly from where it left off. That is durability.
A concrete, falsifiable explanation for the one capability gap both builders keep running into, framed as a data problem rather than a model problem.
What I don't have training data for is the process of building, of designing and architecting something. That is the only part in programming that is actually not usually encoded somewhere in textual form so an LLM can learn from it. And that's why we are stuck here.
If you have an oracle that can tell the LLM if what it did is correct or not, then you basically won.
It will definitely solve the problem, but it's almost impossible that it will fix a problem without adding code.
Everybody gives you a chat box and a sidebar and then good luck motherfucker, figure it out.
REA ("reverse engineer anything") is a fast-rising GitHub repo — roughly 7–8k stars in a day — that packages an MCP server and CLI around existing reverse-engineering tools like Ghidra, Hopper and IDA Pro so a coding agent (Claude Code, Cursor, Codex) can investigate compiled binaries it has no source for. It doesn't recover original source code; it returns pseudo code, assembly, module maps, call paths and network activity with confidence levels and evidence. Rob demos it on a deliberately stripped and optimized "vault" app he built, and the agent finds the unlock logic among 242+ unnamed functions and writes a working code generator. His conclusion: reverse engineering was always possible, REA just removes the friction that acted as de facto protection, so code was never really the moat.
- REA is an MCP server plus CLI wrapper around established reverse-engineering tools (Ghidra from the NSA, Hopper, IDA Pro), exposing dozens of plain-language "intent" tools like open this binary, find the strings, follow the function callers.
- It works on native binaries for Mac, Windows and Linux, plus .NET, Android APKs, firmware, websites and smart contract bytecode — not just Electron apps.
- It does not return original source code; compilation destroys that. Output is pseudo code, assembly, module maps, call paths and network activity, each finding tagged with its source, the model's confidence, and what it couldn't determine.
- In the live test Rob compiled his own "vault" app with function names stripped; the agent loaded 242+ anonymous functions, decompiled, located the unlock check within a handful of calls, and wrote a generator that produced a valid code (AGNT-1001).
- The agent didn't copy code — it understood the logic and wrote something new that the original app didn't even contain.
- Security warnings: this isn't a sandbox, runtime capture runs with your permissions, binaries may carry prompt-injection payloads, and you should keep agent approval prompts on and run things in a sandbox.
- Legal caveats: reverse engineering for interoperability has generally been protected, but many terms of service ban it outright and breaking DRM or encryption is a separate legal problem; your own apps, open-source binaries and authorized tests are safe ground.
- Rob's framing is that this is a correction rather than a disaster — the real moat is data, users, cloud security, shipping speed, taste and server-side logic, and the defensive use case (auditing what apps on your machine send home) is genuinely valuable.
- Setup is a single command, npx rea-agent-setup, which shows a change plan, backs up your config, adds the MCP server and installs a skill that teaches the agent how to investigate; the repo is moving fast with frequent breaking changes.
The only concrete demonstration in the video, and it shows the key distinction between recovering source and reconstructing logic.
It opens up the binary and it gets back 242 plus functions. Every one of them is just called fun and an address... Within a handful of calls it's actually found the one that matters... It didn't copy the code. It understood the logic and then wrote something completely new, a code generator, which my app doesn't even have.
The central argument of the video, delivered as a calm counterpoint to the panic posts circulating about the repo.
That friction of reverse engineering was the protection and REA basically deletes all that friction... Code was never really the moat in the first place. Your moat really is in your data, your users, your cloud security, how fast you ship, your taste, and the stuff that runs on your servers.
It doesn't just hand you the original source code. Nothing can do that. When an app is compiled, the original code is gone.
That friction of reverse engineering was the protection and REA basically deletes all that friction.
If you ship a desktop app, a browser extension, a game, a mobile app, or a big client-side JavaScript bundle, you should now assume that anyone's agent can map out how it works.
Docker Agent is an open-source Docker tool that lets you define an AI agent in a YAML file — model, instructions, tools — and run it with a single command, with Docker handling the agent loop (call model, run tools, feed results back). The video walks through a minimal agent, then a two-agent incident-debugging setup where one agent holds the logs and another queries it over the A2A protocol, and finishes with three agents playing a full battleship match. The pitch is that agents become versionable config you can push to a registry and expose as HTTP, MCP, or A2A services instead of hand-written Python boilerplate.
- Docker Agent is positioned as 'docker run for AI agents': a YAML file specifies the model, description, instructions, and allowed tools, and `docker agent run agent.yaml` starts a terminal UI you can chat with.
- The model line can point at OpenAI, Anthropic, Gemini, OpenRouter, or a local model via Docker Model Runner, so swapping models is a one-line change.
- Tools come from a toolsets section covering built-ins like file access and shell commands plus any MCP server; agents can also have sub-agents so a coordinator hands work to specialists.
- Three claimed advantages: agents as versionable configuration reviewable in pull requests, distribution by pushing to Docker Hub or any OCI registry, and running an agent as an HTTP API, MCP server, or A2A server with one command.
- The on-call demo shows a security benefit: a log analyst agent has read-only file access scoped to the logs folder, while the on-call assistant has no file access and only knows the analyst's URL, so other teams can ask questions without getting the logs.
- In the demo the analyst is served with `docker agent serve a2a` on port 8080; the on-call agent asks why checkout is throwing 500s since 2 p.m., and the analyst reads app logs and deploy history and returns findings that become an incident summary.
- The battleship setup uses three agents — two players on ports 8080 and 8081 and a separate referee running a different model so neither player judges its own game — with the board on a local server.
- Claude Haiku beat the other model in 34 shots at 50% accuracy with both sides down to their last ship; the presenter explicitly says this is a game, not a benchmark, though both played better than random.
- Docker Agent ships by default with Docker Desktop 4.63 or newer, or can be installed via Homebrew and symlinked into the Docker CLI plugins folder.
This is the core argument for the tool — config, registry distribution, and one-command services — compressed into 40 seconds.
The first is that agents become configuration. You can version them, review them in pull requests, and swap the model by just changing one line. The second is distribution... And third is that agents can run as services.
The clearest practical payoff in the video: agent-to-agent delegation as an access-control boundary between teams.
The first one is a log analyst and it's the only agent that can read the logs... The second one is an on-call assistant and it has no file access at all. The only thing it knows is the analyst's URL.
Docker describes it as being to AI agents what docker run is for containers.
In a real company, the platform team would own the log analyst and run it next to the logs. Any other team's agent could ask it questions without ever getting access to the logs themselves.
This is just a simple game, so I wouldn't call it a benchmark, but both models clearly played better than random.
OpenAI dumped 372 claimed math results on GitHub, many machine-verifiable in Lean but unexplained even by OpenAI's own mathematicians, while the company declined to publish the prompts its own advisory group asked for. The video ties that missing-receipts pattern to the AI debt market, where lenders are demanding to see books and OpenAI's annualized revenue just came in near $50 billion rather than the widely repeated $70 billion. It then covers an AI-assisted attack on at least nine South Korean banks by one person using an open-source tool, and proposes a three-layer accountability system modeled on anti-money-laundering rules.
- On 6 October OpenAI published 372 mathematical results on GitHub, including claimed progress on the Riemann hypothesis, most allegedly from a single prompt to a single agent — a month after a Navier-Stokes result that reportedly needed 10,000 agents and millions in compute, which the host finds suspicious.
- Many results came with Lean proof files, so correctness can be machine-checked (Scientific American called many 'all but certain to be correct'), but OpenAI admits its own mathematicians don't yet understand many of them.
- OpenAI's independent mathematician advisory group asked for the model, exact prompt and compute time with every result; OpenAI published average compute time but no prompts and said it is not bound by the group's recommendations.
- Thomas Bloom froze comments on the Erdős Problems site and removed solved/open labels after it filled with unexplained AI-generated proofs; the host still argues the knowledge is worth having even at cost to mathematicians, using aspirin (worked for 70 years before anyone knew why) as the analogy for 'knowing that' vs 'knowing why'.
- The AI debt market is straining: a $60bn package for Anthropic chip leasing was split into a $42bn senior tranche backed by Broadcom's residual value support and an $18bn junior tranche with no backstop, and banks may wait for an Anthropic IPO before lending; Morgan Stanley estimates $1.5 trillion of outside money needed by 2028.
- The Financial Times reported OpenAI's annualized revenue is close to $50bn, not the $70bn figure circulated for weeks and never denied — a $20bn gap partly explained by accounting differences over cloud-resold sales.
- At least nine South Korean banks were hit using RTX, an open-source attack harness published on GitHub that plugs into Claude, ChatGPT and DeepSeek; Shinhan reported ~25,000 customers' data compromised and KB Kookmin took about 68 hours to detect the breach.
- CrowdStrike traced the suspect to a 26-year-old in southern China by analyzing his AI sessions — he had asked Claude where to sell stolen Korean data and to write him a CV containing his age, Telegram account, education and hometown.
- The proposed fix has three layers: model companies must detect and report misuse like banks report suspicious transactions; agents should carry a user-level 'passport' on top of Web Bot Auth's company stamp, with thresholds akin to the $10,000 cash reporting rule; and institutions must defend themselves and treat unsigned agent traffic like spam.
Crisply separates machine-verifiable correctness from human understanding, which is the thesis of the whole video.
Open AI told Scientific American that many of the new results are not yet understood by its own mathematicians. The company that handed in the answers cannot really explain them yet. This is basically every math teacher's nightmare. Full marks, no working show.
A concrete, freshly reported number that undercuts the demand story the entire AI debt build-out is borrowing against.
OpenAI's annualized revenue, which is the single number investors used to judge demand for AI, is close to $50 billion. Not the $70 billion that was widely reported just a few weeks ago... When the receipts finally showed up, it was $20 billion or less.
Full marks, no working show.
The most popular scoreboard in AI maths is now a scoreboard with no scores on it.
If someone breaks into your house to check the answer to a crossword puzzle, touches nothing and leaves, you're technically relieved, but you're also going to change the locks because now you know the locks don't work.
In math, you show your working and somebody else checks it. In finance, you open the books before anyone lends you a penny. Right now, AI hands over the answers and skips the receipts.
A developer named Brandon Thomas rebuilt seven Adobe Creative Cloud apps in Rust under the name Artcraft, open-sourced them, and made them run on Linux too. Fireship tried the Premiere clone (FilmCraft) to edit this very video and found it laggy and visually inferior, but says the real story is a separate viral tool, Reverse Engineer Anything (REA), which wraps Ghidra and AI agents to decompile stripped binaries, JVM bytecode, .NET assemblies, firmware, and container layers into readable pseudocode. The practical workflow is: decompile the one feature you want, hand the garbage pseudocode to a coding agent, and have it reimplement the feature in Rust so you can build a stripped-down clone of any paid app.
- Brandon Thomas, after being hit with Adobe's cancellation fee more than once, used AI coding tools to reverse engineer Adobe's 30-plus-year codebase and ship seven Rust rewrites as the open source Artcraft project, including Linux builds Adobe never officially supported.
- Actually using the Premiere clone (FilmCraft) exposed the limits: audio bar lag and general slowness after dropping a single clip on the timeline, and transitions visibly worse than Premiere's side by side, despite being written in 'blazingly fast' Rust.
- The video points out that an open source alternative to Premiere already existed for decades in DaVinci Resolve, undercutting the novelty of the Adobe clones.
- Reverse Engineer Anything can decompile stripped ELF/PE/Mach-O executables, obfuscated JVM bytecode, .NET assemblies, bare-metal firmware, and OCI container layers, which effectively makes shipped software readable whether or not the vendor wants it.
- Setup is trivial: run REA with Node.js via npx, then configure the Ghidra integration, which does read-only analysis of native EXEs and DLLs and is credited as doing the real work.
- The output is C-like pseudocode plus assembly, strings, symbols, calls, and references useless to a web developer on its own, so the actual move is to pass that output to a coding agent and have it reimplement the feature from scratch.
- The same technique applied to SaaS: REA's networking feature was used to analyze Supabase's API interactions and UI changes to build a custom, cheaper backend clone with only the needed features.
- The stated goal is 'Premiere Lite' a personal build that keeps only the handful of features you use and drops the hundreds that get in the way.
The hands-on verdict that punctures the headline claim that one developer made the Adobe suite obsolete overnight.
The cracks became visible immediately, like after dragging a clip of some lame stock video onto the timeline and hitting play, there was a massive lag in the audio bars, and just overall slowness and lagginess despite being vibe-coded in Rust, which I've been told is a blazingly fast programming language.
This is the concrete method behind the whole premise: Ghidra output as input to an AI agent to clone a single feature you actually want.
A while later, we get back a bunch of C-like pseudocode, along with assembly, strings, symbols, calls, and references... However, we can now take this garbage code and pass it off to our favorite coding agent to re-implement the exact same feature in Rust.
In layman's terms, that means virtually every app in the world is now open source, whether it wants to be or not.
The software is a nearly unusable pile of vibe-coded horseshit.
I think it's crazy that any real vibe developer in 2026 is still paying money for developer tools, when that money should be spent burning tokens.