Delete your CLAUDE.md. Not edit it, not trim it, delete the whole file, along with your skills and your hooks, and see what the model does without them. That's Boris Cherny's actual advice from a recent YC appearance, and the Claude Code team has apparently followed it internally enough times that roughly 80% of their own system prompts are gone. His reasoning: most of those rules patched a weakness in whatever model you ran six or twelve months ago. Newer models often don't have that weakness anymore, so the instruction that used to help is now just constraining a more capable model for no reason. His method is almost embarrassingly plain. Delete everything, work normally for a while, watch where the model actually goes off track, add back exactly one instruction when a mistake repeats, and run the whole cycle again at the next major model release. Keep security and compliance rules. Keep the project quirks a model genuinely can't infer from reading the code. Cut folder structures, dependency lists, and architecture summaries, since a capable model can read those off the repo itself faster than it can read your stale description of them. This is the same problem the rest of the field keeps rediscovering under different names. Anthropic's own long context guidance, OpenAI's notes on attention tradeoffs inside big windows, and Microsoft Research's GraphRAG papers all circle the same fact: a pile of context that only grows, whether it's a system prompt, a vector store, or a knowledge graph, degrades the thing using it, because stale facts sit next to current ones with no signal about which one wins. DeepSeek Harness takes a different structural swing at the same target, building its agent runtime out of swappable plugins so a stale capability gets replaced instead of buried under new instructions. What strikes me is how little of this is about model capability and how much is housekeeping nobody assigned themselves. Most teams have a deprecation policy for their actual code. Almost nobody has one for the three paragraphs pasted into an agent's instructions eight months ago and never looked at again. How long is your CLAUDE.md, and when did you last delete anything from it? xitter.cf/suraj_sharma14/status/…

Someone clones Beehiiv because it is too expensive. Someone else clones that clone because it is still too expensive. Then a third person clones the free version and ships it for nothing. That is Jack Ellis's joke this week, and it is not really a joke anymore. GitHub says 92% of developers now use an AI coding tool somewhere in their workflow. Cursor is past 100 million dollars in annual revenue with under 20 people. Midjourney passed 200 million with 11. Numbers like that used to describe outliers. Now they describe the default cost of building software, which is heading toward zero, and the default cost of cloning it, which is heading toward zero right alongside it. Postiz is the cleanest example running right now. Open source, 38,000 stars on GitHub already, and this week its own community supplied the irony: someone claiming to be a fired contributor said he was releasing the full source code as payback, and people had to point out it was already sitting on GitHub. The real story under the drama is a founder discovering the moat was never the code. What is still actually defensible: distribution you already own, a community that argues on your behalf, data that compounds with every user, and ecosystems other people build on top of, the way Shopify's 13,000 app marketplace works for Shopify even though anyone could clone any single app inside it. Notion gets cloned constantly and keeps growing anyway, because the clones compete with the product, not with the distribution. Founders panicking about this are not wrong to panic. They are aiming at the wrong target. Code was never the moat. It just took free cloning tools to make that obvious. xitter.cf/JackEllis/status/21145…

Two different agent stories broke this week, and most people are treating them as one story when they are not. Anthropic told teams to rip specialist subagents out of their systems and fold them into one main loop: skills for know how, tools and MCP for doing things, subagents only for real parallel work. That is about simplifying one agent's internal design. Separately, someone building a tool called Orca posted about getting Claude Code to use 13.9% fewer tokens in a benchmark, with the real win being able to see what each agent did and share memory between Claude Code and Codex. That is about orchestration, running several different agents side by side on different tasks and comparing them. Different problem, different fix, same week. Orca answers the orchestration question with a desktop IDE and git worktree isolation per feature. We built Campfire to answer it with something closer to a team: run Claude Code, Codex, Goose, Aider, and OpenHands side by side in one browser tab, race the same task across backends in isolated worktrees, and let majority vote or any single deny decide what an agent is allowed to actually touch in your repo before it touches it. The piece most multi agent tools skip is memory. Running agents in parallel is the easy part. Giving them a shared context stream and session replay, so the next run does not repeat the last run's mistakes, is the harder and much less visible problem. It is also the one that decides whether parallel agents compound or just multiply your review load. bunx the-campfire gets you running in one command. github.com/stretchcloud/camp… xitter.cf/AhmedYsrrr/status/2114…

