So they built agentic skills. Good ones. Skills that automate creating features on the existing stack: scaffolding, wiring, testing, the whole delivery pipeline for the monolith as it stands today. And it worked. Features that took days now take hours. They were, understandably, proud of it.

That was the problem

They had spent their AI budget making horses faster in the age of electric cars. Every automated feature was a feature built the old way, on the old architecture, deepening the organization’s commitment to the thing that needs to change. The agents weren’t modernizing anything. They were pouring concrete around the legacy.

My proposal in that room: keep the feature-automation skills, but invest in a parallel track of agentic skills that expose the monolith’s functionality as APIs. Not because APIs are fashionable, but because APIs are what future agents, yours and your partners’, will build on. One track harvests the current stack. The other makes the stack harvestable.

I keep seeing this pattern, so it needs a name. Faster horses: using AI to accelerate what you already do, on the structure you already have, and calling it transformation.

Efficiency has a ceiling. Capability doesn’t.

The instinct behind faster horses is understandable, because it’s the instinct we’ve all been sold: use AI to be more efficient. But efficiency means doing what you already do, quicker. There’s a ceiling on that, and it’s low. You can only compress your current work so far, and everyone else is compressing theirs too. Efficiency gains are table stakes with a shelf life.

Capability is the other game. Not “how fast can I do my job” but “what can I do now that I couldn’t do before.” That has no ceiling, and it compounds.

Helen Edwards and the team at the Artificiality Institute have spent years researching what makes human work irreducible in the age of AI, asking not “will AI take our jobs” but “what is AI doing to us.” One of their findings deserves more attention than it gets: some of the most defensible human capability is physically situated. It lives in bodies, rooms, warehouses, and incident bridges. It never made it into any dataset, which means no model was ever trained on it.

The takeaway: if it was never digitized, AI can’t replace it. But AI can now help you act on it.

Intuition doesn’t compress into a dashboard

The canonical evidence is thirty years old and still underused. Gary Klein’s research on fireground commanders, 26 veterans with an average of 23 years of experience, probed across 156 real decisions and found that in fewer than 12% of decision points did commanders compare options at all. They recognized situations through accumulated exposure to patterns and acted. The famous case: a lieutenant pulls his crew out of a burning building seconds before the floor collapses. He couldn’t articulate why. Nothing in any data feed told him. Years of being there did.

Klein called it recognition-primed decision-making. I call it the asset your AI program is ignoring.

Here’s the loop that turns it into capability, in three moves.

Situate. Go where your data is born. If you run supply chains from a dashboard, spend a day in the warehouse and stay until you find the thing the dashboard doesn’t know: the workaround everyone uses, the rule nobody wrote down.

Prototype. This is where AI changes the equation. Describe the problem to a frontier model and build a rough tool the same week. It doesn’t have to be good; it has to be real enough that the people on the floor can tell you everything wrong with it. That feedback loop, where they poke holes and you fix and repeat, used to require a funded project and a quarter. Now it requires an afternoon and a coding agent.

Own. Take the validated fix up the chain. Not softened into options. “Here’s what I found, here’s what we should do, here’s why,” with your name on it. Being there becomes owning the decision.

The takeaway: AI can’t give you intuition. It can collapse the time between having it and acting on it, from a quarter to a day.

Three places the loop pays off in software delivery

I promised concrete examples. Here are three patterns with one vivid case each. You’ll recognize where the same shape appears in your own delivery organization.

Dashboard blindness. Your observability stack tells you what it was configured to measure. An engineering leader I know sat in on a week of on-call shifts, not reading postmortems but sitting in the incident channel live, and discovered that half the “15-minute resolutions” were actually one senior engineer’s private runbook of undocumented tribal knowledge. The metric looked healthy; the bus factor was one. The prototype: an agent that drafted runbook entries from incident transcripts, put in front of the on-call rotation for demolition and iteration. The same shape shows up in CI/CD metrics that hide flaky-test roulette, and in DORA numbers that look great because risky changes are quietly batched.

Undocumented workarounds. Every delivery process has a shadow version that actually ships the software. Watch a release manager for one afternoon, and you’ll find the spreadsheet, the Slack DM chain, the “we always ping Marta first” step that exists in no process doc. These workarounds are compressed knowledge about where the official process fails. Prototype the workaround into a tool, together with the people who invented it, and you’ve digitized capability instead of paving over it. Support escalation paths and security exception handling hide the same gold.

Decision distance. Product managers who haven’t watched a real user session in a quarter are running on secondhand reality. One PM I worked with spent two days in actual customer onboarding calls and caught a misunderstanding that no analytics funnel could express: users weren’t dropping off, they were succeeding at the wrong task. A prototype fix was in front of those same customers within the week. The roadmap debate that had run for a month ended in one demo.

