Saturday, 17 October 2026
Matt Pocock, a self-taught developer who says he stopped writing code by hand around the release of Opus 4.5 in December 2025, argues the highest-leverage skill in the AI era is communication: being able to surface your unknown unknowns and tell an agent exactly what you care about. He claims the environment agents work in (a clean, testable, verifiable code base) matters far more than which model or harness you pick, and tells the story of abandoning spec-driven development after months of watching his code quality degrade. His practical advice: climb a "trust ladder" slowly, give agents your boring work rather than your most ambitious tasks, and run models at lower effort levels than most people do.
- Pocock treats the Opus 4.5 release in December 2025 as the threshold where he decided he would never write a line of code himself again; before that, agents hadn't clicked for him despite a decade of coding.
- He argues the biggest constraint isn't model intelligence but the communication gap between human and agent — the agent never knows what you care about unless you repeatedly tell it, so garbage environments produce garbage output.
- Old software engineering books about tests, checks and preventing classes of bugs "feel like they were written last week" because raising the floor for 100 mediocre human coders is the same problem as raising the floor for agents.
- His 'grill me' skill makes the agent interview him relentlessly before building, specifically to flush out unknown unknowns like security or deployment concerns the agent would otherwise invent answers for.
- He recommends domain-driven design's 'ubiquitous language' — the same terms in code, database, UI, and client conversations — and built a 'grill with docs' variant of his skill to construct that vocabulary.
- He tried spec-driven development for months on his custom video editor project after seeing an OpenAI talk claiming 'specs are the new code,' watched the code get steadily worse, and ditched specs to focus on code quality instead.
- Contrary hot take on effort levels: he runs Opus 5.5 at medium and is considering going lower, because his tests and code base do the quality work, giving him better token efficiency and speed.
- He disagrees with the 'give it your most ambitious task' pitch from AI lab leaders — he gets the most value giving agents menial, verifiable work he can easily check and correct.
- He reports 200-300 commits a day versus roughly 20 on a good day before agents, and says fixing his project so an agent could click through the app in a browser and take screenshots produced a bigger quality jump than any model upgrade.
A concrete, months-long failure against a popular industry idea, with the reasoning that replaced it: code is the environment the agent lives in.
I tried this for months because I thought this guy was OpenAI, right? He knows what he's talking about... And it wasn't working. So, I realized, no, I'm going to ditch these specs. I'm actually going to focus more on the code.
A direct rebuttal to the 'try your hardest task on our model' marketing line from AI lab leaders, grounded in how he actually uses agents day to day.
I don't know cuz I think the opposite, right? I think give it your most menial boring work... give it simple achievable tasks where you can measure the output and measure how good it is.
The best way to get the best work out of agents is to tell them what you care about.
The skill is being aware of unknown unknowns — of knowing that you could be missing things in your design and not trusting that you've come up with a complete design.
When you learn to drive, what's the first pedal you learn? You learn the brake. You learn how to stop.
What I'm excited about right now is turning agents into that annoying developer who's always on the team who says, 'No, we should do it the right way, not the fast way.'
A walkthrough of P-Stack, an open-source repo of AI coding skills, workflows, and principles published by Lauren Tan (Cursor, ex-Meta/React team). The reviewer maps her skills onto a six-stage AI software development lifecycle — planning, design, building, testing, deployment, maintaining — and notes the defining difference from other skill sets he's reviewed: P-Stack fans work out across multiple models and agents instead of relying on a single model. He concludes that the planning skills are weak for greenfield solo building, but the design fan-out, the 'no comments' rule, 'attack the premise,' and the type-system principles are worth stealing.
- P-Stack is built mostly for brownfield work — existing codebases, migrations, large changes — with 'how', 'why', and 'teach' skills for learning code and 'figure out' plus 'show me your work' for splitting tasks into tickets and logging decisions to markdown.
- The design stage is the biggest departure from other skill sets: an 'architect' skill triggers an 'arena' where multiple models (Opus, GPT, Grok) fan out to propose designs, then 'interrogate' judges and aggregates the best parts into a single design report.
- The building stage pairs a TDD skill with a TypeScript best-practice skill and a 'cleanup diff' skill that diffs the feature branch against main and strips AI slop — stray comments, over-broad try/catch, untyped variables, deep nesting — while keeping behavior identical by re-running tests.
- The 'no comments' rule exists because AI agents often read a stale comment instead of the actual code; if a comment says the function returns A but the code returns B, the model may trust the comment, so removing comments removes that noise.
- Testing separates unit-level TDD from a 'create verification' skill that builds the whole end-to-end harness — spinning up databases and servers, driving user behavior, collecting evidence, tearing things down — with one feature per folder, then uses a 'swarm' of agents on small parts and 'interrogate' plus a 'thermonuclear code quality review' to attack the diff.
- Deployment covers PR hygiene end to end: making PRs easy to review, babysitting the merge, fixing merge conflicts, pulling review comments, and fixing CI; there are no maintenance-stage skills in P-Stack.
- Principles are kept as separate skills with an index map rather than stuffed into a system prompt, because a giant always-loaded prompt burns tokens on rules irrelevant to the current task.
- Two principles the reviewer plans to adopt: 'attack the premise' — when an AI loops on fixing a bug that keeps recurring, stop and question the assumption rather than keep patching — and type-system discipline that rejects impossible states, e.g. a payment that is both paid and pending.
This is the structural difference between P-Stack and every other skill set reviewed on the channel — design by committee of models, then judged and merged.
The architect here is going to trigger the arena to basically have multiple different models and multiple different AI agents fan out and do the design... once we have multiple different designs, we trigger a skill called interrogate, which will have an AI model judge the results and aggregate them back into a single report.
A concrete, counterintuitive rationale for a rule most developers would reflexively disagree with.
Let's say we have a comment says that this function returns A, but this function in the code, it returns B. So what does AI listen to? Well, the AI sometimes just looks at the comments rather than the code.
Often time AI sometimes just reads the comments instead of the code.
It's going to continuously cycle through a loop where we have AI fixing and then blocked, fixing and then blocked... what this skill does is stop and have AI question the assumption.
A payment here could not be paid and also pending at the same time.
Bigger context windows don't make agents more reliable a study of 18 frontier models found all of them degraded as context grew, a phenomenon called "context rot." The video breaks down four ways an agent's context window goes bad (poisoning, distraction, confusion, clash) using a running example of an agent migrating a codebase to a new database driver. Each fix validate, compact, curate, prune works by deliberately throwing information away.
- Context windows have grown to a million tokens or more, but attention is a finite budget spread across those tokens, so every token competes rather than being looked up like a database row.
- A typical agent context window fills up with system prompt, task prompt, project instructions (e.g. an agents.md file), tool definitions, message history, and usually largest tool results like file contents, test output and schema dumps.
- Context poisoning: the agent misreads documentation, writes itself a false note (the new driver auto-retries connections), and then treats its own note as ground truth deleting good retry code file after file.
- Context distraction: with an hour of its own past actions in the window, the history becomes the strongest pattern for a pattern-continuation machine, so the agent repeats old ground instead of asking what the task needs next.
- Context confusion comes from tool sprawl in one benchmark a model failed a task when offered 46 tools but passed the same task with only 19.
- Context clash happens when the agent later discovers its note was wrong and records the correction, leaving two contradictory versions sitting in the window.
- Fixes: validate conclusions against something real before writing them down; compact long histories into summaries (accepting that compaction is lossy, like a photocopy of a photocopy); curate the tool set to what the job needs; prune superseded information or start a fresh window with the corrected state.
- Offloading detail into permanent files and pulling it in only when needed is suggested as a way to limit compaction's drift.
States the counterintuitive finding that motivates the whole topic and defines context engineering in one line.
A recent study looked at 18 frontier models and it turned out that they all got less reliable as the context window got bigger. Researchers have taken to giving this thing a name, and that is context rot.
A concrete, memorable benchmark result showing that simply exposing fewer tools can flip a failure into a success.
In one benchmark, a model failed a task when it was offered 46 tools, but it then passed the very same task, when it was only offered 19 tools.
The more tokens in the window, the less reliably the model uses any of them.
The window might hold a million tokens, but the attention spread across those tokens is finite.
All four fixes work by throwing something away. An agent can get better at long tasks, by holding less.
A tour of the creator's complete daily terminal setup, layer by layer: Ghostty as the terminal emulator, tmux (with his own SessionX and Floats plugins) for multiplexing, Workmux for managing Git worktrees, and Pi as his coding agent. He also announces he has abandoned Nushell and returned to zsh/POSIX after a year of advocating for it. The rest covers zoxide, Atuin, fzf, Starship, Neovim, Superfile, Television and Mise, all of which live in his public dotfiles repo.
- Ghostty is his terminal of choice — GPU-accelerated, written in Zig by Mitchell Hashimoto, who donated it to a nonprofit to keep it open source permanently and has since founded a company building a multiplexer.
- tmux remains his local multiplexer despite trying Hadir and Zellij; he runs Catppuccin plus two plugins he wrote himself, SessionX (fuzzy session picker) and Floats (persistent floating panes).
- He publicly reverses his year-long advocacy of Nushell and returns to zsh, citing friction with exporting environment variables and eval; he still invokes Nushell on demand (e.g. `nu -c ls`).
- Git worktrees are 'Git's best feature with the worst UX'; Workmux wraps worktrees in a TUI dashboard showing diffs, PR status and run time, and `workmux add <name>` spins up a new session with the Pi agent.
- Pi replaced OpenCode as his coding agent because of its speed and lean design; it has a conversation tree that lets you fork any branch to free context without compaction, plus session export/import and gist sharing.
- He configures his agent with ASD-STE100 (Simplified Technical English), an 1980s standard for unambiguous instructions used in aviation, popularized recently by Karpathy but shipped as a Pi extension two months before his tweet.
- Supporting tools: zoxide for jumping directories, Atuin for AI-searchable local command history, fzf as the base for most pickers, Starship instead of Oh My Zsh for prompts, Neovim with LazyVim, Superfile as file explorer, Television, and Mise as a better direnv.
- Everything shown is in his public dotfiles repo on GitHub, and he notes Neovim's team has targeted 2027 for a good out-of-the-box experience.
A creator publicly reversing a year of advocacy, with the specific technical reason why, is the most candid moment in the video.
I'm no longer with Nushell Sumi. I'm back to the zsh, the good old POSIX compatible friend... What I'm tired of not having is this, exporting environment variables or eval.
The clearest explanation of the problem he's solving and how worktrees, tmux sessions and parallel coding agents fit together.
I think they're Git's best feature, but with the worst UX, kind of like tmux sessions when you think about it... Workmux puts everything I just mentioned glued together and with a UI, well, a TUI.
I think work trees are Git's best feature, but with the worst UX, kind of like tmux sessions when you think about it.
Most of the things I show don't stick, but not because they're bad, because they don't work for me.
Fork any branch in case you ask your model how many calories are in a Snickers bar while building a backend in Rust.
Two bets on AI are running in opposite directions: that AI makes software worthless, and that AI companies won't earn enough to repay their debts. The first bet looks weak — the viral "free Photoshop" built with AI covers only about a third of professional work by its own roadmap, and Adobe just posted a record quarter even as its stock fell ~30%. The second bet has real evidence behind it: AI borrowing collapsed from a record $113B in June to $23B in September while the cost of insuring Oracle, CoreWeave and even Big Tech debt hit records. The video's conclusion is that AI can make code cheap to copy without making anyone rich — the value may be leaking out to users rather than landing with model makers or lenders.
- Brandon Thomas, a 15-year software veteran and ex-Square engineer, released seven free open-source Adobe clones built with Claude Opus, claimed he "one-shotted" Photoshop and that "software is over," then walked it back on Hacker News to 99% in months.
- PhotoCraft's own roadmap says it covers roughly 25–35% of what a professional needs daily, five of seven apps were still labeled in development as of October 11, and a Chinese outlet's test of smart filters found it matched Photoshop's output in only 5 of 30 cases.
- Free alternatives have existed for decades without killing paid software: GIMP since the mid-1990s, and LibreOffice had ~200 million users by 2018 against Microsoft Office's estimated 1.2 billion.
- What people actually pay for isn't the code — it's reproducibility, file compatibility, muscle memory, and a whole team, printer and client using the same tool; Adobe's record $6.76B quarter (creative pro segment up 13% to $4.65B) backs that up.
- AI-linked borrowing fell from a record $113 billion in June to $23 billion in September per Morgan Stanley, even though Morgan Stanley had predicted a second-half ramp-up; 2026 still totals about $466 billion versus $101 billion by this point last year.
- Prices say caution, not satiation: insuring $100 of Oracle debt hit a record $2.88/year, CoreWeave's went from $3.68 on October 6 to over $10 nine days later, its 2032 bonds trade at 77 cents, and CDS costs for Amazon, Alphabet, Meta and Nvidia also hit records.
- Broadcom CEO Hock Tan said "a lot of investors have no clue what they're investing in" and that AI investing is "almost like they're in a casino" — while Broadcom sits in a $60 billion financing package with Anthropic.
- Demand is real — Anthropic's Q3 revenue hit $16.8B (up 45%) and TSMC posted a sixth record quarter with profits up 69% — so the narrow question lenders are asking is whether renting out chips earns enough to repay what was borrowed to build around them.
It's the single concrete number that separates "looks like Photoshop" from "works like Photoshop," and it reframes the whole software-is-over argument.
When Photograph opens those files and redraws the picture, it matches Photoshop in only five cases out of 30. So it can read your settings perfectly. It knows you asked for a blur and how strong, but most of the time it cannot turn them into the picture Photoshop would have given you.
A clean logical test that distinguishes the innocent explanation for the lending slowdown from genuine lender nervousness, backed by the Oracle and CoreWeave CDS numbers.
If companies were borrowing less because they already had what they needed, then borrowing should be getting cheaper now or at least staying the same, right? Instead, it's actually getting more expensive.
A lot of investors have no clue what they're investing in... almost like they're in a casino.
Maybe software isn't over. Maybe what's over is the idea that writing the code was ever the valuable part.
AI can make code cheap without making anyone rich.
Claude Code Projects is a beta feature (waitlist, now effectively open) that puts a Claude orchestrator in Anthropic's cloud, where it spawns and manages persistent full Claude sessions called threads. Unlike sub-agents, each thread keeps its own context window, opens its own pull requests, can be messaged directly, and keeps running when your machine is off — and it bills against your Max subscription usage rather than API credits. The video walks through the settings (coordinator vs thread models, memory, GitHub repo, cloud environments, secrets, local folder access) and a 25-minute demo where one prompt split into five parallel threads that built an "AI Creator Radar" dashboard.
- Projects runs in Anthropic's cloud but draws from your Max plan usage instead of API billing, which the host calls the main change from previous Anthropic cloud offerings.
- Access requires submitting an application on a waitlist page; the host says turnaround is now under 24 hours and that everyone was let off the waitlist a few weeks ago.
- Threads are not sub-agents: they're persistent full sessions with their own context windows, they own their own pull requests, and you can message any of them directly as well as through the orchestrator.
- Don't use it for quick one-session tasks, work that must manipulate local files, or team/enterprise setups; do use it for long-running, complex builds that split into parts and live in a GitHub repo.
- Default models are Opus on low effort for the coordinator (it only delegates, so low is fine) and Opus on medium for threads; usage can burn fast with 10-15 workers running at once, and there's an auto-continue setting that resumes work when limits reset.
- Setup requires designating a GitHub repo; adding API keys means creating a custom cloud environment with network access and secrets, which the demo had to do mid-run to clear a blocker.
- You can enable local device access with pre-approved folders — in the demo, the X-scanning thread ran locally to use logged-in browser cookies and built a scheduled routine on the machine.
- A debug access panel lets one project inspect another to troubleshoot a poisoned context or stuck memory.
- Boris Cherny, who created Claude Code, reportedly stopped managing desktop sessions and uses Projects as a backlog/dumping ground for ideas since everything shares memory.
This is the core technical distinction that makes Projects different from the sub-agent pattern people already use.
They're full sessions because they have their own context window. Furthermore, they're persistent. They'll own their own pull requests. And because these workers are persistent and they maintain context throughout, we can also message them as much as we want.
Shows the actual orchestration output and the review/blocker workflow you'd be managing day to day.
After we gave it the prompt, it split into five parallel threads, and each thread was given some piece of the pie that it needed to execute on... I have two that are now ready for review. I have three that have some sort of blocker.
Instead of you being in charge of managing all of these separate threads, guess who does it? Well, Claude does it.
Sessions with sub-agents is best when we're just doing one task at a time. These projects are great if we have a stream of work we just don't want to babysit.
The real sell for projects at this point isn't the singular thing it created. It's the fact that this is now something that is living in the cloud.
Eric walks through an open-sourced "software factory" — a set of Claude-style agent skills that pull issues from telemetry tools (Sentry, PostHog), turn them into GitHub tickets, and run them through a builder → QA → reviewer loop that mimics a real dev team. Each specialist agent chains curated skills: Ponytail for complexity reduction, Context7 for library docs, MapPoke for implementation, plus dedicated QA and review flows, with every agent comment logged on the GitHub issue. The setup is meant to be model- and harness-agnostic (Claude Code, Codex, etc.) and installable in about three steps.
- The pipeline is: telemetry (Sentry/PostHog) → a "supercollect" skill that scrapes issues on a schedule → GitHub project board tickets → "superboard" which runs specialist builder, QA, and review agents one ticket at a time.
- Failed QA sends the ticket back to the builder for revisions, and tickets needing human sign-off get moved to a blocked column rather than auto-shipped.
- Every agent's work and comments are written back to the GitHub issue along with the pull request, so a human or another agent can audit what happened.
- Before any code is written, the builder runs two prep skills: Ponytail, which uses a seven-rung ladder to ask whether the code should exist at all (reuse a util, a standard library, a native platform feature, an installed dependency, or a one-liner), and Context7, which reads the real documentation for the project's dependencies.
- The build step uses MapPoke skills — chosen over GSD, GSTA stack, and superpowers after reviewing them — with separate modes for implementing features, diagnosing bugs, and codebase redesign for refactors.
- The QA agent is built around testing-pyramid discipline: unit tests first, then integration and React component tests, and only then Playwright or Cypress end-to-end tests, so the right library is used for the right ticket.
- A separate UI refinement loop combines MapPoke with the Impeccable skill to diagnose, critique, restyle, add motion, and polish a page over several iterations to reduce "AI slop" design.
- Guardrails are enforced with hooks that block secrets from being committed, auto-generate a skills eval file, and keep README documentation from going stale.
Concrete explanation of the single biggest lever against agent code bloat, with the actual checklist the skill applies.
A lot of AI agents are writing code just duplicate after duplicates — a single file could be like a thousand or 100,000 lines. So what it does here is it has a ladder to see if this code here should be actually written at all.
A specific, defensible design decision that separates this QA agent from generic 'write some tests' prompts.
Chances are you probably are using Playwright for your testing. But that's the actual last step for testing itself. You want to actually test the bottom layer, like the fundamental unit testing layer, and eventually move up to integration testing or component testing.
A small feature once it's shipped can be used by millions or hundreds of millions of people, and one bug can cause a real cost in a production application.
Impeccable skill is simply a skill helping to design UI that are less AI slop.
Each ticket is actually being tracked inside of the GitHub issues... so any agent or human here can look at the actual issue log and see exactly what happened.