Also wrong, gay marriage had 60% support before Obergefell v. Hodges.

And it's not actually necessary for it to exist at the API level. It's a pattern. Making it API-side is just an optimization.

To do it client-side: 1. Define a single tool, tool_search 2. List the names of your deferred tools in context (or tool_search's description) 3. When tool_search is called, match the query against the tool names (or names + descriptions) 4. Append the matched tool def to the context in a new -esque tag

Claude Code (as of the leak) does this client side. You can even see the custom matching function and A/B tests about whether to include the descriptions.

Whether or not that tool definition comes from MCP or a local definition is kind of beside the point.

Its crazy that people are still discussing this. It's ancient history. Deferred tool loading, large contexts, and prompt caching have made 2026 completely different from 2025.

Also, the "CLI saves token" debate really falls apart when step one of using the CLI is running "--help". The problem remains: if knowing how to call the thing isn't in parametric memory, it has to be in context.

And then, one day, the politicians started saying it...

EVERYONE (engineers, pms, managers, sales) uses Claude Code to read and write Google Docs (google workspace mcp). Ideas, designs, reports. It's too much for one person to read and, with a distributed async team, there's an endless demand for more.

So for every project there's always one super Google Doc with 50 tabs and everyone just points their claude code at it to answer questions. It's not to be read by a human, it's just context for the agent.

Gemma-4 26B-A4B + M5 MacBook Pro + OpenCode isn't Claude Code _yet_, but it's good enough that if I were forced to use it I would be fine.

At this point I just want a decent Helix-Evil-Mode.

Phase 1: Download the student's code from their submitted github repo URL and run a series of extractions defined as skills. Did they include a README.md? What few-shot examples they provided in their prompt? Save all of it to a JSON blob.

Phase 2: Generate a series of probe queries for their agent based on it's system prompt and run the agent locally testing it with the probes. Save the queries and results to the JSON blob.

Phase 3: For anything subjective, surface the extraction/results to the grader (TA), ask them to grade them 1-5.

The final rubric is 50% objective and 50% subjective but it's all driven by the agent.

It's just "Thou shalt not grow a brain in a test tube and force it to play a 1993 shooter" didn't make any sense to Moses and therefore didn't make the editors cut.

There's also just that weird thing where they're obsessed with emoji which I've always assumed is because they're the only logograms in english and therefore have a lot of weight per byte.

But I think the future of programming is english.

Agent frameworks are converging on a small set of core concepts: prompts, tools, RAG, agent-as-tool, agent handoff, and state/runcontext (an LLM-invisible KV store for sharing state across tools, sub-agents, and prompt templates).

These primitives, by themselves, can cover most low-UX application business use cases. And once your tooling can be one-shotted by a coding agent, you stop writing code entirely. The job becomes naming, describing, and instructing and then wiring those pieces together with something more akin to flow-chart programming.

So I think for most application development, the kind where you're solving a specific business problem, code stops being the relevant abstraction. Even Claude Code will feel too low-level for the median developer.

The next IDE looks like Google Docs.

Even at 9 years old, I don't see myself upgrading in the foreseeable future.

But yeah, a concrete example is playwright-mcp vs playwright-cli: https://testcollab.com/blog/playwright-cli