The takeaway: the highest-leverage AI prototypes come from insights that were never in your data, which means someone has to go get them in person.

The executive version: parallel tracks or you’re decorating the legacy

For leaders whose IT capability is the business, in banking, logistics, retail, or healthcare operations, the fintech story from the top is the whole lesson in miniature.

Most enterprise “AI transformation” programs are efficiency programs wearing capability costumes. They automate existing workflows on existing systems and report the hours saved. The numbers are real. They are also faster horses: every automated workflow deepens the organization’s dependence on the architecture underneath it, and the architecture is precisely what limits what you can become.

The move that separates capability from decoration is running two tracks in parallel.

The first track is agentic automation of current workflows on the current stack. This funds itself and buys credibility. Do it, measure it, but don’t confuse it with transformation.

The second track is agentic work that exposes core functionality as APIs and well-described services. This is what lets future agents, your own, your partners’, your customers’, compose new things on top of your systems. In an agentic economy, the organizations that matter are the ones whose capabilities are addressable. A monolith with no API surface is invisible to that economy, no matter how fast its features ship.

And apply the situatedness test to your own program: if your AI strategy was written entirely from vendor decks and dashboards, it inherited their blind spots. The five most valuable days an executive sponsor can spend on an AI program are in the warehouse, the branch, the ops floor, finding what the systems don’t know before deciding what the agents should do.

The takeaway: the first track makes the horses faster. The second builds the road for electric cars. Fund both, and never report the first as the second.

The model math, July 2026, and why you’ll redo it in October

Concreteness cuts both ways: these numbers will age, and that aging is the final lesson.

As of this writing, the frontier tier for serious agentic coding, the prototype step of the loop, is led by models like Claude Opus 4.8 (around $5 input / $25 output per million tokens, 88.6% on SWE-bench Verified) and GPT-5.5 ($5/$30, 88.7%), with Gemini 3.1 Pro ($2/$12) as the value play in the frontier tier. This is where you want to be when the problem is messy: multi-file refactors, reasoning over half-structured field notes from your warehouse day, turning a fuzzy observation into a working prototype. Frontier models are expensive per token and cheap per discovery.

The open-weight tier has quietly crossed a threshold. Several open-weight and open-adjacent models now clear 80% on SWE-bench Verified at $0.60 to $2.40 per million output tokens, and DeepSeek’s V4 family sits as low as $0.14/$0.28. On an identical coding-agent workload, the spread between a frontier model and a budget open-weight one can reach roughly 48x. And if you sustain more than about 500K tokens per day, self-hosting open weights starts beating hosted APIs on cost, with the sovereignty and data-residency benefits that regulated industries care about anyway.

The smart pattern is not “pick the cheap one” or “pick the best one.” It’s this:

Frontier to discover, open-weight to operationalize. Use frontier models where ambiguity is high, and the task is novel: the prototyping loop, the gnarly refactor, the first version of anything. Once the insight is validated and the task becomes routine (classification, extraction, the internal tool that now runs every day), route it to an open-weight model at a fraction of the cost. Add caching (frontier providers bill cached reads at roughly 10% of input rates, and DeepSeek’s cache hits are near-free) and a simple router that escalates only the hard cases, and teams routinely cut inference bills by 60 to 80% without a quality cliff.

Then put a recurring event in your calendar: re-price per task, per model, every quarter. Not per month of spend. Per task. The unit that matters is “what does one validated prototype cost” and “what does one day of the routine workload cost.” Both numbers have moved by multiples in the last twelve months and will move again. A model choice made in January and never revisited is, by July, just another faster horse.

Prices and benchmarks checked July 2026 against published provider pricing and SWE-bench Verified leaderboards.

The takeaway: the specific numbers expire; the method doesn’t. Frontier to discover, open-weight to operationalize, re-price quarterly.

What survives

Twenty-plus years in this industry has taught me that tools change faster than judgment. The builders who survive each wave aren’t the ones who adopted the tools fastest. They’re the ones whose judgment about what to build was grounded in something the tools couldn’t see.

That’s what the capability loop protects. Intuition from being there. Prototypes fast enough to test it. Ownership loud enough to matter. AI doesn’t replace any of the three. It removes the excuse for skipping the middle one.

So, a challenge for this week: spend half a day where your dashboard’s data is born. The warehouse, the incident channel, the customer call. Come back with one thing the dashboard didn’t know. Then build the ugliest possible prototype and put it in front of the people who told you.

Don’t breed a faster horse. Go find out what the road actually needs.

