Tuesday, 20 October 2026
Agentic Coding Scam
Earl Brandt of Kira argues the industry's latest pitch — that the real value of AI coding lies in increasingly elaborate agent "harnesses" — doesn't hold up. He walks through a recent EPFL/Apple paper where a bare-bones agent with just a file system and three tools beat sophisticated multi-agent scaffolding across every frontier model tested, with delegation and sub-agent setups actually making results worse. The second half is an interview with a developer, Marcos, who uses Brooks' "No Silver Bullet," Gall's law and Jevons paradox to argue that AI shifts where engineers work rather than eliminating them.
- Researchers at EPFL and Apple tested how much harness an agent actually needs by giving agents 24 hours on the same hardware to fetch data, build a model and test results.
- A minimal agent called Malena — just a file system and three small tools — beat four state-of-the-art harnesses with tree search and parallel workers; on GLM 5.2 it won almost two-thirds of the time while the best elaborate system stayed mostly below 50%.
- Ablation showed the single biggest contributor was giving the model a file system and a shell so it could run its own code and read its own errors; skills libraries, validation rules and search tools made no statistically significant difference, and several additions made things worse.
- Reading the agents' working notes, the complex harnesses treated a whale-identification task as a brute-force search over candidate ideas, while the simple agent built one working pipeline (turning photos into fingerprints) and iterated on it.
- Adding management functions — delegation, supervision, collaboration, plan execution — lowered performance, meaning extra tokens spent on orchestration can create negative value.
- Marcos invokes Fred Brooks' 1986 essay "No Silver Bullet": tools can shrink the friction of coding (syntax, boilerplate) but not the hard part — deciding what the system should do and handling cases like two people booking the same seat or a payment failing halfway.
- Gall's law says complex systems must grow from simple working ones, so prompting "build me an app like Uber" produces something with no structure underneath that can't be patched when it breaks.
- Jevons paradox predicts cheaper software means more software, not fewer engineers; companies cutting teams are throwing away capacity and the institutional knowledge of why systems were built a certain way.
- Brandt's framing: the people pushing the job-apocalypse narrative aren't the ones doing the work, and firms that laid off engineers are already having to buy that expertise back.
This is the paper's core result and the single empirical claim the whole argument rests on.
On the GLM 5.2 model, the bare agent Malena won almost 2/3 of the time. And the best of the elaborate systems got mostly below 50%... the one change that mattered the most was giving the model a file system and a shell.
A clean economic counterargument to the assumption that faster engineers means fewer engineers.
When something becomes cheaper to use, we don't use less of it, we use more of it... Ideas that were never worth the cost before suddenly are, because they've been reduced to a weekend of prototyping.
They're token prediction algorithms with a wrapper of code around them.
A scaffolding or a harness is a bit like training wheels on a bicycle. Sure, they're great to get you started, but ultimately those training wheels end up slowing you down.
AI didn't fire those people, the companies did.
Pstack Is Agent Overkill. Use It Anyway!
Rob Shocks walks through Pstack, a skill/playbook bundle from Lauren Tan (React core team, ex-Netflix, SpaceX, now Cursor) that packages a senior engineer's workflow into 20+ agent skills routed by a "potato mode" dispatcher. He uses it to one-shot a skill manager app called Molten Base, then breaks down the standout skills (arena, swarm, why, recall, interrogate, create/maintain verification, onslaught, brawl) and the underlying principles. Verdict: it roughly doubled build time and burns far more tokens than a plain agent run, but produced a noticeably more hardened app, so it's worth using selectively rather than on every project.
- Pstack is deliberately not a spec-and-planning framework like BMAD or OpenSpec test it's built to operate on an established codebase, because Lauren Tan's stance is "I don't believe in planning. The best spec is the code."
- "Potato mode" acts as a router that picks which of the 20+ skills and 22 playbooks to invoke for a given prompt.
- Arena runs three or four different models (Claude, GPT, Grok, Opus) against the same problem and grafts or rejects parts of each into the final commit test a feature Cursor shipped and later removed; swarm instead gives parallel workers different slices and aggregates the results.
- The "why" skill pulls decision context from connected MCPs and CLIs test PostHog product data, Slack threads, Sentry logs test to reconstruct ADRs rather than just reading the chat transcript; "recall" uses the same trick to resume a stale project.
- Verification is the backbone of the whole stack: create-verification writes scripts that prove real app behavior, maintain-verification keeps those scripts from drifting, and interrogate has multiple models review the same code against standards.
- In the demo run, the verification/audit phase caught three false claims the agent had hallucinated about its own work.
- Core principles include the laziness protocol (prefer deleting code, smallest change possible), redesigning from first principles as if a feature existed on day one, minimizing reader load, exhausting the design space, building a lever (a CLI or script) for anything repeated, and guarding the central context window by offloading to sub-agents.
- Benchmark: the same project took ~30 minutes with a plain model run and no skills versus ~1 hour with Pstack, at substantially higher token cost test the presenter says skip it for small design changes or front-end UI tweaks.
It's the clearest statement of the philosophy that separates Pstack from spec-driven frameworks, immediately followed by the arena skill pitting four models against one design problem.
Lauren's personal take on this is I don't believe in planning. The best spec is the code. So there's deliberately no planning skill baked into Pstack.
A concrete result showing the verification machinery actually catching the agent lying about its own work, plus the point that detailed up-front plans break on contact with reality.
This is why verification is so important. The agent had realized it had hallucinated some of the details. It caught three false claims that it was able to correct.
I don't believe in planning. The best spec is the code.
The goal isn't more code, it's maximum impact with the least amount of code.
Having a compile and go green on tests is not the same as actually testing and proving it works in terms of real artifact by deeper verification.
Ray Amjad walks through Felix's Anthropic essay "How to Be More Ambitious," which splits ambition with AI agents into four types: speed, altitude, depth, and range. He skips speed as the thing everyone already does, and spends the video showing concrete Claude Code and Slack-agent setups for the other three: prompting for outcomes instead of tasks, insisting the model use the actual tools an expert would use, and borrowing solutions from unrelated professions. The through-line is that the bottleneck is no longer the model but the ambition of the prompt and the tooling/access you give the agent.
- Altitude means giving the agent the outcome rather than the task — "every page loads in under 200ms for real users" instead of "add an index to the orders query" — and then asking what the goal beyond that goal is.
- Raising altitude only works if the agent has the tools and environments to act; he asks Claude up front what access it needs (Sentry, real Windows/Mac/Linux machines, its own budget-capped AWS account) and lets it ping him when it needs more.
- He replaced himself as the "meat proxy" in support: an agent watches support tickets and Sentry, matches tickets to crashes, tries to reproduce on a real machine, asks the user clarifying questions if it can't, then fixes, merges and replies — including a ticket that arrived in Japanese.
- Instead of dashboards, he has a weekly Slack agent generate ten questions he should be asking about customer satisfaction and revenue and then answer them; this surfaced that median time from first visit to purchase was about four minutes (an impulse buy) and that full video watchers were less likely to buy.
- Agents now own business areas — revenue, signups, refunds, churn, errors — running once or twice a day and only tagging him when something looks off; he also points Claude at the system rather than individual apps, because a fix to the system propagates to everything it touches.
- Depth means forcing the method, not the vocabulary: told to "act professional" a model changes its words but still produces a markdown table, whereas insisting on a performance engineer's tools makes it profile the app and read traces instead of sprinkling lazy loading and useMemo.
- Depth also includes setting an unreasonable target and asserting it's reasonable (ask for 200ms when you want 5 seconds, and push back when Claude says it's impossible), echoing the Riemann hypothesis prompt that spent half its length encouraging the model.
- Range means noticing another field already solved your problem; the trick is converting a noun into a verb (an error message becomes "helping a confused person get unstuck alone"), and since you only know your own field, you ask Claude to interview you and name the professions that handle problems of that shape.
A concrete workflow swap with real numbers, including the counterintuitive finding that full video watchers were less likely to purchase.
Rather than using AI as a way of answering questions that you have, it should be also used as a way of helping you ask the right questions to begin with... the median time from first visit to purchase, I concluded that for one of my products it was about 4 minutes, which puts it in the category of an impulse buy.
The clearest worked example of 'range' — a feature request reframed as a diagnosis problem, producing three features instead of the one that was asked for.
A patient walks in and they say, okay, I need antibiotics. A good doctor wouldn't just give them a prescription... Claude may realize that everyone who's asking for CSV exports, in reality most of them may be importing it into Google Sheets every Monday.
When you fix a bug in the application, then you fixed one bug. But when you fix a bug in the system, then every app, everything the system touches will also get that fix.
When you ask a model to act like a professional, often it will change its vocabulary, but it won't actually change its method.
These models are having jumps every couple of weeks and our expectations are not moving nearly as fast. So this is a gap that you can kind of take advantage of.
The Only SaaS Moats Left in 2026
Rob Walling's MicroConf Europe talk argues that AI isn't ending SaaS, but it is quietly dismantling most of the moats founders relied on. He lays out ten ways AI can attack a SaaS business — six supply-side (customers, competitors, open source, platforms, agencies, the models themselves) and four demand-side (customers going out of business, seat contraction, the managed workflow disappearing, humans being replaced by agents) — and estimates 10–20% of SaaS companies will decline or go to zero. He then names eight moats he thinks still hold, each with a big-name and a small bootstrapped example, plus the question you should ask to test whether you have it.
- Walling's estimate, co-developed with his M&A-side co-author who runs a sell-side advisory for $2–20M SaaS companies, is that 10–20% of all SaaS businesses will decline or go to zero — not the total 'SaaS-pocalypse' of social media, but far from business as usual.
- The supply-side attacks are: customers vibe-coding the three features they actually use, competitors hitting feature parity fast (he counted 46 AI note-takers), AI-accelerated open source that non-technical buyers can now deploy, platforms shipping your feature because your UI was the spec, agencies selling custom builds at near-SaaS prices with recurring revenue, and foundation models absorbing thin wrapper products.
- The demand-side attacks are less obvious: your customers' own industries being wiped out (translation and transcription agencies), seat counts collapsing as support goes 80–90% automated, the thing you manage ceasing to exist (take-home coding test software), and humans using your software being replaced outright by agents.
- Of nine classic moats, he says AI has eroded six — features, clever code, integrations, UX familiarity, owned traffic/SEO, and even high switching costs, since AI can extract data from apps with no export.
- The eight moats he believes still work: buyers know and trust you (QuickBooks, Shopify), you're a system of record (Jira, Gymdesk), you're allowed to act rather than advise (Stripe Connect, Reimbi, Churnkey), customers don't check your work (Gusto, Avalara), someone official already approved you (SOC 2, HIPAA, board-accredited courses, SMS carrier registration), everyone is already in the software (Slack, Commit Swimming), every customer makes the product smarter (Stripe Radar, Ramp, Mailchimp's Omnivore), and it's simply hard to keep running (ScrapingBee, Cloudflare, Drip's spam fighting).
- The learning-loop moat only counts if three gates are met: one customer's data improves the product for everyone, customers can export their data but not what you learned from it, and the system keeps improving.
- These moats matter even for founders who never plan to sell, because private equity does roughly 70% of acquisitions in this market and buyers are now discounting companies they can't see surviving three to five years.
- His favorite diagnostic question: 'What do you maintain that you resent maintaining?' — the operational burden you hate is often the thing a competitor won't replicate.
The sharpest version of the demand-side threat: a competitor doesn't beat you on features, it removes the human who was using your software at all.
Imagine if you were software for receptionists... if you don't agentify your software, build some type of agent on top of it, I think you're going to zero in the next couple years. Cuz someone's going to come along and they're going to say, 'Yeah, you want that software plus a fully autonomous, let's say 90% accurate agent for $300, $500 a month when you're paying 50 bucks a month, but you can let the receptionist go?'
A concrete market signal that public investors are already pricing in which companies have AI-proof moats and which don't.
HubSpot beat earnings, beat almost every expectation, did a billion-dollar stock buyback, and their stock dropped 21%, and Atlassian had similar results, but their MCP server had like doubled in use... they went up 35%.
They don't need your 50 features, they only need the three that they use.
QuickBooks is terrible software, I hate using it, but I don't care because my accountant uses it and he likes it. And a better product doesn't get you in this conversation.
Is it hard to build or is it hard to keep running? Cuz that thing that you hate and resent can actually be a moat.
Jake Van Clief argues that most people don't need to build custom AI agents — they need well-organized folders of markdown files describing who they are, how they like things built, and who their clients/investors are. He contrasts the old approach (databases behind APIs, custom Python connectors, per-task tools, one agent per output format) with giving a single model a minimal "harness" of read/write/search tools plus a readable folder tree, so adding a new capability means adding a folder instead of building a new agent. The second half of the video traces computing history — the Jacquard loom, Ada Lovelace, Descartes, Turing, Claude Shannon, Grace Hopper, compilers, C and Python — to argue that natural language is simply the latest layer of abstraction over machine code, and that structuring your intent in folders is the current step in that lineage.
- The folder method: keep markdown/text files describing how you like things built, who you are, and who your clients or investors are, and the AI reads only the relevant parts when you ask for something.
- The traditional agent approach required a database (SQL, Drive, SharePoint, JSON/YAML) behind an API, custom Python connectors, a separate tool for each output format, and web-scraping plus error handling — and changing "slide deck" to "PDF" meant building a second agent.
- A "harness" is the minimal set of general tools — read files, write files, search the web — that nearly every workflow uses; most leading models already ship with it, so extra agent plumbing is often unnecessary.
- He credits the Unix file-tree philosophy from Ken Thompson and Dennis Ritchie (1969–70) as a 50-year-old fundamental that doesn't stop working just because an AI is the thing navigating it.
- On training a Fortune 500 client's 1,500+ employees with Microsoft Copilot: the PowerPoints were "the worst I have seen an AI make ever" because the model couldn't actually control the software — workarounds involved generating HTML or screenshots and pasting them in.
- Transformers predict the most likely answer, but more context layers shift output toward the most fitting answer; adding your own context folder is how you steer it toward what you consider correct — making the AI a tool rather than something that shapes you.
- Historical thread: Descartes' two tests for a thinking machine (1642), Lovelace's objection that machines can't originate, Turing's reply that nothing is original and that machines can surprise us, and Shannon's separation of meaning from the engineering problem.
- Grace Hopper's compiler was rejected by engineers who said computers could only do arithmetic and that you'd lose control of the code — an objection he points out sounds identical to today's criticism of AI coding.
- Every abstraction layer — binary, assembly, Fortran, C, Python — exists to turn human language into machine action; prompting in English is the newest layer, and folders are a way to standardize the one thing the AI still lacks: your intent.
This is the core cost argument against agent-per-task architecture, stated in the clearest terms in the video.
That's one agent. If I change this word to a PDF document, oh, I don't have a tool for PDFs. So I have to come back over and build a whole new one... Now I have agent one, which builds slide decks and knows about my investors, and agent two that can build PDFs in the same way.
A sharp historical parallel that reframes current skepticism about AI-written code as a repeat of an argument that was already lost once.
I had a working compiler and no one would touch it. They said computers could only ever do arithmetic... It's too unknown. You can't control the code. It's going to make too many errors. You're not thinking about the code anymore. Does that sound familiar?
Because in a world full of cheap answers, questions become valuable, instructions become valuable.
Instead of having to build agents for every process, you're building instructions for each process and letting one AI become what it needs when you need it.
If you don't understand the why, you don't understand how something breaks — and you don't know what you can skip.
Every single time you type the letter K, the letter J into a keyboard, that is hundreds of lines of code being executed. You are living on the top of giants right now.
Anthropic says Claude now writes ~90% of Claude Code's own code, so they've shifted from "did a human read this?" to layered automated checks plus risk-tiered human review. The flow stacks self-checks, multi-agent bug review with voting, a security pass, CI, and a classifier that decides whether 0, 1, or 2 humans must approve. They keep the reviewer honest with daily evals built from real incident bugs, and cap review rounds after agent-vs-agent loops ran a PR through 50+ cycles. The video closes by poking at the headline stats: a 40% drop in revert rate alongside doubled PR volume still means roughly 20% more reverts overall.
- Anthropic's main monorepo went from ~2,500 changes a day in May to over 30,000 on its busiest September day, and Claude Code creator Boris was shipping 20–30 PRs a day back in March.
- The target is that most PRs merge with at most one human involved — possibly the author — with the hard constraint that less human review must not increase reverts or production incidents.
- Review works like Swiss cheese layers: self-verification in the engineer's Claude session, a sub-agent diff review, a multi-agent bug review where agents vote before a comment is posted, a security-focused pass, then standard CI and a PR template covering testing and rollback.
- Recurring reviewer complaints get fixed at the system level — a lint rule or a Claude.md line for real mistakes, and a review.md written by code owners describing what failure actually looks like for false positives.
- A classifier agent assigns each PR a risk tier: low-risk (docs, feature-flagged) needs no human, medium needs one, highest-risk paths need two, with a second agent double-checking the call.
- The reviewer is evaluated daily against real bugs from past incidents, confirmed by the engineers who own the code; any prompt or model change must score higher on the eval to be kept.
- Noise is tracked separately because flagging everything would game the eval, and noise hurts more with agent authors — one PR hit 50+ review rounds overnight, with ~59% of flags on code present since the first review.
- Capping re-reviews at three rounds and only re-checking new changes lifted single-round pass rates from 65% to 78% and cut PRs needing five or more rounds from 9% to 1.5%.
A concrete failure mode of agent-to-agent review, plus the specific fix and the numbers showing it worked.
One PR went through over 50 rounds of review overnight before that author stepped in and stopped it. And when they looked at what the reviewer actually kept flagging, about 59% of it was code that had been there since the very first review.
The one moment that pushes back on Anthropic's headline stat and adds the cost caveat of $15–$25 per review.
If you exactly double your PRs while your revert rate drops by 40%, you still end up with about 20% more reverts overall. So it's a great result per PR, but doesn't necessarily mean that fewer things are breaking.
Instead of asking, did a human read this code, they started to ask, what could actually go wrong with this change?
A good review.md says what failure actually looks like in that part of the code.
You land it, you own it — AI saves the time in coding, but 100% of the responsibility should still remain on you.