The Netherlands just told its interior ministry: find savings in the civil service, and let AI do it. Civil servant headcount went from 140,000 in 2021 to 170,000 last year, policy roles nearly doubled to 20,000 in a decade, and the fix on the table is new AI tooling to claw some of that back. Insiders are pointing at roughly 200 million euros in savings in 2028 and in 2029, scaling to a billion euros a year by 2035. Scale like that is not subtle. The UK is running the same experiment with better data to show for it. HMRC just handed out 28,000 Microsoft Copilot licenses, with its own line being that it wants to become "the most AI-enabled tax authority on the planet." The cross government trial behind that rollout, 20,000 civil servants, found an average of 26 minutes saved per person per day. Seventy percent said it cut time spent hunting for information. Eighty two percent said they would not want to go back. The Alan Turing Institute puts a ceiling on this: up to 41% of public sector tasks could get AI support, and drafting alone could cut email time by 70%. Here is the part nobody is pricing in. The Dutch government's own advisory committee warned that AI only pays off if you also cut the pile of rules and compliance checks sitting on top of the work, not just bolt a chatbot onto the existing process. The Register's reporting on HMRC makes the same point from the other side: Copilot is good at finding and summarizing, shakier on complex or sensitive casework, and nobody has resolved what happens when an agent gets someone's tax file wrong. My read: the job cuts are the easy headline. The actual hard problem, in The Hague and in Whitehall both, is whether anyone redesigns the process the AI sits inside, or just hands the same broken workflow to a faster intern. xitter.cf/Polymarket/status/2114…

A post worth sitting with this morning: Google's AI Overviews and AI Mode have started citing dedicated "LLM info pages" for queries that don't even mention the brand. The point isn't that you need more content, it's that you need pages structured for passage extraction specifically, chunked so a retrieval system can lift one section cleanly, and that most SEO advice is telling people to skip exactly that step. Zoom out and the whole category is chasing the same problem from different directions. Firecrawl raised a $75 million Series B last month to build Alexandria, a knowledge library pulling structured data from 70 million codebases and tens of millions of government filings, essentially pre-digesting the open web so agents don't have to. Samesurf is pitching simulated browsing as a replacement for scraping entirely. Everyone agrees raw HTML is the wrong input for an LLM. Nobody agrees on where the structuring should happen. I think it should happen once, deterministically, at the source, not re-run through an LLM on every single fetch. That's the whole premise behind DeepScrape: generate CSS selectors once, let them self heal when a page's layout changes, and only call an LLM for the targeted work, generating, validating, and adapting selectors, not for reading the page over and over. Output comes out as markdown, tables, or structured JSON, already chunked the way that SEO test found, whether or not the site owner ever built an "LLM info page" on purpose. Point the MCP server at a site and an agent can query it directly instead of re-scraping it cold every session. The pages winning citations right now are the ones that did this structuring by hand. The interesting question is what happens once it's automatic for every page on the web, not just the handful built for it. github.com/stretchcloud/deep… xitter.cf/Charles_SEO/status/211…