With thanks to Helen Edwards and the Artificiality Institute, whose research on irreducible work and physical situatedness sparked this piece, and whose question “what is AI doing to us?” is the right one to keep asking.

And there are most likely many more like this in the wild.

This story is worth sitting with, because it’s not a failure of AI tooling. The tools worked exactly as designed. It’s a failure of cognitive posture, and it’s becoming the dominant failure mode of the current moment.

In the past year, I’ve built two serious products using Codex, Claude Code, and Cursor. And I can attest that the effort to keep things in check increases significantly when LOC exceeds 100K. Just some of that effort could be outsourced to more powerful models, such as Claude Fable 5, at a cost of (b)millions of tokens, but even that will not guarantee that it is doing the right thing for the project long term.
Let us step back for a moment and observe where we are and what to do about it all.

Acceleration and its asterisk

The numbers on AI’s impact on engineering throughput are real. The 2026 AI Engineering Report from Faros AI, based on two years of telemetry from 22,000 developers across 4,000 teams, found epics completed per developer up 66%, task throughput up 33.7%, and PR merge rate up 16.2%. More features shipped, more initiatives completed, faster cycles. Engineering leaders are right to want more of this.

But the same dataset carries a different set of numbers that rarely make the headline slide.

Code churn, the ratio of lines deleted to lines added, is up 861% under high AI adoption. The probability of a production incident per code change has risen 242.7%. Bugs per developer are up 54%. And 31.3% more code is merging into production with no review at all.

The report’s authors named this “the Acceleration Whiplash”: AI has flooded a system built around human-paced development with output it was never designed to absorb. Throughput is up. So are the hidden costs accumulating at every downstream stage.

Kent Beck, whose fingerprints are on more software development methodologies than almost anyone alive, put the current moment plainly: “When anyone can build anything, knowing what’s worth building becomes the skill.” The 2026 Thoughtworks Deer Valley gathering, attended by Beck, Martin Fowler, and roughly 50 senior engineering leaders, framed the same problem differently: cognitive debt is the new technical debt. When AI generates code nobody fully understands, you accumulate cognitive debt. And it compounds exactly like technical debt.

“Velocity without understanding is not sustainable.”

What you’re actually outsourcing

There is a clarifying distinction that gets lost in the AI productivity conversation: the difference between task execution and reasoning.

LLMs are extraordinarily good at task execution given sufficient context. Feed them your conventions, your domain model, your existing patterns, a clear specification, and they will generate code faster than any human team. This is genuinely valuable. This is the part worth accelerating.

Reasoning is different. Reasoning is: why does this component exist? What problem does this architecture solve, and what problems does it create? What happens to this system under load six months from now? Who is responsible when it fails?

LLMs do not reason in this sense. They pattern-match against an enormous corpus and produce plausible next tokens. They have no stake in the outcome. They cannot be paged at 2am. They will not be in the incident post-mortem. They cannot be responsible for anything, which means, if you’ve delegated the reasoning, you’ve made yourself responsible for decisions you didn’t make and don’t fully understand.

This is not a critique of the tools. It’s a structural fact about what they are.

The Reddit developer’s codebase wasn’t broken. It was a liability they didn’t know they’d taken on.

The spectrum of exposure

The stakes are not uniform across all use cases. A back-office utility processing internal data has a different risk profile than a B2B SaaS product with contractual SLAs. A solo side project has different exposure than a system handling financial transactions. The appropriate response to AI-assisted development scales accordingly.

If you’re building with a larger codebase, multiple domains, or multiple contributors:

Start with documentation, not of the code, but of the reasoning behind it. Your business rules. Regulatory constraints. Architectural principles. Domain boundaries. Not to satisfy a compliance checkbox, but because this is the context that separates purposeful generation from confident hallucination. The better you can articulate why your system is structured the way it is, the more your AI tooling behaves as an accelerator of your intent rather than a substitution for it. The model doesn’t know that you chose an event-sourced architecture for auditability reasons, or that a particular domain boundary exists because of a regulatory separation requirement. If you don’t tell it, it will invent something coherent that may contradict everything you’ve built.

On security and performance:

These are the areas where the accountability gap is sharpest. AI-generated code looks syntactically correct. It may pass your tests. It will not announce its own vulnerabilities, and it will not flag the n+1 query problem lurking in the generated data layer. The Opsera 2026 AI Coding Impact Benchmark (250,000+ developers) found senior engineers realise nearly five times the productivity gains of junior engineers from AI tooling, precisely because senior engineers apply judgment to the output. They know what to look for. They know what questions to ask. The tooling amplifies expertise; it doesn’t substitute for it.

