0918 | Less Code, More Agents

||Download

Show notes

From pruning products and running self-driving codebases to ternary models, an OS in V, a CrowdSec leak, centenarians in Japan, and CCC's next congress — a fast tour of what shipped, what broke, and what we still don't know.

Timeline

  • 00:00:04 Opening
  • 00:00:46 Do Less: The Case for Building Less
  • 00:05:14 Agents Get Portable and Accountable
  • 00:09:11 New Model Economics: Tiny Weights, Live Weights, Big Fleets
  • 00:12:10 Security: Leaks, Patching, and Rate Limits
  • 00:17:28 Proof, Prediction, and the Wider Tool Landscape
  • 00:20:44 People, Storage, and Congress
  • 00:23:25 Closing

Related links

This episode is produced by Bri. Bri uses advanced AI technology to turn the feeds you care about into podcasts made for listening. Contact us at hi@bri.so.

Transcript

Mia: Welcome back to the show, everyone. I'm Mia.

Milo: And I'm Milo. It's been a busy twenty-four hours on the Hacker News front page, and the thread running through almost everything today is restraint. Restraint in what you build, restraint in how big your models need to be, restraint in what you trust an agent to do without checking.

Mia: Yeah, there's a real through-line: a lot of the smartest takes today are people arguing that doing less, deliberately, beats doing more. That shows up in product advice, in model design, even in how people think about security. So let's just dive straight into the one that kicked off my morning.

Milo: The Liam Nugent quote. The most important product decision is what you don't build.

Mia: Right, and it's paired with a McGovern claim that's genuinely provocative: that cutting eighty to ninety percent of your content actually increases sales and lowers support burden. Now, if you hear that cold, it sounds absurd. You spent years producing that content. But the argument is actually pretty coherent once you sit with it.

Milo: The reasoning, as I understand it, is that most content isn't serving users — it's serving search engines, or it's serving the org chart of whoever produced it. And every extra page is a page that can be wrong, outdated, or contradictory with another page. That's where the support cost comes in. If a user finds two answers and one is stale, they don't blame the page, they blame the product, and they file a ticket.

Mia: And the sales point follows from the same logic. A site with ninety percent less stuff is easier to navigate, the good pages rank better because they're not competing with filler, and the path to purchase has fewer places to lose someone. It's the same instinct behind the "do things that don't scale" era, honestly — attention is the scarce resource, and clutter is a tax on it.

Milo: What I found interesting in the discussion is that nobody was really disputing the direction of the claim. The fight was over the number. Eighty to ninety percent is easy to say from the outside. If you're the person who wrote three hundred of those pages, the framing lands very differently. Some people were basically saying: fine, but you have to decide what to cut, and that's the actual hard problem.

Mia: Which is exactly the open question here, and it's the one I want to sit on for a second. How do you decide? The sources don't give a formula, and I don't think one exists. But there's a reasonable heuristic in the air: cut anything you couldn't defend in a sentence about who it serves. If the answer is "SEO," or "the VP asked for it," that's a signal.

Milo: And the counterargument you always hear — "what about long-tail traffic?" — is worth naming. The response in the thread was essentially that long-tail traffic that never converts and never reads isn't traffic, it's server load. If McGovern's numbers hold even partially, the long tail was costing more than it earned.

Mia: Now here's the part that makes this more than a product anecdote. There's a blog post making the rounds about what the author calls "tokenmaxxing" — the disappointment of throwing ever more tokens at AI coding agents and expecting the codebase to just get better.

Milo: Yeah, and this connects beautifully. The essay's conclusion is that the primitives we have for what people are calling self-driving codebases just aren't there yet. More compute, more tokens, more agents — none of it substitutes for the thing that was always scarce: good ideas and good architecture.

Mia: So it's the same argument in a different costume. Nugent says the most important decision is what not to build. The tokenmaxxing piece says the most important input isn't volume of generation, it's the quality of the plan underneath. In both cases, more output is a way of avoiding the hard decision, and the hard decision is the valuable one.

Milo: And there's a lovely little supporting example in the mix. Someone rebuilt flat.social, a 3D spatial meeting app for the web, completely solo — Three.js for rendering, LiveKit for audio and video, Rapier for physics — bootstrapped, with a live demo. That's one person choosing a very narrow scope and shipping it. That's "what not to build" as a feature, not a limitation.

