# Your Framework's Most Important User Never Read the Docs > Source: > Published: 2026-09-25 16:41:10+00:00 For two decades we optimized software for the humans who would read it, and that was the only audience worth designing for. Three things this week suggest it has quietly stopped being the only one. ## 1. Rails Published a Landing Page Aimed at Something That Cannot Sign Up Rails now has [a page making the case that it is a good framework for coding agents](https://rubyonrails.org/ai). The pitch has four legs: convention over configuration gives an agent a map, so generated changes land in the right files with less prompting; Ruby's density means fewer tokens per feature, leaving more context for the problem; decades of public Rails code give models a strong signal for controllers, jobs, migrations and the glue between them; and the one-person framework plus an agent lets a solo builder cover more surface area. Underneath the pitch is a benchmark suite, which is the genuinely new part. Two evaluations through one harness: 21 atomic tasks that each turn on a single Rails API, and 20 feature-sized tickets on a real kanban app, written the way a product manager would file them. Every model ran every task three times at default effort and again at maximum, capped at 90 minutes, 400 steps and $60 per run, scored on hidden checks as well as the app's own suite. A framework shipping a model leaderboard for itself was not a genre a year ago. The argument that lands is the boring one. Token efficiency and training-data density are now framework properties, the same way startup time is. Conventions were sold for twenty years as a way to onboard humans; the same property now makes an agent's diff predictable, which makes human review cheap, which is where most of the remaining cost sits. And it compounds: a popular stack has more public code, which yields better generated output, which attracts more projects. **Why it matters:** - **For ICs:** when you evaluate a library, add a criterion — how much good public code exists for it. A niche framework now costs agent throughput, not just Stack Overflow answers. - **For leaders:** "the models are fluent in it" is a legitimate input to a stack decision, and a quiet argument against the bespoke internal framework nobody outside your company trained on. - **For founders:** if you sell developer infrastructure, your docs are no longer the front door. Being legible to a model is distribution. ## 2. Half of Vercel's Deployments Are Now Triggered by Something That Isn't a Person The adoption numbers are further along than the discourse. [One industry analysis](https://redmonk.com/sogrady/2026/09/16/new-new-kingmakers/) collects them: Vercel reported under three percent of deployments were agent-triggered in January, and more than half by June. Netlify coined Agent Experience as the counterpart to developer experience. Shopify, after six years on React Native because native apps were too slow to build, is moving back to native per platform — agents changed the arithmetic. One sandbox vendor reported over a billion sandboxes launched. That sandbox category is the tell. Cloudflare, Daytona, Docker, E2B, Modal and now Vercel all sell into a market that would not exist without agents. Tooling built for humans assumed the user would stay within acceptable bounds of behavior. Tooling built for agents assumes the opposite, and sells autonomy plus containment as one product. The strategic consequence is the part worth sitting with. Developer relations meant persuading a large, diverse, opinionated population — slow, but it produced variety. Agent relations means influencing a number of models you can count on two hands. Fewer deciders means fewer total choices, and the popular option has more training material behind it, so incumbents gain advantage precisely as switching costs approach zero. Those opinions came from developers in the first place, which means today's consensus gets frozen and replayed. **Why it matters:** - **For ICs:** the technology choices you make now are the training data for the defaults you will be handed later. Idiomatic code is a vote. - **For leaders:** track what fraction of your deploys, PRs and tickets originate from an agent. That ratio leads every tooling and access decision you have coming. - **For founders:** if adoption depends on a human reading about your product, you are competing for the shrinking half of the funnel. ## 3. A Thousand Agents Is Not a Bigger Team. It's an Unscheduled Cluster. The evidence against "just add agents" is now quantitative. [A survey of the research](https://www.instacloud.com/blogs/a-million-agents-is-a-distributed-systems-problem) pulls together a 180-configuration study across five architectures and three model families: centralized coordination improved parallelizable work by up to 80.9%, while every multi-agent variant made strictly sequential reasoning worse, by 39% to 70%. Communication overhead ate the budget the task needed. Independent parallel agents amplified errors by 17.2 times; an orchestrator in front of them cut that to 4.4. A separate benchmark ran teams of 2 to 100 agents over 1,620 experiments and found them competent communicators and poor distributed reasoners, with the hardest tasks hitting zero success at 50 agents. So the shape of the task decides, and coordination is real work drawing on the same budget as the task. The research treating agents as processes is converging on the obvious answer: an agent runtime shaped like an operating system — scheduler, context manager, memory and storage managers, access control — reported up to 2.1 times faster execution. Letting a scheduler pick the workflow per query, instead of running the heavy multi-agent path every time, cut tokens 43% and end-to-end latency 36% for at most a 1.4 point accuracy drop. The conclusion is that the agent should not be the durable thing. Goals, plans, decisions, pending tasks, ownership and checkpoints have to live outside any single worker, because workers get killed, run out of context and get rescheduled. The failures that hurt are the ones where the plan existed only inside a context window. **Why it matters:** - **For ICs:** before you fan out, ask whether the task is actually parallel. On sequential work, more agents is a measurable downgrade. - **For leaders:** budget orchestration and durable state as infrastructure, not glue. The error amplification numbers say the orchestrator pays for itself. - **For founders:** the agent runtime layer — scheduling, checkpointing, handoff, backpressure — is an open category with real benchmarks behind it. - The thread across all three: every layer of the stack is acquiring a second user, and that user does not read, does not tire, and does not forgive an ambiguous convention. ## The Verdict: Real or Hype? **Frameworks optimizing for model legibility → Real.** When a framework ships its own model leaderboard, the positioning war has already moved. **Agent relations replacing developer relations → Real but unevenly distributed.** Half of one platform's deploys, near zero at most companies — and the gap closes from the wrong end. **Fleets of agents as a distributed-systems discipline → Real but early.** The failure modes are measured and published; the runtime that handles them is still mostly blog posts.