On review and ownership:

The 31.3% of code merging without review isn’t a workflow problem. It’s a symptom of a posture problem, the implicit assumption that AI-generated code is somehow more trustworthy than human-written code, or that the velocity justifies skipping the check. It isn’t, and it doesn’t. Review isn’t about trust. It’s about comprehension. If you can’t explain what the code does and why it’s correct, you don’t own it.

Cognitive sovereignty is a practice, not a setting

The framing of “cognitive sovereignty” is not a call to write everything by hand or reject the tools. The tools are genuinely useful. Claude Code, Copilot, Gemini CLI, used well, they compound your capabilities. The question is whether you’re using them as amplifiers of your own reasoning, or as replacements for it.

The test is simple: can you explain every significant decision in your codebase? Not line by line, but at the level of: why this architecture, why this pattern, why this boundary? If there are large regions where the honest answer is “the AI generated it and it seemed fine,” you have cognitive debt. It may not surface immediately. It will surface.

The developer who deleted 70% of their project didn’t learn that AI tools are bad. They learned that outsourced reasoning has a bill that eventually arrives. Their two-week rewrite produced a codebase half the size, which they understood completely.

That’s not a cautionary tale about AI. It’s a story about what ownership actually costs, and what it’s worth.

What serious teams actually do differently

The Faros data makes one point starkly: there is no correlation, at the organisational level, between AI adoption and performance outcomes. High-AI teams can finish at the top or bottom of the distribution. What separates them is not tool selection. It’s taste, discipline, and ownership. Teams with strong foundations see AI compound their advantage. Teams without strong foundations see AI compound their dysfunction.

A few concrete practices that distinguish the former:

Specs before prompts. The quality of AI output is bounded by the quality of the specification fed to it. A vague prompt produces confident vagueness. Writing a good spec — stating what the component must do, what it must not do, what invariants it must maintain forces the reasoning that turns AI output from plausible to purposeful.

Tests as a verification layer, not an afterthought. Kent Beck’s argument for TDD in the AI era is pragmatic: unit tests are the most reliable way to prevent AI from introducing regressions. When the model generates code, the test suite is the closest thing you have to a specification check. This isn’t new advice. It’s newly urgent.

Architecture Decision Records before architecture changes. If you can’t write a three-paragraph ADR explaining why you’re making a structural change, you haven’t done the reasoning yet. Let the model write the first draft if you want, but the reasoning has to be yours before the change merges.

Don’t cut the senior engineers. The Faros report is explicit on this point. The code review bottleneck median time in review is up 441.5% under high AI adoption is not a sign that review is unnecessary. It’s a sign that the humans absorbing the quality gap from AI-generated code are the most experienced people on the team. Cutting them to realise the productivity gains from AI adoption is exactly the wrong response.

The tools are not the problem. Cognitive surrender is the problem. A machine can accelerate your work. It cannot be responsible for it. That responsibility still lives with you, which means the understanding has to live with you, too.

Accelerate. But stay behind the wheel.

Do you have some practices, advice, or tools that work for you to help with this problem? Please share in comments or reach out to me.

Sources: Faros AI Engineering Report 2026 (faros.ai/research/ai-acceleration-whiplash) · Opsera 2026 AI Coding Impact Benchmark · Thoughtworks Deer Valley Retreat, February 2026 · r/ChatGPT, u/Ambitious-Garbage-73
Kent Beck Post: https://www.linkedin.com/feed/update/urn:li:activity:7471011017670512640/

The software industry is obsessed with top-line numbers right now. We hear things like “3/4 of all code at Google is now written by AI,” and everyone immediately jumps to a flawed conclusion: Software engineering is becoming a pure game of prompting.

That is a dangerous illusion. If you treat AI like a magical slot machine where you just “vibe-code” your way to production, you aren’t accelerating your throughput—you are just compounding your cognitive debt at an unprecedented velocity.

As a pragmatic builder, my focus has always been on systems that actually work, scale, and survive in production. And after digesting recent internal data out of Google’s Developer Intelligence team, a fundamental truth has been validated: AI doesn’t erase the need for deep engineering; it aggressively penalizes the lack of it.

To survive and thrive as builders in this AI-native era, we have to evolve our roles. We aren’t code-monkeys, nor have we ever been that. We are builders, system architects, orchestrators, and value translators. We need to become T-Shaped Builders 2.0.

The Paradox of Vibe Coding

Google’s Dora team discovered a massive “productivity paradox.” While individual developers feel faster using AI extensions, team-level delivery can actually slow down. Why? Because writing unverified, context-deaf code into a shared repository creates massive evaluation bottlenecks and integration chaos.