Mia: Exactly. He didn't build a metaverse platform. He built one good room. Okay, so here's our bridge — and it's a natural one. That "what not to build" logic is now showing up inside AI coding tools themselves, and specifically in how agents are being wired together.

Milo: So let's talk portability. There's a YC company called Skillsync, and their pitch is that AI-agent sessions — the full record: the chat, the reasoning, the tool calls — should be portable between agents. They built a Rust engine called txcript that ports sessions between Claude Code, Codex, and Cursor.

Mia: Why does that matter? Because right now your agent session is hostage to the tool you started it in. If you're two hours into a debugging session in one agent and you want to try another one, you start over. Skillsync is saying the session is the asset, not the agent. Chat, reasoning, tool calls — that's your context, and you should be able to carry it.

Milo: The discussion around this split in a predictable way. One camp said this is obviously the future — interoperability always wins eventually, and the agent layer is where the lock-in currently lives. The skeptical camp asked the obvious question: will session formats ever actually standardize? That's the unresolved question, and I want to be honest that it's unresolved.

Milo: If every vendor's internal representation is different in load-bearing ways, porting is lossy, and lossy porting might be worse than starting over.

Mia: And there's a deeper version of that objection: reasoning isn't just text. If one agent's internal reasoning format encodes things another agent can't use — or misinterprets — you're not porting a session, you're porting a translation. Whether that's good enough is exactly what nobody knows yet.

Milo: Second piece in this cluster: Cloudflare shipped something called security-audit-skill. It's a skill for coding agents that runs multi-phase security audits, and the notable part is that the findings come out verified and machine-readable.

Mia: The "machine-readable" part is doing a lot of work there. Security audits traditionally produce a PDF that a human triages. If the output is structured and verified, it can feed directly into the pipeline — tickets, CI checks, whatever. It's the difference between a report and an API.

Milo: And that pairs with a piece of thinking that I think is the sharpest idea in this whole space today: the argument that LLM classification is really feature engineering. The claim is that you shouldn't use an LLM's judgment as the final answer. You use it as a feature — one input among several — in something like logistic regression.

Mia: Explain why that's better, because it sounds like a downgrade.

Milo: It's the opposite. Because a raw LLM verdict is uncalibrated. It says "this looks suspicious" with no sense of how suspicious, no threshold you can tune, no way to explain to a stakeholder why the system flagged something. But if the LLM judgment is just one feature in a regression, you get calibration — you learn how much to weight it. You get thresholds you can set for your risk tolerance. And you get interpretability, because the model's coefficients tell you what mattered.

Mia: So Cloudflare's verified findings fit that mold — the agent produces signals, but there's a verification step that turns a vibe into a checked result. And Skillsync's portability fits the same story: the session isn't magic, it's data, and data can be audited, moved, and reasoned about. The theme is agents as infrastructure — infrastructure you can inspect.

Milo: Which raises the stakes, because as soon as agents are infrastructure, the security of the tools around them becomes critical. And that's our next thread.

Mia: CrowdSec confirmed a source-code leak in May 2026. The important reassurances: no customer data appears to be involved, and they rotated tokens. The suspected vector is a TanStack compromise — which, if that holds, is a supply-chain story, not a CrowdSec story. Somebody upstream got hit, and the blast radius traveled down the dependency chain.

Milo: That's the part that made people uneasy in the thread. You can do everything right in your own repo and still leak because a dependency's ecosystem got compromised. Supply-chain security isn't a checklist you complete; it's exposure you accept every time you install something.

Mia: Alongside that, GitLab.com announced that rate limits will follow your subscription tier starting October 19th, 2026, with anonymous access down to sixty requests an hour. And per the discussion, the driving reason is presumably LLM scraping — automated agents hammering public code at a scale that normal rate limiting can't distinguish from legitimate use.

Milo: And here you can feel the pressure this creates. Rate limits punish the scraper, but they also punish the anonymous researcher, the student, the person doing legitimate one-off analysis. The open question people were asking: does this actually stop the scraping, or does it just push it to mirrors, proxies, and other platforms? Limits are a tax on the honest as much as the dishonest, unless the honest can authenticate — which is exactly what the subscription tier is.

Mia: Which brings us to the netmeister essay, and I want to give this real time because it reframes the whole security conversation. The argument: the actual bottleneck in security isn't finding vulnerabilities. It's patching.

Milo: And once you say it out loud, it's obviously right. We have more scanners, more fuzzers, more AI-assisted bug finding than at any point in history. And yet the same classes of bugs keep getting exploited, because the bug was known and the patch sat unapplied for months. Adding another discovery engine doesn't move the needle if the fixing pipeline is the constraint.

