OpenAI VP of Application Infrastructure Venkataramani’s exact words in March 2026 were “there are easily 1,000x engineers now”; a July 2025 randomized controlled trial by METR found that AI tools increased task completion time by 19% for 16 senior open-source maintainers. In the same industry, in the same year, two claims separated by 50 orders of magnitude are both in circulation.

Which of these two numbers is right? Neither. They’re not operating on the same level. 1000x is rhetoric; -19% is a single experiment’s measurement on a specific cohort. The real issue isn’t “who do you believe” but that marketing has churned this industry’s conceptual framework into a slurry: AUI is being treated as a formal standard, Multi-Agent and Multi-Harness are used interchangeably, and outdated MCP tutorials are everywhere. This article performs a layered cleanup—each term gets its full English name, definition source, and boundary with adjacent concepts. All facts are dated (verified 2026-09-22), slang is labeled as slang, and standards are labeled as standards.

1. 100x/1000x: A Number That Was Never Measured

Start with the origin, because the origin is the problem.

The “10x programmer” originated from a 1968 CACM paper by Sackman, Erickson, and Grant. The original study compared batch processing versus online terminal programming, not individual programmer ability; the often-cited 28:1 ratio was simply the extreme difference between fastest and slowest. Critics in that same CACM issue noted high measurement uncertainty, and that much of the difference came from the technology used, not the people (deconstructed by Prechelt in 1999). “10x engineer” went viral from a July 2019 tweet by Accel investor Shekhar Kirani, describing someone who “uses an IDE, hates meetings, and codes late at night”—pure investor rhetoric. In 2025, Surge AI CEO Edwin Chen multiplied 2–3x coding speed × 2–3x harder work × 2–3x fewer distractions to reach 100x; in March 2026, OpenAI’s Venkataramani pushed it to 1000x. At no point along this transmission chain was an operational measurement definition provided.

What actually measured numbers look like:

Two rows in that table deserve a pause. The METR row is刺点 (the sore point): developers predicted a 24% speedup beforehand, still self-reported a 20% boost afterward, but the measurement was -19%. When self-report and measurement diverge in opposite directions, every “I feel faster” data point should be downweighted. METR’s follow-up experiment in February 2026 revealed a deeper issue: the 57-person study was compromised by selection bias—most optimistic AI users refused the no-AI condition, and 30–50% of participants admitted skipping tasks they didn’t want to do. The MIT row, meanwhile, is the largest rigorous experiment to date, concluding at +26%, or 1.26x.

Why is there a chasm between 1.26x and 100x? Because multiplier claims almost always stop at Layer 1, while delivery happens at Layer 4:

1. Code generation volume: tokens and lines. GitClear’s analysis of 211 million lines of changes showed copy-pasted code rose from 8.3% (2021) to 12.3% (2024), while refactoring-type changes dropped from ~25% to under 10%—generation volume growth and maintainability degradation are happening in lockstep.
2. Task throughput: PR count, task count. The second layer in the table above swings wildly from -19% to +55.8%, entirely depending on task difficulty and participant experience (novices benefit most; veterans actually slow down on their own familiar repos).
3. Post-verification delivery: merged code that isn’t rolled back. No study measures this layer directly; we only have proxy metrics—Uplevel’s +41% bugs, Stack Overflow’s 2025 survey where 66% of developers said “AI solutions are almost right but not quite,” costing more time to fix, and GitClear’s churn data.
4. Business value: revenue, users, retention. Zero measurements.

Simon Willison’s August 2025 self-assessment is a rare honest sample in this space: “LLMs make me 2–5x more productive on the parts of my job which involve typing code into a computer”—a 2–5x limit bounded to the coding portion. As of 2026-09, all peer-reviewed or auditable measured gains cap out around 2.5x. 1000x has zero empirical support; its actual function is to redefine “engineer” as “an orchestrator of many agents,” then discuss leverage in terms of the orchestrator—but OpenAI’s own same-interview remarks acknowledged that verification stages like code review, security audits, and CI/CD scaling did not speed up.

Author-proposed measurement framework (this is built here, not an industry standard): before discussing multipliers, nail down four things—what’s the baseline, which layer’s output is being measured, how are error rates and rework counted, and does verification cost enter the denominator. Any multiplier that can’t answer these gets treated as marketing.