Anthropic's applied AI team spent the last year watching enterprise customers build agent systems that look like org charts: a router on top, a planner underneath, one specialist subagent per function. Their new guidance, out this week, says most of that should come apart. One customer ran roughly twice as fast after collapsing their setup into a single agent with a shared context window. The failure mode Anthropic names is specific: every subagent handoff returns a summary, and every summary drops detail. They call it a telephone game. The replacement pattern is one model, one context window, an open ended tool loop with turn and cost budgets enforced by the harness rather than the prompt. Each subagent's job becomes a skill. Its API calls become MCP tools. Approval gates move into the tools themselves. None of this works without progressive disclosure, loading instructions only when a task actually needs them. Anthropic says that technique alone cut Claude Code's system prompt by more than 80% on their newer models. It's also why the pattern couldn't have shipped two years ago: the models weren't reliable enough to manage that much ambiguity in one context window. Worth noting this isn't a totally new argument. Cognition built Devin on a single sequential agent back in 2024 explicitly because they'd watched multi-agent swarms produce confident, coordinated nonsense. LangGraph and CrewAI still default most users toward multi-agent graphs. Anthropic is now telling its own enterprise customers the opposite of what half the agent tooling industry sells by default. The honest caveat in their own writeup: folding one subagent lowered latency but broke a process in one of two test runs, because the agent skipped a shipping check it used to delegate out. Their fix isn't "don't fold," it's "fold one at a time and eval every change with real examples." That's a less exciting takeaway than the speed number, and probably the more important one. xitter.cf/Arindam_1729/status/21…

Five days after Claude Duet went waitlist only, there are already two independent open source rebuilds live on GitHub. One calls itself OpenDuet, MIT licensed, built by someone who had it running on open models within 48 hours. A separate project, also named open-duet, lets you name agents, give each one a workspace and a model, and have a lead agent hand off tasks to specialists, as long as that lead is Claude or Codex. That's the tell. Everyone rebuilding Duet is converging on the same shape: one coordinator, a few named workers, approval gates before anything sends or pays. What none of these clones do yet is let you run several different agent engines against the exact same task and actually compare them. That's the gap I built Campfire to close. Run Claude Code, Codex, Goose, Aider, and OpenHands side by side in one browser tab, not because one is strictly better but because for a lot of real tasks you don't know which is until you've seen both try it. Agent races put the same prompt in front of multiple backends in isolated git worktrees so you can diff the outcomes instead of guessing from a benchmark leaderboard. Permission voting extends the single approval gate pattern these Duet clones use into something that works across engines you don't fully trust yet: majority rules to approve, any one agent can veto, a 30 second timer so nothing stalls a session waiting on a human who stepped away. Self hosted, bunx the-campfire to run it. Session replay, a cost dashboard, and a kanban board built straight from the agents' own tool calls, so you can see what happened without reading raw logs. github.com/stretchcloud/camp… xitter.cf/RoundtableSpace/status…

$16.3 billion in revenue for the first half of 2026, up from $1.1 billion a year earlier. That's the number sitting at the top of Anthropic's S-1, filed with the SEC this morning ahead of a reported Nasdaq listing targeting something close to a $2 trillion valuation. The number that actually matters more: $9 billion spent on compute in just six months, already more than the $7.3 billion spent in all of 2025. Anthropic has locked in roughly $450 billion in noncancelable cloud commitments over the next decade: $111 billion with Google Cloud, $110 billion with AWS, $31 billion with Microsoft. The filing says it has asked hyperscalers for more capacity than they were willing to supply, which is why it's now chasing third party data center deals directly. Net loss for the half: $80.7 billion. About $72 billion of that is non-cash, tied to how convertible notes and financing instruments get marked. Strip that out and the operating picture looks far less alarming than the headline number, but it tells you something about how much of this business is still financial engineering layered on top of a product that didn't exist at this scale three years ago. Two risks stood out to me in the filing language. Customer concentration: about 20% of first half revenue came from two customers. And a catastrophic liability clause, flagging that damages from a severe AI safety incident could exceed what its insurance actually covers. OpenAI is reportedly sitting this year out, with Altman pointing to a 2027 window instead. Whoever goes first sets the pricing and disclosure bar the other has to match. My read: the real story in this filing isn't the valuation number everyone will quote today, it's that Anthropic just told the public market exactly how capital intensive frontier AI actually is, in a level of detail no earnings call has given us yet. xitter.cf/testingcatalog/status/…