AI is both a mirror and an amplifier. If your engineering practices, system designs, and team cultures are structured, AI magnifies your strength. If your infrastructure is fragile, data is siloed, and processes are broken, AI will just help you build catastrophic technical debt 10 times faster.

So how do we fix it? We focus on the system, not just the code.

       The AI-Native T-Shaped Developer Framework
  ┌──────────────────────────────────────────────────┐
  │         AI ENGAGEMENT & ORCHESTRATION            │ ◄── (New Core Horizontal Layer)
  ├────────────────────────┬─────────────────────────┤
  │ ADJACENT ENGINEERING   │ ADJACENT NON-ENGINEERING│ ◄── (Extended Wings: Context)
  │ (Infra, Sec, Ops)      │ (Business, Product, UX) │
  └───────────┬────────────┴─────────────────────────┘
              │  DEEP DOMAIN & CORE ENGINEERING      │ ◄── (The Stem: Precision & Verification)
              └──────────────────────────────────────┘

1. The Core Stem: Precision Engineering Over Intellectual Passivity

The horizontal bar of a traditional T-shaped engineer is expanding, but the stem—the deep, specialized engineering knowledge—has never been more critical.

When code is generated instantly, verification becomes your ultimate bottleneck. If you accept machine output wholesales because it “sounds confident,” you are practicing intellectual passivity. Pragmatic builders delegate tasks, never judgment.

How to stay sharp:

• Reimplementation loops: Don’t just accept the first draft. Force the AI to tear it down and rebuild it differently. Ask it to explain why it made alternate trade-offs.

• Trace walkthroughs: Spend time walking through agent decision traces or “alien code” (code you didn’t write) to keep your mental model of the system intact.

2. Shifting Left on Intent (Spec-Driven Development)

Traditionally, “shifting left” meant moving security or testing to an earlier stage in the pipeline. Today, shifting left means capturing structured intent.

The fundamental source of truth is moving away from the code itself and toward upfront specification files. If you let an agent workforce build without rigid specifications, you build a prototype nobody understands.

• The Spec is the Deliverable: Spend your cognitive energy upfront debating constraints, business logic, and user requirements. Treat your .spec or skill files like real code—versioned, observed, and fiercely protected.

3. Moving from Conductor to System Orchestrator

The era of chatting with a single AI companion is over. The future belongs to asynchronous multi-agent architectures.

Instead of asking one LLM to write a complex migration, modern teams build systems of reasoning. For instance, Google tackled delicate TensorFlow migrations by deploying a strict three-agent architecture:

1. A Planner Agent to map verifiable steps.

2. An Orchestrator Agent to group and route execution.

3. A Coder Agent to execute the changes within defined style guides.

As the human engineer, you sit above this loop. You build the environment, set the guardrails, and track agent performance traces.

4. Becoming a Value Translator

Since AI handles the routine execution of how to code, the pragmatic builder’s real value shifts up the abstraction stack to the what and the why.

When a product request asks to “improve database performance,” a weak prompt results in a generic refactor loop. A Value Translator looks at metrics, asks “Performance for which user segment under what context?” and guides the agent network to optimize the critical paths that move the business needle.

The Leadership Mandate: Protect the Struggle

If you are managing or leading teams, remember W. Edwards Deming’s classic phrase: “A bad system will beat a good person every time.” You cannot demand a 10x output if it means crushing your developers under 10x cognitive load and constant agent context-switching. To prevent burnout, leaders must make three immediate shifts:

1. Stop measuring lines of code or PR volume. (hope you never did that) Reward outcomes and met business requirements.

2. Protect the “productive struggle.” Carve out dedicated time for devs to whiteboard systems, audit infrastructure, and experiment with tooling.

3. Build absolute psychological safety. Agentic systems will fail. If your culture punishes failure, engineers will retreat to old, slow, safe ways of working.

Stepping Up, Not Stepping Aside

The craft of software engineering isn’t vanishing; it’s stepping up to its highest and most powerful altitude. We are moving from hand-crafting bricks to precision-engineering the ecosystem that safely allows buildings to exist.

Let’s stop vibe coding. Let’s start system designing.

What does your agent-orchestration stack look like today?
Do you have something worth sharing that works nicely for your team?

Drop your thoughts in the comments.

And just like that, the honeymoon seems to be over, and the money started flying — except this time, it’s yours.

I’ve been writing software professionally for over twenty years. I’ve watched the dot-com bubble inflate and burst, the mobile revolution, the cloud transition, the NoSQL hype cycle, the microservices gold rush. Each of those moments felt significant in its own way. But I’ll be honest — this one feels different. What’s happening right now in AI tooling is genuinely unprecedented. The pace, the stakes, the way it’s touching every layer of the stack simultaneously. And within that larger story, this week’s GitHub Copilot pricing announcement is a small but telling moment. A signal flare, not a firework.