Mia: It also quietly indicts the AI-security hype cycle. If the pitch is "our model finds more vulnerabilities," the netmeister response is: finding was never the scarce resource. The scarce resources are maintenance windows, owner accountability, and the organizational will to ship the fix.

Milo: And notice — Cloudflare's machine-readable audit findings suddenly look even smarter in this light. If finding is cheap, the value is in making findings actionable and verified, so they flow into the patching pipeline instead of piling up in a queue.

Mia: Okay. Next cluster: model economics. Three different attacks on the same cost problem, and they're all interesting.

Milo: First, PrismML's Ternary Bonsai 2, a 27-billion-parameter model with ternary weights. The headline numbers: it fits in 5.9 gigabytes, hits 98.2 percent of Qwen3.8-27B's benchmarks, supports 262K context, and it's Apache 2.0.

Mia: Let's unpack why ternary weights matter, because the size is the tell. Ternary means each weight is one of three values — roughly minus one, zero, plus one. No expensive multiplications in the normal sense, dramatically less memory. A 27B model in under six gigabytes is the kind of thing that runs on hardware people actually own, not a data center.

Milo: And the license matters as much as the size. Apache 2.0 means anyone can take it, fine-tune it, ship it. The discussion around this was mostly "wait, really, 98.2 percent?" — which is the right skepticism. Benchmark parity at a fraction of the size is a big claim, and real-world performance on your specific workload is the only test that counts.

Mia: Second attack: a paper on arXiv — 2609.18842 — proposing an infinite-parameter LLM. Instead of fixed weights, a hypernetwork generates the weights live, from interaction data, using Bayesian online updates.

Milo: Which is a genuinely different worldview. Normal models are frozen at deployment and learn nothing until the next training run. Here, the model's parameters are a function of what's happening right now. The upside is adaptability — no retraining cycles. The unknown, and this is the big one, is reliability. Live-generated weights mean your model's behavior can drift with your data stream, and if the updates go wrong, you don't have a checkpoint to roll back to in the usual sense.

Milo: Everyone agreed the idea is fascinating; nobody could tell you how it behaves in production.

Mia: Third attack: retrieval and scale. OpenAI's Astra for Law pairs GPT-6 with a legal search index of 230 million URLs, and it scored 54.0 percent versus 38.7 percent on the Vals AI legal-research benchmark.

Milo: Look at that gap — fifteen and a half points on a benchmark where legal researchers themselves score around the 38 mark, presumably. The lesson is that a big chunk of that gain probably isn't the model getting smarter; it's the model getting better material. Grounding in a good index turns open-ended generation into lookup plus reasoning, and lookup is more reliable.

Mia: And then there's the scale end of the spectrum: GLM running production inference on over a hundred thousand Chinese accelerators, with three times the throughput, and — this is the detail that got people talking — a large share of the infrastructure work was done by their own GLM-5.3 Infra Agent.

Milo: An agent writing the infra that serves the agent. People found that almost poetic. But it also connects back to our first topic: the agent succeeded there because the task had good architecture and clear constraints. It's not tokenmaxxing; it's a well-scoped problem.

Mia: Two side notes in this cluster. The Economist reports that AI now beats some of the best human forecasters — though the discussion was skeptical about how new that actually is, since superforecasting benchmarks have been inching this way for a while. And separately, Timothy Gowers — Fields Medalist — wrote about why he did not sign the letter from medalists against mass-produced LLM proofs, even though he agrees the underlying crisis is real.

Milo: The Gowers piece is worth dwelling on because it's an argument about strategy, not about whether there's a problem. His position, as I read it, is that agreeing there's a crisis doesn't obligate you to endorse a particular letter, and that a public signature has consequences he weighed carefully. It's a rare example of someone declining to join a bandwagon they ideologically agree with, and the discussion treated it as a lesson in how public statements get made — and unmade.

Mia: So: tiny weights, live weights, and retrieval plus fleets. Three different bets on the same question — how do you get capable AI without paying for capability you don't use. And that question about what you pay for leads straight into our last big cluster, because the most interesting stuff today wasn't at the frontier labs at all.

Milo: Let's do the tool roundup, but properly, not as a list — each of these says something.

Mia: Vinix first. A modern operating system written in V, that runs on 100 megabytes of RAM and 1 gigabyte of disk, supports Apple Silicon M1, and — this is the kicker — runs Alpine Linux binaries natively, without a VM or emulation.