2. Interface Layer: GUI, CLI, TUI, Web UI, AUI, VUI

This group is the easiest to clarify and the most easily muddied. First, draw the boundaries:

The first five have stable, widely accepted definitions. A Wikipedia-level anchor suffices. Two common mistakes: TUI is not a subclass of CLI—CLI is a line-by-line I/O stream; TUI takes over the whole screen to draw windows and menus. Wikipedia’s TUI entry explicitly states “Not to be confused with Command-line interface”; htop is TUI, ps is CLI. Web UI is not a fourth independent type alongside GUI—strictly speaking, it’s a “GUI implemented with the web tech stack and rendered through a browser,” with its boundary anchored in the browser+HTTP distribution mechanism.

AUI is the only abbreviation in this set without a formal standard, with at least four parallel usages: since 2025, the AI circle has used it to mean Agentic UI / Agent User Interface (the interface layer that lets agents execute tasks inside apps, per Salesforce and various design studios); HCI academia uses it for Adaptive User Interface; accessibility circles use Audio/Audible User Interface; and some papers expand it to Agent-friendly UI (interfaces optimized for agents rather than human eyes, e.g., NUS Show Lab’s AUI-Gym benchmark). Neither Anthropic nor OpenAI uses “AUI” in official texts: Anthropic’s Building Effective Agents (2024-12) uses ACI (agent-computer interface)—the tool interface given to agents should be designed as seriously as HCI; the MCP official ecosystem uses “agentic app” and MCP Apps (SEP-1865 extension proposal, released 2025-11, co-authored by OpenAI and Anthropic employees, enabling MCP servers to expose interactive UIs to host applications). Another adjacent concept is the AG-UI protocol (an open-source event protocol from CopilotKit). Writing advice in Chinese: always expand the full name on first use; writing just “AUI” is equivalent to writing nothing.

Why agent engineering favors text interfaces? This intuition has empirical backing. arXiv 2609.11999, Is Bash All You Need?, compared five tool-interface modalities on enterprise benchmarks and found that using bash only outperformed typed interfaces by 21.8–24.5 percentage points, while also saving 19–72% in tokens (note: single-study conclusion; the paper itself notes security/compliance scenarios require fixed tool directories). The structural reason follows from the definition of CLI: text output is grep-able, pipable, structurally parsable, and fully loggable for audit; GUI for agents means pixel-level recognition and non-composable click streams—exactly the phrasing in Wikipedia’s GUI entry: “icons and dialog boxes are usually harder for users to script.” This is why the five leading coding agents—Claude Code, Codex CLI, Gemini CLI, Aider, and OpenCode—all live inside terminals.

3. Protocol Layer: API, SDK, MCP

Three words governing three things: API is the service itself, SDK is the engineering wrapper around the API, and MCP is the protocol standard for tool connectivity.

API (Application Programming Interface): in the LLM context, this refers to the HTTP interface exposed by model providers. Take Anthropic’s Messages API: POST /v1/messages, required fields model, max_tokens, messages (alternating user/assistant turns), optional system, tools, stream. Two details critical to what follows: APIs are stateless—full conversation history must be resent every turn (this is where the cost model comes from, see Section 6); tool calling is protocol-level standardized—the client sends a tools parameter, the model returns a tool_use content block with stop_reason: "tool_use", the client executes and feeds the tool_result block (with tool_use_id) into the next message, looping until end_turn.

SDK (Software Development Kit) is a typed convenience layer on top of the API; it provides no new capabilities beyond the API. Take anthropic-sdk-python (v1.7.0, 2026-09-18): request parameters are TypedDict, responses are Pydantic models; automatic retries default to 2x with exponential backoff, covering 429/5xx; streaming assistants via messages.stream(); pre-request token counting; typed exceptions. A heuristic for distinguishing API vs. SDK: what the model can do is determined by the API and the model; an SDK upgrade is an engineering-interface change, not a capability change.

MCP (Model Context Protocol): an open-source tool-connectivity protocol from Anthropic (November 2024), donated in December 2025 to the Agentic AI Foundation (AAIF) under the Linux Foundation. As of 2026-09:

• Built on JSON-RPC 2.0; architecture is host-client-server: one host application manages multiple clients, each client communicating one-to-one with one server.
• Servers expose capabilities through three primitives: tools, resources, prompts. Terminology precision matters: hosts/clients/servers are architectural roles; tools/resources/prompts are primitives. Conflating them is wrong.
• Two transports: stdio (local subprocess) and Streamable HTTP (remote endpoint). Legacy HTTP+SSE transport was superseded in the 2025-03-26 revision and is now deprecated.
• Latest version is 2026-07-28, a structural overhaul: the protocol became stateless (removed the initialize handshake and session headers), added multi-round-trip requests (MRTR), allowed caching of list results, hardened OAuth, and moved roots/sampling to deprecation.
• OpenAI (March 2025) and Google (April 2025) announced adoption; AAIF’s September 2026 position: Tier 1 SDK monthly downloads approach 500M; over 10,000 MCP servers published.

MCP and function calling are not competing. MCP governs tool discovery, connectivity, and transport; whether and how the model invokes them relies on each provider’s tool-calling capability—the MCP official docs define tools as “model-controlled.” A model that doesn’t support tool calling can’t use an MCP server even if connected. The community phrase “MCP reduces the M×N integration problem to M+N” is common parlance; the spec supports the direction but doesn’t use that exact quantification.

Why MCP citations must include version dates: MCP has undergone major behavioral revisions at 2025-03-26, 2025-06-18, 2025-11-25, and 2026-07-28 since its initial 2024-11-05 release. Intervals are irregular, but each revision changes behavior. The initialize handshake, Mcp-Session-Id, and stateful sessions described in 2025 MCP tutorials no longer exist in the current spec—citing secondary sources will almost guarantee staleness. The facts in this section are sourced directly from the GitHub repo’s main branch spec as of 2026-07-28.

4. Execution Layer: Agent, Harness, Multi-Agent, Multi-Harness, Multi-Vendor

This section is a minefield because Harness has no official standard definition;各家用法相近但不是同一份规范. The best approach is to lay out each provider’s phrasing side-by-side and then clarify where semantic drift occurs.

Agent. The most-cited industry definition anchor is Anthropic’s Building Effective Agents (2024-12-19) dichotomy: Workflows are “systems where an LLM and tools are orchestrated through predefined code paths”; Agents are “systems where the LLM dynamically directs its own process and tool usage.” One-liner: an agent is typically an LLM using tools in a loop based on environmental feedback. Simon Willison’s version is “LLMs calling tools in a loop to achieve a goal”; he also criticized OpenAI’s overly broad definition (“a system that can do work independently on behalf of the user”) for muddying the waters. Note: there is no cross-vendor standard for “agent,” so debates over “is XX a real agent” are almost always definitional arguments.

Harness. This term only entered official texts in high frequency in late 2025. Three representative usages:

• LangChain’s The Anatomy of an Agent Harness (2026-03) gives the bluntest formula: “Agent = Model + Harness”, “If you’re not the model, you’re the harness”—the harness is everything outside the model: system prompts, toolsets, MCP, sandboxes, orchestration logic, hooks, context compression.
• Anthropic’s Effective harnesses for long-running agents (2025-11): “The Claude Agent SDK is a powerful, general-purpose agent harness”—system prompt + toolset + context management, letting the loop span multiple context windows.
• Anthropic’s documentation on Claude Code’s positioning: “Claude Code serves as the agentic harness around Claude: it provides the tools, context management, and execution environment that turn a language model into a capable coding agent.”

A semantic drift to watch: in A harness for every task (2026-06), Anthropic applied “harness” to the multi-agent orchestration layer as well—the same word now appears at two granularities: “single-agent execution shell” and “multi-agent orchestration layer.” When writing, anchor “harness” to a specific source. Concrete examples: Claude Code, Codex CLI (openai/codex, ~125.7k stars, 2026-09-21), Gemini CLI (~107.1k), Aider (~49.1k, an early provider-agnostic design representative), OpenCode (~209k, now maintained by anomalyco) are all coding-agent harnesses.

Then the three “Multi” terms: they are three distinct dimensions, not synonyms (this three-dimensional distinction is a framework I organized here, not an industry-consensus definition):