The honeymoon was fun. Frontier model access for $10 a month, unlimited completions, agentic sessions running wild on your codebase. Nobody was really looking at the bill because the bill looked fine. It looked fine because someone else was quietly covering most of it. That era is ending now, and the transition is worth understanding clearly — not because it’s catastrophic, but because the builders who understand it earliest will make better decisions than those who don’t.

Let me explain what actually changed, why it matters more than the headlines suggest, and what you should concretely do about it if you’re a builder, an engineering lead, or someone running a small software business.

What GitHub actually announced

Starting June 1, 2026, all GitHub Copilot plans move from a flat request-based model to usage-based billing. The old system counted “premium request units” — each interaction with a premium model consumed some number of PRUs from your monthly allowance. The new system replaces PRUs with GitHub AI Credits, where 1 credit equals $0.01, and your usage is calculated based on actual token consumption: input tokens, output tokens, and cached tokens, priced at the published API rate for whichever model you used.

Plan prices are not changing on paper. Copilot Pro stays at $10/month, Pro+ at $39, Business at $19/user, Enterprise at $39/user. But here’s what is changing and what the headline writers mostly glossed over: each plan now includes a monthly credit allotment equal in dollar value to its price. So a Business subscriber paying $19/month gets $30 in pooled AI credits. When those credits are gone, you either buy more or you stop.

And critically — unlike the old system, where exhausting your PRUs would quietly fall back to a cheaper model and let you keep working — under the new model, there is no fallback. When the credits run out, the well is dry. For a lot of developers, Copilot has functioned as an always-available background tool, something you barely had to think about. That cognitive simplicity ends on June 1.

The math that makes this concrete

Abstract talk about “token-heavy workflows” doesn’t land until you put real numbers on it. So here they are.

Claude Opus 4.7 — one of the frontier models available in Copilot — costs $5 per million input tokens and $25 per million output tokens at published API rates. A moderately sized agentic session on a real codebase might consume 50,000 input tokens and 8,000 output tokens. That’s a single session costing roughly $0.45. If you’re a developer running five of those sessions a day, five days a week, you’ve burned through your entire monthly Business credit allotment in about a week. Then you’re buying more, switching to a cheaper model, or waiting until next month.

GPT-5.4, the other heavy hitter, charges $2.50 per million input tokens and $15 per million output. Still non-trivial at scale — and Copilot code review sessions and agentic workflows pile these costs up fast, often invisibly, because the tool is sending context you didn’t explicitly choose to include.

This is the part that the flat-rate model was hiding from you. Token-based billing doesn’t change the underlying cost of inference — it just makes the bill legible. In some ways, that’s actually healthy. But it does require you to start thinking about something most developers have never had to think about before: the economics of their own prompting habits.

Why this happened: the unit economics broke

GitHub’s own Chief Product Officer described this change as “an important step toward a sustainable, reliable Copilot business.” That word — sustainable — is the tell. Leaked internal documents earlier this month revealed that the week-over-week cost of running GitHub Copilot had nearly doubled since January 2026. Doubled. In four months.

The culprit is agentic usage. When Copilot was primarily an autocomplete tool, the token math was manageable. When it became an agentic platform — running multi-step coding sessions, reviewing entire pull requests, spinning up cloud agents that hold large context windows open for extended periods — the cost per user exploded. GitHub paused new individual plan signups on April 20th, framing it as investigating “high abuse through trials.” The real explanation is that the flat-rate model became financially unviable under agentic load, and they needed to stop the bleeding before fixing the model.

This isn’t unique to GitHub. Anthropic made similar moves with Claude Code. OpenAI moved Codex to token-based credits. The whole industry ran the same experiment — subsidized flat-rate access to frontier models to drive adoption — and the whole industry hit the same wall at roughly the same time. IDC has forecast that large enterprises will underestimate their AI infrastructure costs by 30% through 2027. That gap is going to be expressed through pricing changes exactly like this one, from every major vendor, over the next 18 months. GitHub is just the most visible domino to fall this week.

How the developer community actually reacted

The GitHub community discussion thread is worth reading in full because it’s more honest than most analysis. One developer wrote: “This is removing the one real advantage GHCP had over Claude Code et al.” Another: “I would much rather you jacked up the price per premium request by 30-50x than switch to token-based pricing where agents can nuke your supply of credits in very little time.” A third, more bluntly: “Request-based billing is user oriented. Token-based billing is not user oriented.”