Web data shouldn't be ephemeral. Olostep posted today, and they're solving it by selling retention: pick 10, 30, 90 days or forever and they'll persist your extraction results so a pipeline regression doesn't mean scraping everything again from scratch. The need is real. A page's markup shifts, your selectors silently return half empty records, and now you're stuck inspecting the exact page your agent saw last week to figure out what actually changed. Most scraping setups have no answer to that beyond rerunning the whole job and hoping. I built DeepScrape to answer it differently: keep the data and the detection in your own infrastructure instead of renting a retention tier. It runs CSS selectors with no LLM in the loop for the common case, so there's no per page model cost and nothing to hallucinate. When a site's structure actually changes, /api/extract-auto has an LLM re derive the selectors once, caches the fix, and goes back to running without a model, the switch triggers automatically once too few records populate required fields. Save an endpoint as a SiteSpec and it gets re verified on a schedule, self heals on drift, and becomes its own MCP tool your agent can call directly. Change tracking against previous scrapes and a 30 day snapshot window give you the same "what did my agent actually see" answer Olostep is charging for, except it's your Redis and your Docker container holding it, not someone else's billing tier. 330 stars in, MIT licensed, and it still won't touch a CAPTCHA for you. But if the retention pitch sounds expensive for a problem you could own outright, it's worth a look. github.com/stretchcloud/deep… xitter.cf/olostep/status/2114084…

Enter a URL. Get back thousands of ads for a product the software has never seen before, launched before your coffee gets cold. That's Fastlane's pitch with what it's calling Claude for Ads: point it at a website and it pulls the brand's past ads, studies what's working for competitors, mines Reddit and Amazon reviews for underserved angles, generates the creative, and launches it straight into the ad account. No agency brief, no three week turnaround. The category around this is more crowded than the demo video suggests. Creatify raised a $15.5M Series A last year backed by Katzenberg's WndrCo, crossed $9M ARR, and calls itself the first end to end AI ad agent for video. AdCreative.ai has taken a slower path, $3.3M total from Koc Holding and a couple of smaller funds, still mostly a creative generator rather than a full launch and optimize loop. Omneky raised a $10M seed on the same thesis. GetCrux, a YC company, is narrower: it studies what's already winning and ships on brand variations, claiming roughly double the iteration speed with acquisition costs down about 10 percent. Fastlane's own numbers: 70,000 plus businesses, pricing from $29 to $999 a month by credit volume, and a table on its site putting minutes to first launched campaign against three to four weeks for an agency. None of those figures are independently audited, they're the companies' own dashboards. And every one of these startups is building on top of the exact platforms, Meta and Google, that are shipping their own in house generative ad tools for free inside the ad manager. The generation problem looks basically solved across this category now. What's still unsettled is whether anyone lets an agent spend real budget unsupervised, and every one of these companies is quietly betting that answer changes within a year. xitter.cf/UseFastlane/status/211…

Fourteen bugs caught by one agent. Sixty six caught by a team of them, same seventy planted bugs. That's the number builders are throwing back at Anthropic this week, four days after Anthropic's own guide told everyone to fold their subagents into a single loop. The guide itself is more careful than the headline suggests. Anthropic says newer models, starting with Opus 4.5, hold a complex plan in one context window well enough that splitting it into subagents just adds latency and cost. In their own comparison the single loop ran about twice as fast. They cut the Claude Code system prompt by more than 80 percent once skills and tools started loading on demand instead of living in every prompt, and they found tool selection quality degrading once an agent carries more than 30 to 50 tool definitions at once. They shipped the methodology as a repo too, single-agent-loop-kit, Apache licensed, so anyone can run their own comparison instead of taking the blog post on faith. What Anthropic is really describing is org chart leakage. Every team ships its own subagent, the architecture ends up mirroring the reporting structure, and you get overlapping agents arguing over conflicting system prompts. A Vals study backs this up from a different angle: scaling an agent team from 10 to 30 to 100 members added cost with no quality gain. Eric Provencher at OpenAI called agent swarms almost certainly a waste of money, months before Anthropic said roughly the same thing in writing. LangGraph, CrewAI, and AutoGen survive this, but their job gets narrower. Coverage tasks where a clean split catches more, bug hunts, red teaming, parallel search, still favor the swarm. Tasks where handoffs lose context favor the loop. Watch who still owns the merge step six months from now. That's the part no one's benchmark is measuring yet. xitter.cf/hansel_hansl/status/21…