Milo: Native binary compatibility is the hard part. Anyone can write a toy kernel. Making real Alpine binaries just work means you've implemented enough of the Linux syscall surface that existing software doesn't know the difference. That's years of unglamorous work.

Mia: Then Flet 1.0 — cross-platform apps for six platforms in pure Python, over 150 controls, built on Flutter, with the web version running via Pyodide and WebAssembly.

Milo: The pitch to Python developers is obvious: you already know Python; now you can ship to mobile and desktop without learning Swift or Kotlin. The skeptic take is always "Flutter under the hood means you're debugging someone else's abstraction," but for the huge population of Python-only teams, one language across six targets is a real unlock.

Mia: Manticore Search added built-in auto-chunking — five strategies, applied automatically at insert time. On their own manual as a test corpus, recall at 5 jumped from 55 percent to 83 percent.

Milo: That's a twenty-eight-point jump from making the default the right thing. Chunking is the unglamorous step in every retrieval pipeline, and most people chunk badly because it's fiddly. Baking five sensible strategies into the database means the median user gets the good pipeline for free. Very "do less" — the user does less, and gets more.

Mia: Hister is a private search engine over the pages you've visited and your own files, with a browser extension and an MCP server, sitting at 3.8 thousand stars on GitHub.

Milo: The MCP server part is quietly significant. It means your personal history becomes a tool an agent can query — "where did I read that thing last week" becomes a searchable index you own, on your machine, not in someone's ad-targeting database. Given everything we said earlier about agents as inspectable infrastructure, a local, private index feeding your agents is a very healthy pattern.

Mia: And flat.social we already mentioned — the solo-built 3D meeting app. I want to hold it up next to the big-budget stuff and just note the contrast: one person, three well-chosen libraries, a live demo. The frontier isn't only the frontier labs.

Milo: Which is basically the thesis of this whole segment. The tools that changed my week weren't the ones with billion-parameter press releases. They were the database that chunks for me, the OS that fits in a hundred megabytes, the search engine that stays on my disk.

Mia: Alright, last segment — and it's the human one. Three stories that sound unrelated but rhyme.

Milo: Japan has, for the first time, more than a hundred thousand centenarians: 107,677 of them, and 88 percent are women. The staggering detail in the discussion: a 2010 audit found about 230,000 registered people over 100 whose whereabouts couldn't be confirmed — records kept alive, in some cases literally, by families who didn't report deaths, sometimes to keep collecting pension payments.

Mia: So the number is both a triumph — actual people living past 100 in record numbers — and an audit lesson. And it rhymes with everything we've said today: a data system that nobody re-verifies accumulates fiction. Whether it's centenarian registries or content farms, unverified accumulation drifts from reality.

Milo: Then the self-storage story. The US holds roughly ninety percent of the world's self-storage capacity, over forty billion dollars a year in revenue, with more locations than a list of major fast-food chains you'd recognize.

Mia: Ninety percent of the world's storage capacity is in one country. And the read in the piece is that it's a physical mirror of the overconsumption problem — we buy more than our homes hold, and then we pay monthly rent on the overflow. It's the anti-restraint story. It's what happens when "what not to build" never gets asked about a whole economy's stuff.

Milo: And the contrast with our first topic is almost too neat. Nugent says cut eighty to ninety percent of your content. The storage industry says: keep everything, and build warehouses for it. Two visions of dealing with abundance, and one of them is clearly winning in square footage.

Mia: Finally, the Chaos Communication Club — CCC — has opened the call for participation for 40C3, "Model Citizens," December 27th to 30th, 2026, in Hamburg.

Milo: If any of this episode resonated — the security supply chain, the AI proofs debate, agents as infrastructure — that congress is where a lot of those arguments actually get had, in person, by the people doing the work. CFP is open now, so if you've got a talk in you, the deadline won't wait.

Mia: So let's tie the bow. Today's stories kept circling one idea: the scarce resource isn't capacity. It's judgment. What to cut, what to verify, what to patch, what to keep on your own disk.

Milo: And the unresolved questions are the honest ones. How do you actually decide what to cut? Will agent sessions standardize? Do live-generated weights survive contact with production? Do rate limits move scrapers or just move them somewhere worse?

Mia: No answers today, but better questions. Thanks for listening — we'll be back tomorrow with whatever the internet decided to argue about overnight.

Milo: See you then.