That last one cuts to something real. The flat-rate model wasn’t just financially convenient — it was cognitively convenient. You knew what you had. You knew roughly when it would run out. Token consumption is invisible, variable, and highly dependent on decisions — model choice, context window size, session length — that most developers don’t think about explicitly while they’re actually working. The anxiety in that thread isn’t primarily about money. It’s about the loss of predictability. GitHub’s answer to its own FAQ question — “this just wiped GitHub’s value moat, why should I stay?” — was essentially: “because we think we’re still the best experience.” That may well be true. But it’s a harder sell when using the product responsibly now requires a working knowledge of token economics.

Are open-weight models a real alternative?

Yes. More than most enterprise developers currently acknowledge.

The common misconception is that open-weight means worse. That was true two years ago. It’s increasingly not true for the category of tasks that make up the majority of a working developer’s day: autocomplete on familiar patterns, boilerplate generation, test scaffolding for well-defined functions, documentation drafts, simple refactors. For these tasks, a well-quantized Qwen2.5-Coder-32B running locally is competitive with GPT-4 class inference. Not identical — but competitive. The difference becomes meaningful at the edges: novel architectural reasoning, subtle cross-file bug diagnosis, deeply understanding a codebase it’s never encountered with minimal prompting.

The models worth knowing right now:

Qwen2.5-Coder-32B (Alibaba): The current benchmark leader for self-hosted coding assistance. Runs on a single consumer GPU with 24GB VRAM at full quality — an RTX 4090 or NVIDIA RTX 6000 Pro handles it well. On a Mac with an M3 Max or M4 Max and 128GB unified memory, you can run it via Ollama with solid performance. Setup is genuinely simple: install Ollama, pull the model (ollama pull qwen2.5-coder:32b), configure Continue.dev to point at your local endpoint. Three config lines. You’re done.

DeepSeek Coder V2: Mixture-of-experts architecture that delivers strong performance on reasoning-heavy tasks at lower effective inference cost. Particularly good for debugging sessions where it needs to hold a lot of context without drifting.

Continue.dev as the harness: this is the piece that makes local models usable in daily IDE work. It sits inside VS Code or JetBrains, provides Copilot-like UX, and routes to any OpenAI-compatible endpoint — your local Ollama instance, a direct API call, or both depending on task type. You get the experience without the Copilot billing event.

The honest limitation: if your work involves frequent large-context, multi-file architectural sessions — the kind of heavy lifting where frontier models genuinely earn their cost — local models will frustrate you at the margins. Use them for the 70-80% of tasks that don’t require that. Reserve frontier API calls for the work that actually warrants them.

Smarter harnesses: routing as a professional skill

The shift to token-based billing makes explicit something that good engineers should have been doing anyway: matching model capability to task complexity. The flat-rate era made this unnecessary. The new era makes it advantageous.

Think in three tiers.

Tier one is local and free: inline completions, next-line suggestions, boilerplate for patterns you already understand well. Run a quantized open-weight model via Ollama. Sub-100ms latency in most setups, zero marginal cost, no billing event, no context leaving your machine.

Tier two is mid-range API: chat for moderate reasoning tasks, test generation for complex functions, documentation for non-trivial modules. A smaller Claude or GPT-4.1-class model via direct API. The critical discipline here is context window hygiene — the single biggest driver of unnecessary token spend is sending more context than the task actually requires. Scope your prompts. Reference specific files. Don’t dump the whole repository into context for a question about one function.

Tier three is frontier, used deliberately: security analysis, architectural review, complex multi-file reasoning where correctness matters more than cost per session. You already know when you need this level of capability. The problem has been that most tooling defaulted to frontier models for everything, including tasks that didn’t need them. Token-based billing will enforce better habits here, even if the forcing mechanism is uncomfortable.

One practical note: GitHub is launching a preview billing dashboard in early May, available through your Billing Overview page on github.com. Check it before June 1, not after. It will show you your projected costs under the new model based on your actual recent usage. If the number surprises you, you still have time to adjust before it becomes a line item on a real invoice.

The new divide: governance as competitive moat

Here’s the angle that most coverage has underplayed, and I think it’s actually the most consequential part of this story long-term.

The shift to pooled credits with admin budget controls isn’t just a billing change — it’s a governance change, and it structurally advantages large organizations in a way that compounds over time.

Under the new Business and Enterprise model, unused credits pool across the whole organization rather than expiring per-seat. Admins can set budgets at the enterprise, cost center, and individual user level — deciding which teams get access to which models at what spend limits. A 500-person engineering organization can route expensive frontier model credits toward senior architects doing novel, high-stakes work, and restrict junior developers to mid-tier models for routine tasks. They can centrally optimize AI spend in a way that’s genuinely sophisticated. That’s a real operational capability that requires organizational scale to use effectively.