Stop iterating with your agent. That's the line from Thorsten Ball's piece this week on how he actually works with coding agents as of October 2026, and it cuts against almost everyone's default habit. Most people still work an agent conversationally: try this, no, try that, back and forth. Ball's point is to skip the back and forth. Ask for 20 variations and a page to compare them. Ask for four theories on why something is slow, then have the agent check all four at once. The piece reads like a field manual, not a hot take, and the specifics matter more than the thesis. Use the frontier model, always, because a model that's wrong 10% of the time costs more in rework than it saves in per token price, and you can't tell which 10% in advance. Stop managing context by hand, compaction works, one thread equals one task whether that thread runs 46 messages or 3,714. Give the agent the whole software lifecycle, not just the editor: production logs, deploys, rollouts, bug triage, so it stops guessing at the parts it can't see. And the line that actually changes how you'd review code: ask for irrefutable proof, a before and after number or an end to end walkthrough, then only hand review the five or so files with real blast radius. Everything else, the question is just does it work and can you change it in a month. This only works because the tooling caught up to the philosophy. Ball builds Amp at Sourcegraph, which runs background tasks in parallel through what it calls Orbs and bills pay as you go at provider cost with no markup. Claude Code ships the same async posture through GitHub Actions and scheduled pipeline jobs, bundled into its $20 to $200 Pro and Max tiers. Devin takes it furthest, running in sandboxed VMs with its own browser and terminal, billing seat fees plus credits for the heavy autonomous runs. Cursor, by contrast, is still mostly a conversational tool built around the editor, which is precisely the model Ball is arguing past. None of this is about which agent is smartest. It's about whether you've rebuilt your own workflow around waiting for proof instead of narrating every step, and most teams haven't gotten there yet. xitter.cf/thorstenball/status/21…

There's now a prediction market on whether AI's data centers survive their own financing. Polymarket posted it this week: most of the 200+ AI neocloud companies collapse or consolidate as debt markets cut off funding for data centers, citing a warning from Elon Musk. Musk's actual reply was shorter, one word, "yikes," to a chart of CoreWeave's bond yield hitting a record high. The number behind the yikes is real. Five year credit default swaps on CoreWeave's bonds hit 1,194 basis points on October 15, up from roughly 300 in June, which Bloomberg reads as better than 60% odds of default within five years. The stock is 56% below its October 2025 peak of $150. CoreWeave's debt went from $21 billion at the end of 2025 to $35 billion by June, net interest expense nearly tripled to $640 million a quarter, and it still posted a $626 million net loss on $2.58 billion of revenue. Management points to a $104 billion backlog as the answer. Gartner isn't buying the backlog argument at the category level. Its October 14 note says AI infrastructure spending needs $8.5 trillion in cumulative revenue through 2030 to clear a 12% return hurdle, against a forecast $3.6 trillion actually showing up, with over $3.5 trillion in spending exposed to impairment and more than 80% of neoclouds not surviving as independent companies. And yet the same week, Lambda is reportedly raising $3 billion at a $12 billion valuation, up from $2.5 billion in February 2025, eyeing a 2027 IPO. Crusoe is in talks near a $30 billion valuation after a $10 billion round months ago. Nscale is prepping a US listing on a $51 billion contracted backlog. Nvidia owns roughly 10% of CoreWeave and has backstopped it with a $2 billion equity check and a $3.5 billion convertible note, which tells you who actually can't afford for this to unwind cleanly. A $104 billion backlog only protects a company if the revenue arrives faster than the interest compounds. Gartner's math says it won't for most of these companies. Nvidia's checkbook says at least a few of them aren't allowed to find out the hard way. xitter.cf/Polymarket/status/2114…

