Once Upon a Time, Slow: Two Kinds of Slow, Two Fates | by Addo Zhang | Jun, 2026 | MediumSitemapOpen in appSign up<br>Sign in

Medium Logo

Get app<br>Write

Search

Sign up<br>Sign in

Once Upon a Time, Slow: Two Kinds of Slow, Two Fates

Addo Zhang

7 min read·<br>5 days ago

Listen

Share

Press enter or click to view image in full size

TLDR<br>AI has eliminated friction in our workflows — but it’s also quietly skipping the necessary passages of growth. GitHub Copilot’s billing change is just a signal: not all slowness should be made fast.<br>A Billing Change Worth Thinking About<br>On June 1, 2026, GitHub Copilot quietly changed its billing model.<br>The old model charged by “request count” — a quick Q&A and an agentic task that ran for an hour cost the same. The new model charges based on actual token consumption, in units called GitHub AI Credits — the more powerful the model, the longer the run, the more you spend.<br>Subscription prices haven’t changed, but developer Slack channels and tech forums have been full of complaints.<br>Some people discovered their typical usage would multiply their bills several times over under the new model. Some burned through their credits in a day and a half and had to drop down to a lower-tier model to keep working. Others sighed: “It’s hard to go back to less after you’ve had more.”<br>More interesting was another response: “We need to learn to use it efficiently.”<br>That sounds like advice, but if you think carefully, it’s itself a new kind of friction — before, you never had to think about this. Now you need to spend mental energy researching how to “use less.” AI was supposed to eliminate friction, but it just created a new kind of intermediate cost.<br>That led me to a bigger question: what exactly is AI repricing?<br>The First Kind of Slow — the Weight of Systems<br>Let’s start with workflows.<br>A typical engineering workflow rarely happens inside a single system. Requirements live in Jira, code in GitHub, deployments in Jenkins, monitoring in Grafana, documentation in Confluence, notifications in Slack. Each system has its own API, its own data format, its own interaction model.<br>Getting from input A to output F means passing through B, C, D, E — each step a format conversion, a system switch, a manual handoff. None of these intermediate steps carry inherent value. They’re just the residue of history: gaps left behind when different teams built different systems in different eras.<br>AI is exceptionally good at exactly this kind of problem. Unstructured inputs, wildly inconsistent formats and interfaces, constant cross-platform friction — this is AI’s home turf. You hand it a requirements description; it generates a Jira ticket, drafts a PR description, updates the docs, sends a Slack notification. B, C, D, E get dissolved. You go straight from A to F.<br>This kind of “elimination” is genuine efficiency gain with no loss. Those intermediate steps never should have existed — or more precisely, they existed only because we lacked better tools to handle the chaos between systems. AI filled that gap. That’s a good thing.<br>But there’s a trade-off worth noting. The traditional approach is to spend engineering effort once building an adapter or ETL pipeline, then almost never invest again. The AI approach is the inverse: near-zero upfront cost, but every execution burns tokens — what was a “one-time cost” becomes a “per-use API bill.”<br>When tokens were subsidized, the AI path was obviously better. But Copilot’s billing change signals that the subsidy is ending — and the scales of this trade-off are starting to tip again. The friction in workflows deserves to be eliminated, but the cost of elimination is now being priced for real. This is the first kind of slow: one that never should have existed. We just didn’t notice the price before.<br>The Second Kind of Slow — the Density of Growth<br>Also slow. But an entirely different thing.<br>Now let’s talk about how engineers grow.<br>The path from junior engineer to senior engineer or architect typically involves: learning a language, grinding through a framework’s documentation, spending two days debugging a bizarre bug, getting wrecked by a production incident, having countless code reviews surface problems you never thought of. These experiences accumulate and slowly crystallize into something — judgment.<br>Judgment isn’t knowledge. Knowledge can be retrieved, generated, instantly provided by AI. But “this area has a trap, I fell into it once” and “this solution looks viable, but it’ll break at scale” — these intuitions can only grow from real friction.<br>With AI, a junior engineer can skip large swaths of B, C, D, E and directly produce something that looks like F. They can write code that runs, explain a complex architecture, produce a technical proposal that looks the part. From the outside, this person seems to have already reached F.<br>But judgment hasn’t followed them to F.<br>When AI gives them an answer, they have no ability to evaluate when that answer is wrong. When a system breaks...