A freelancer or a five-person startup has $10-19/month in credits, no pooling, no budget controls, and no organizational buffer for an unexpectedly expensive month. The gap isn’t just financial — it’s the gap between having a CFO-grade view of your AI spend and getting a surprise on your credit card statement.

The best AI coding tools have always favored those with the resources to deploy them well. Token-based billing sharpens that asymmetry considerably, even if it didn’t create it. This is the part of the story that the “prices are unchanged” headline obscures entirely.

What SMBs and individual builders should actually do

First and most urgently: go look at the May preview billing dashboard when it drops. Don’t skip this. Your intuitions about your own usage patterns are probably wrong. Many developers will discover they’re primarily inline completion users and their actual credit exposure is low — inline completions and Next Edit suggestions remain unlimited across all paid plans and don’t consume credits at all. Others will discover they’ve been running frontier model sessions that cost significantly more than they assumed. Know which camp you’re in before making any decisions.

If you’re on an annual Copilot plan, you have some buffer — PRU-based pricing continues until your plan expires. But model multipliers are increasing for annual subscribers on June 1, so it’s not cost-neutral even in the interim. Worth running the math before assuming you’re insulated.

Seriously evaluate whether Copilot’s harness is the right one for your workflow. Copilot’s genuine differentiator is deep GitHub integration — repo-aware context, PR-native code review, cloud agent tied to your CI/CD workflow. If you’re using heavy Copilot Chat but not actually leveraging those GitHub-native features, you may be paying for integration you’re not using. A direct API setup through Continue.dev might deliver 90% of your daily value at lower cost with more model flexibility and no vendor lock-in on billing structure.

Invest two hours in setting up local model infrastructure. Not as an experiment you’ll abandon, but as a parallel environment that runs alongside your existing tools. Ollama plus Continue.dev plus Qwen2.5-Coder-32B is a real setup that real developers are using in production workflows today. Run it for a month on your routine tasks and measure whether the quality is adequate for your actual work. The answer will be different for different people and different codebases — but you can’t know until you run the experiment properly.

Finally, develop the explicit habit of asking one question before opening any frontier model session: does this task actually require this level of capability? Could a scoped prompt to a lighter model do the job? This isn’t about being cheap. It’s about being precise — and precision in how you use these tools is a compounding skill regardless of what they cost.

The bigger picture

Twenty years in this industry gives you a particular kind of calibration. You get better at distinguishing the moments that are genuinely structural shifts from the ones that merely feel like it. This period — right now, 2025 into 2026 — feels like a real one. Not because the tools are magic, but because the economics of software development are being restructured in ways that will take years to fully understand. The rate of change is unlike anything I’ve seen before, and I’ve seen a few cycles.

The subsidy era made sense as a land-grab strategy. Vendor-subsidized access to frontier inference lowered adoption barriers, seeded habits, and built switching costs. It worked exactly as designed. Enterprises are hooked enough that GitHub knows they’ll absorb usage-based billing. That’s not a criticism — it’s how technology markets mature. But for the builders who aren’t enterprises, the question now is whether they can maintain meaningful access to tools that close the productivity gap, or whether those tools become structurally reserved for organizations that can run them at scale.

The pragmatic answer isn’t despair. It’s building the judgment to route intelligently — knowing when local is enough, knowing when the credits are worth spending, understanding the economics of your own workflow. The developers who compound the most value from AI tooling over the next three years won’t be the ones who used it most indiscriminately during the subsidy era. They’ll be the ones who developed genuine judgment about when and how to use it.

The honeymoon is over. The money is flying. Might as well understand exactly where it’s going.

pragmaticBuilder is where I write about software development without the hype. If this was useful, forward it to someone who’s about to get a surprise on their June Copilot bill.

Few words about me:

I started programming in the early 90s on a Commodore 64. For the past 20 years I’ve been doing it professionally — building scalable products, leading teams, and working as a solutions architect in fintech.

But 2026 feels different. AI tools have genuinely changed how I build things — and I’ve been in the trenches with Claude Code, Codex, and Cursor long enough to separate the hype from what actually works.

PragmaticBuilder is where I share what I’ve learned. Practical insights on building products effectively. Honest takes on which AI tools actually move the needle and how to use them without wasting your time. No fluff, no tool-of-the-week hype — just the stuff that works, from someone still doing it every day.

If you’re a developer, a founder, or just curious about where software is going — this is for you.

Let’s build something worth building.

Subscribe now