"CapCut doesn't need to exist." Andrew Wilkinson said that about his own portfolio company's software this week, after CapCut announced a ChatGPT plugin at CapCut World LA. His argument: Claude and ChatGPT plugins integrate your software into their interface, train users to work that way because it's genuinely a better experience, then quietly cut you out. The mechanism is already live, not theoretical. OpenAI's Apps SDK shipped pilot apps with Booking.com, Canva, Coursera, Figma, Expedia, Spotify and Zillow, with DoorDash, Instacart, Uber and Target queued up next. ChatGPT now suggests an app mid conversation, Zillow for a house hunting question, and OpenAI pitches developers on reaching its 800 million weekly users. Anthropic answered on January 27 with MCP Apps, an open extension of its own protocol, launching with Asana, Box, Canva, Figma, Slack, monday.com, Hex, Clay and Amplitude, Salesforce's Agentforce 360 coming next. Microsoft and Google are running the same trade in reverse, pushing Copilot and Gemini into Word and Sheets rather than pulling Word and Sheets into the chat. Most analysts expect the two models to converge. Wilkinson's point is sharper than the usual "AI disrupts software." These aren't API integrations where your product still owns the interaction. A plugin inside Claude or ChatGPT means the model owns the conversation, your product just executes the task, and the user never has a reason to open your app again. Everest Group is already flagging the other side of that trade: running a third party's UI inside your agent raises the due diligence bar, since enterprises now have to audit what that sandboxed interface can see and touch. A lot of what passes for a SaaS product in 2026 is a UI wrapped around a database call, and that's exactly the layer getting commoditized first. Booking.com and Spotify can survive fine as a booking engine and a catalog sitting behind someone else's interface. Companies whose entire value proposition was being the interface can't. The part people keep missing is that an API was never the moat. The relationship with the user was, and that's exactly the layer Claude and ChatGPT are now absorbing directly. xitter.cf/awilkinson/status/2114…

Vikrant Shukla published a pre-Black Friday checklist this week for making a store readable by shopping agents: move facts out of banner images and PDFs into attributes, normalize colour and size names, keep Product and Offer markup complete, make sure the API matches what the storefront shows. Practical, and worth running, but it assumes the merchant has the engineering time to do it before code freeze. Most won't. Shopify's Agentic Storefronts, part of the Winter '26 Edition, already pipes catalog, checkout, and brand data straight into ChatGPT, Copilot, Google AI Mode, and the Gemini app for stores that adopt it. The Universal Commerce Protocol that Shopify and Google launched at NRF in January gives agents a standard way to browse and buy across merchants. OpenAI and Stripe built the Agentic Commerce Protocol for checkout inside ChatGPT itself. Adobe measured AI-referred traffic to US retail sites up 4,700% year over year by last July, and McKinsey now puts 3 to 5 trillion dollars of global retail spend in play for agentic commerce by 2030. Shoppers who arrive through an agent convert 38% more often than ones who don't. None of that protocol work reaches the millions of stores that never get to Vikrant's checklist in time, running on platforms with no Agentic Storefronts equivalent, selling through catalogs an agent still has to read the hard way. That's the problem DeepScrape solves from the other side: generate a selector once against the page as it actually exists, run it deterministically on every visit after that, and only call a model again when the page changes shape and the selector starts failing. Markdown, tables, and change tracking come out the other end without burning a token on pages that haven't changed. An agent doesn't need your store to have adopted a protocol. It needs the data to come out clean once, and stay that way. I'd rather build for that reality than wait for every merchant to finish a protocol migration. github.com/stretchcloud/deep… xitter.cf/vikrantshukla/status/2…

