The Friction You Can’t See
You’ve felt it, even if you didn’t know the name: that weird lag when an AI agent tries to push code through a pipeline built for humans. The bot hesitates at the merge screen because there’s no obvious "submit" button, just a dropdown with eight ambiguous states. Or it fails a review gate because the approval flow expects three human sign-offs, but your agent’s policy says two.
Most enterprise software still operates like a human-first museum. Every interaction path assumes the visitor knows how to read body language, infer intent from silence, and navigate ambiguous UI labels based on context clues. Agents? They need explicit affordances, deterministic state transitions, and clear feedback loops.
GM’s key insight at VB Transform 2026 wasn’t just "AI works better when it’s less constrained." It was this: the bottleneck isn’t model capability. It’s the environment. If your agents can’t do their job end-to-end — from writing code through review to merge — you’ll keep seeing diminishing returns, no matter how many compute dollars you toss at foundation models. That 300% increase in merged pull requests wasn’t luck. It was elimination of human-shaped friction from the system.
So why do we keep designing for people first? Because it feels safer. We imagine we’re preserving quality control, when really we’re preserving inertia.
GM Flipped the Script — And So Did Its Metrics
Most teams approach AI integration backward: build the tool, then bolt an agent wrapper around it. GM did the reverse at VB Transform 2026: start with what an agent needs to operate, then redesign the human interfaces second. The outcome? A 300% rise in merged pull requests — a metric that matters because it measures the full loop, not just output volume.
Think about that number for a second. It’s not 10%, 50%. A threefold jump means the old system had agents hitting a wall more often than not. They could draft code, sure. But the handoffs, approvals, and feedback loops kept blocking them. Once GM rewired its software to treat AI as a first-class user, agents could complete tasks without human intermediaries. That’s the difference betweenAssistant mode and Agent-first mode.
This doesn’t require a massive AI rewrite across every legacy system overnight. It starts with one lane: maybe your pull request review flow, or your CI/CD trigger events. Define a clean, agent-friendly contract — deterministic status codes, no ambiguous "submit" buttons — and let the agent negotiate that contract end-to-end. Human reviewers step in only when the agent explicitly requests intervention, not because a rule arbitrary says it must.
GM’s talk underscores a dirty truth: if your agent can’t run full loops, you’re not shipping AI capability. You’re shipping automation theater.
That 300% Is a Diagnostic — Not a Goal
Here’s what most teams miss: the merged pull request spike isn’t the finish line. It’s a symptom check — proof that removing agent-specific friction unlocks otherwise invisible throughput.
Consider the steps an AI agent must complete to ship a PR:
- Draft code that passes local linting and unit tests
- Format diffs in a way humans can review without switching context
- Navigate merge conflicts and rebase strategies without human hand-holding
- Submit a changelog that matches your commit convention, not the agent’s internal log format
- Handle CI artifacts and approval gates that weren’t designed for autonomous agents
Each of those steps adds latency, each introduces a failure mode. GM’s team didn’t just speed up code generation — they removed the obstacles that made agents bounce off the track. Think of it like highway design: even a sports car won’t reach top speed in heavy traffic.
That’s why bolt-on agent wrappers often underperform. They’re trying to make a human-oriented API feel natural for machines, when what’s needed is an API built for agents — and then made human-readable as a secondary concern. The result? Tools that don’t force developers to context-switch when debugging agent failures, and which surface agent intent in human-friendly summaries.
The Hidden Cost of Human-First Tooling
Every tool you ship with human-only UX in mind carries a silent tax. That tax shows up as:
- Inconsistent agent outputs because the AI had to guess at ambiguous prompts or UI states
- Manual interventions that look like feature flags but are really workarounds for bad integration design
- Development slowness disguised as "quality gates" that just slow things down without adding safety
The irony is thick: we claim to automate development, yet keep tooling that makes agents second-class citizens. GM’s move at VB Transform 2026 was to treat AI agents like first-class developers — with dedicated lanes, clear signals, and deterministic feedback.
This has real implications for your roadmap:
- If an agent can’t reliably trigger a deploy without human help, your deployment pipeline isn’t autonomous.
- If code review suggestions require human rewriting to make sense, your review tool’s data model isn’t agent-compatible.
- If your CI logs confuse agents but not developers, your logging pipeline is human-first by default.
The fix isn’t training better agents. It’s designing the environment for them first, then making it legible to humans afterward.
What This Means for Your Team’s AIfuture
GM isn’t rewriting its entire codebase to make agents work. It’s rethinking a few high-leverage flows and measuring the outcome in merged PRs, not just lines of code written.
You don’t need a headline-grabbing keynote to begin. Start with one process:
- How does an agent request approval?
- How does it signal a block that needs human review?
- How does it surface a conflict without dumping raw git output on a developer?
Design those interactions first for the agent, then make them palatable to humans. That’s GM’s recipe, and it worked — a threefold increase in throughput proves it.
The future of enterprise AI isn’t smarter models. It’s software that doesn’t treat agents like clumsy tourists asking for directions in the dark. When the tools themselves are agent-native, humans get better outputs and agents stop hitting invisible walls.
It’s time to design for who will actually do the work — not just who used to.