I like the concept, but it seems like an obvious extension of where Anthropic is building with Tasks and Memory. What’s the moat? Cross-agent compatibility?

Personally I would be astonished if LLMs percolating through the global economy doesn’t give a 50bp bump from here on out.

Even if scaling hit a wall, commoditizing what we have now would do it. We have so much scaffolding and organizational overhang with the current models, it’s crazy.

Agreed. Applying the intelligence we already have more broadly will have a huge impact. That's been true for a while now, and it keeps getting more true as models keep getting better.

Right. Reader was not a case of apathy and failure to see the product’s value.

It was Google clearly seeing the product’s value, and killing it because that value was detrimental to their ads business.

So is this a model baked into the VLLM layer? Or a scaffold that the agent sits in for testing?

If the former then it’s relevant to the broader discourse on LLM generality. If the latter, then it seems less relevant to chatbots and business agents.

Edit to add: this is not part of the model, it’s in a separate pillar (Simulator vs Driver). More at https://waymo.com/blog/2025/12/demonstrably-safe-ai-for-auto....

This may be true pre-LLMs, but I think you need to account for the baseline build-vs-buy tradeoff shifting.

Companies in most cases don’t want to build SaaS because it is expensive to hire engineers to do it, not because they are allergic to owning teams.

If in-housing becomes substantially cheaper than the alternatives then companies will adapt.

But even if the new equilibrium is to hire a contract dev shop to build something custom to keep avoiding responsibility, this would have the same impact on SaaS.

So I’m pretty skeptical of this first-principles prediction expressing right level of uncertainty.

You’re forgetting the companies that already had developers.

Whose job had been maintaining a single internal system but had never had the bandwidth to expand their focus.

Companies like that are the ones spending millions a year for large one size fits all SaaS products.

The same cost savings could be captured by SaaS. Potentially not by incumbents, but by up and comers.

If you can spend $10K/year to keep your in house one alive but $5K/year on the new SaaS option, you stop building your own again.

Possibly, but I don’t think it’s certain. For a SaaS to capture, you’d need a forward deployed engineer model. And then I would have ten different FDEs to liaise with, none of whom know my domain.

Vs if I contract a shop, then I have a dedicated team ramped up on my domain who then can vet infra providers and choose the best tech. So potentially still some SaaS, but probably shifting more to PaaS.

Similar to how you don’t hire your Salesforce or SAP contractors from these companies, I would predict this model spreads to other platforms too, and may make OSS viable in more places.

I think with a SaaS you're trading user research and workflow design for a certain lack of customization, and that for 90% of businesses that will remain the right call. (And for the ones where it's not the right call, I think the contractor model also makes more sense than in-house LLM-generated-user-tool teams. That's a lot of code to pile up under a very small team for long-term maintenance. Yeah, "the agents can do it," but you're making ever-more balls that the people overseeing the agents will have to juggle over time.)

If you're selling honey online, say, how bespoke does your inventory management tool really need to be? And are there no lessons you'd learn from a SaaS tool that you'd not have thought of on your own?

I could believe that SMB SaaS doesn’t change much, but the vast majority of revenue is from enterprise.

I think enterprise SaaS is where you’ll see big changes.

> AI-native. No installation wizard; Claude Code guides setup. No monitoring dashboard; ask Claude what's happening. No debugging tools; describe the problem, Claude fixes it.

> Skills over features. Contributors shouldn't add features (e.g. support for Telegram) to the codebase. Instead, they contribute claude code skills like /add-telegram that transform your fork.

I’m interested to see how this model pans out. I can see benefits (don’t carry complexity you don’t need) and costs (how do I audit the generated code?).

But it seems pretty clear that things will move in this direction in ‘26 with all the vibe coding that folks are enjoying.

I do wonder if the end state is more like a very rich library of composable high-order abstractions, with Skills for how to use them - rather than raw skills with instructions for how to lossily reconstruct those things.

I think the more interesting question is were tools the right abstraction. What is the implication of having only a single "shell" tool. Should the infinite possibilities to few happen by the AI having limited tools or should whatever the shell calls have the limitations applied there. Tools in a way are redundant.

I think it’s pretty easy to write a law that doesn’t include email and sms. They have no engagement algorithms.

Forums require a little more finesse - but a good starting point is distinguishing upvotes from personalized engagement-based algorithms.

Basically I don’t buy that your concern is a problem in practice.

Edited to add - here is the guidance for Australia’s law for reference: https://www.esafety.gov.au/about-us/industry-regulation/soci...

Don’t guess; just get your vitamin D levels tested. It’s $20, you can just buy it à la carte.

For some people even in sunny areas, 5000 IU might be needed to get you in-range. This is highly individual.

I’m confused by the “at last”, it’s been consistently covered on The Guardian:

iran site:theguardian.com

There is a narrative that has been floating around and it seems like a Russian psyop designed to sow discord (not accusing you of being a bot personally), “the lefties are friends with Iran and don’t complain about their attrocities”, which is objectively false.

Indeed if you look at independent aggregators the latest article on Iran is more “left leaning” reported: https://ground.news/article/at-least-6-126-people-killed-in-...

I think both can be true, no?

Multi-agent coordination is obviously what's next.

And, Gas Town itself might never amount to more than a proof-of-concept.

Personally I'd put my money on whatever Anthropic build to do this job, rather than a layer someone else builds atop CC.

Remember when code LLMs were just APIs, and folks were building their own coding scaffolds like Aider and Cursor? Then Claude Code steamrolled everyone; they win because they can do RL on the whole agentic scaffold.

Any multi-agent system will have the same properties, i.e. whatever traits (e.g. the GUPP) and tool expertise (e.g. using Beads) are required to effectively participate in a swarm will get RL'd into the coding model, and any attempts to build alternate scaffolds will hit impedance mismatches because they do not fit the shape of what was RL'd (just like using non-CC UIs with Anthropic models gives you worse results than using the CC UI).

I say this with love - Yegge is putting forth some excellent ideas here. Beads seems like a great concept to add to CC ASAP; storing the TODO state in a repo would mean we don't need MCPs onto issue trackers. And figuring out what orchestration concepts are required will need a lot more trial and error, but these existence proofs are moving the frontier forward.