Nine benchmarks, not two or three. Epoch AI ran its Benchmark Reviews program across 15 widely cited tests and could only fully verify four of them: ExploitBench v0.1, SimpleQA Verified, PostTrainBench v1.1, and WeirdML v2. Nine others, including SWE-bench Verified, SWE-Bench Pro, Terminal-Bench 4.0.0, Humanity's Last Exam, and HealthBench Professional, got flagged flawed. Two more came back inconclusive. The bar for flawed is an error rate of 20% or higher in a stratified sample of 50 tasks, or a grading problem systemic enough that sample size stops mattering. The errors aren't typos. Reviewers found invalid tasks, false negatives, false positives, under-elicitation, setup bias, and silent versioning, where a benchmark quietly changed underneath the leaderboard. A separate citation in the same review found errors in 42% of FrontierMath v1 problems. SWE-bench Verified making that list matters more than the others because it's the single most quoted number in coding-agent marketing right now, the same leaderboard every CLI and IDE agent cites to prove itself. Hamel Husain, who has spent his career building evals, called the gap between benchmark quality and industry reliance on them astounding, and he's not alone in paying to close it. Braintrust raised a 36 million dollar Series A led by a16z at a 150 million dollar valuation this year, with Notion, Stripe, Airtable, and Zapier among the customers paying between five figures and over 100,000 dollars to run their own evals instead of trusting a published score. Braintrust's own numbers claim accuracy often climbs from under 40% to over 80% within weeks of adopting real evaluation. A leaderboard number is marketing until someone runs the failed examples by hand. Most teams still skip that step because the benchmark did the work of looking rigorous for them. xitter.cf/HamelHusain/status/211…

Nobody ships agent-to-agent coordination out of the box yet, so people build it themselves. Alex Salnikov spent this week wiring cross-agent comm into his own Claude Code setup, agent and human working one repo as peers, and framed it as a direct transfer from six years of people management. Most of what's out there still orchestrates one vendor's agents talking to themselves. Claude Code spawns sub-agents, opencode does the same, Amp spawns parallel sub-agents of its own. Cline adds a Plan and Act approval step before each change. Codex on the web, Devin, and the Copilot coding agent run in hosted sandboxes and hand back a pull request. None of that is agents from different vendors working the same repo with a vote on what ships. That's the gap I built Campfire to close. Run Claude Code, Codex, Goose, Aider, and OpenHands side by side in one browser tab, each session isolated in its own git worktree so a bad edit from one backend never touches another's work. Permission voting means majority rules approves a change, any single deny blocks it, and a 30 second timer keeps a stalled vote from freezing the session. Agent races run the identical task across every backend at once so you can see which one actually gets it right before you commit to a vendor. A Collective Intelligence layer gives the sessions shared context streams and semantic memory instead of each one starting cold. Management, not babysitting, same instinct Alex is building toward by hand. github.com/stretchcloud/camp… xitter.cf/insider0x/status/21144…

Uncle Bob Martin said something blunt this week: he's done with CLI agents, and he's building through grokbots now. elvis, who has spent years as a CLI power user, agreed and went further: the point of contact for agents keeps getting simpler, and anyone optimizing their workflow around a terminal window is optimizing for last year's constraint. The data backs the discomfort more than the conclusion. A JetBrains survey has Claude Code at 18% work adoption against 3% for Codex CLI, with Gemini CLI and Antigravity both sitting around 6%. On Terminal-Bench 2.0, Codex CLI scores 77.3% to Claude Code's 65.4%. Antigravity, running Gemini 3 Pro, posts 76.2% on SWE-bench Verified. Grok Build claims 70.8% and eight parallel agents running at once, numbers nobody outside xAI has verified yet. None of those numbers settle the CLI question, because CLI versus app was never really about the interface. Claude Code's CLAUDE.md convention is a switching cost dressed up as a config file: once your repo context lives in that format, moving to Codex or Grok Build means rebuilding it. Copilot answers with a different lock-in, consumption pricing tied to the GitHub ecosystem you already live in. Gemini CLI competes on a free tier of 1,000 requests a day on Flash, then loses a chunk of that goodwill to rate-limiting and file-destruction bugs from March that still aren't fully resolved. What's actually shifting is who absorbs the integration tax. A terminal makes you do it yourself. Grok Bot and the Codex app are betting enough developers would rather pay in dollars or vendor lock-in than in setup time. I don't think CLI agents disappear. I think they stop being the default for anyone who isn't already deep in one, and the real fight moves to whoever owns the context once you're in. xitter.cf/omarsar0/status/211448…

A solo builder named Marcos Damasceno took a hand-written inference engine from 2 tokens a second to 106 on a single RTX 5080, running Gemma 4 12B at batch size one with no speculative decoding, and the fix that got him there is the opposite of what the usual advice tells you to do. The obvious move when a GPU sits idle between reads is to fill that idle time with prefetching, loading the next weights into cache while the card waits. He tried it, measured it across eighteen controlled comparisons, and it made the engine 2.7 to 3.6 percent slower every single time. The real cost turned out to be blocks on the chip waiting on each other at synchronization barriers, not idle memory. Replacing blanket barriers with direct signals between only the blocks that actually depend on each other took the engine from 91 to 106 tokens per second without reading a single extra byte. This is the same territory llama.cpp, vLLM, and SGLang have spent years optimizing, and the comparison he ran against llama.cpp is honest about where his engine still loses: at a short prompt the two are close, 97 against 96 tokens per second, but on an 8,000-token prompt his engine reads the prompt 70 to 140 times slower because it hasn't built prompt batching or a persistent KV cache yet. Those are well understood problems with known fixes, just not built yet. What stands out is less the benchmark and more the method. He kept a record of every speed measurement tied to the exact code version that produced it, which is how he caught that an earlier speedup he'd credited to one change was actually 3.68 percent from that change and the rest from twenty-seven others. Most performance claims in this space don't survive that kind of bookkeeping. xitter.cf/marcospaulosd/status/2…

What happens when you train a model to argue well about moral dilemmas, then let the same kind of model grade its own arguments? Google DeepMind ran that experiment and published it this week as Consistency Is Not Validity. They trained a policy model with reinforcement learning in a self-judged tournament, where generated arguments about dilemmas pulled from classic literature were judged pairwise by the policy itself for argument quality. Tested against three external benchmarks, MoralChoice, ELEPHANT, and MORABLES, the trained model got more decisive and more invariant to having its options reordered. The problem is that decisiveness and correctness turned out to be different things. Sycophancy and reframing still moved the model's verdicts even after reordering stopped working as an attack, and the paper's conclusion is blunt: consistency under reordering can be optimized without improving the moral judgment it's supposed to signal. This lands in the middle of a crowded year for eval reliability. Braintrust, Galileo, Arize Phoenix, and Patronus AI have all built businesses around catching exactly this kind of drift, mostly by treating the judge itself as something that needs versioning and periodic revalidation against human-reviewed examples rather than a fixed oracle. Patronus open-sourced Lynx specifically to catch hallucinations a judge model would otherwise wave through. A NeurIPS paper making the rounds this year calls social sycophancy a hidden tax on judgment reliability, which is a precise way to describe what DeepMind just measured directly. None of this means LLM-as-judge is broken beyond use. It means treating a judge's score as ground truth was always going to be a mistake, and the industry is only now building the tooling to catch it instead of trusting the number on the dashboard. xitter.cf/HEI/status/21145059717…

An open source project called Diffinery showed up this week that gives Claude Code and Codex their own GitHub accounts, with guardrails enforced server-side instead of trusted to whatever the agent decides to do, running through a built-in MCP server you deploy to your own Cloudflare account. Fifteen stars right now, which is nothing, but the shape of the idea is the part worth noticing. Self-hosted execution for coding agents has quietly become its own category this year. E2B runs Firecracker microVMs and is the usual baseline people compare against. Daytona went closed source back in June, so its public repo is frozen and isn't a real self-hosting option anymore. Modal has strong sandboxes but no on-prem path. Most teams end up choosing between operating someone else's control plane or stitching together Docker and raw Firecracker themselves, and neither answers the actual question underneath all of it: when more than one agent is running against the same codebase, who verifies what each one actually did. That's the gap I built Campfire around. It runs Claude Code, Codex, Goose, Aider, and OpenHands side by side in one browser tab, with majority-rules permission voting and a 30-second timer before anything risky executes unsupervised. Every session replays afterward, so when something breaks you get a record of exactly which agent made which change and why, not a guess. Forking and racing agents against the same task runs through isolated git worktrees, so testing three approaches never means three agents stepping on the same files at once. The permission and audit layer is where self-hosted agent infrastructure is actually heading, not just cheaper compute. github.com/stretchcloud/camp… xitter.cf/LLMpsycho/status/21145…