Press enter or click to view image in full size
TLDR
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.
A Billing Change Worth Thinking About
On June 1, 2026, GitHub Copilot quietly changed its billing model.
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.
Subscription prices haven’t changed, but developer Slack channels and tech forums have been full of complaints.
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.”
More interesting was another response: “We need to learn to use it efficiently.”
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.
That led me to a bigger question: what exactly is AI repricing?
The First Kind of Slow — the Weight of Systems
Let’s start with workflows.
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.
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.
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.
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.
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.”
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.
The Second Kind of Slow — the Density of Growth
Also slow. But an entirely different thing.
Now let’s talk about how engineers grow.
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.
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.
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.
But judgment hasn’t followed them to F.
When AI gives them an answer, they have no ability to evaluate when that answer is wrong. When a system breaks in a way AI can’t handle, they don’t have the instinct that says “I’ve seen something like this before.” They skipped those slow moments — and also skipped what those moments would have left behind.
This isn’t AI’s fault. It’s not the engineer’s fault either. It’s just that the second kind of slow and the first kind of slow are completely different things. The first kind of slow is noise. The second kind is signal.
Once Upon a Time, Slow
Mu Xin (木心) was a Chinese poet, painter, and writer. He wrote a poem called Once Upon a Time, Slow (《从前慢》):
记得早先少年时
大家诚诚恳恳
说一句 是一句清早上火车站
长街黑暗无行人
卖豆浆的小店冒着热气从前的日色变得慢
车，马，邮件都慢
一生只够爱一个人I remember when we were young,
everyone was earnest and sincere —
a word meant a word.Early morning at the train station,
the long street dark, no one walking,
a small soy milk shop steaming in the cold.Days used to move more slowly.
Carts, horses, letters — all slow.
A lifetime was only enough to love one person.
Many people love this poem, but they love it differently. Some love the atmosphere of slowness — nostalgic, warm. But what I think the poem is really saying is that slowness is the source of depth.
“A lifetime was only enough to love one person” — not because people in that era were more devoted, but because slowness gave every thing enough weight. Writing a letter took three days; in those three days, you turned your thoughts over until they were clear. Waiting for a reply took a month; in that month, the relationship slowly fermented inside you. Slowness isn’t a deficiency. Slowness is where depth comes from.
For an engineer’s growth, the logic is the same.
Two days chasing a bug — in those two days, you loaded the entire system’s inner workings into your head. A week grinding through bad documentation — that week gave you a real sense of the framework’s design philosophy. One production incident handled — you now understand “what does a system actually do at the extremes” not from reading a blog post, but from the memory of your hands shaking.
These slow moments aren’t inefficiency. They’re where real learning happens.
Now these moments are being skipped at speed. Not because anyone decided to skip them — just because the tools are so frictionless that slowing down starts to feel odd. Like letters giving way to messages: no one forbids a long letter, but you naturally stop writing them.
Two Bills
After GitHub Copilot changed its billing, one feature became suddenly interesting: the billing preview. You can see how much your last month of usage would cost under the new model. Some people opened it and inhaled sharply.
That bill is visible. There’s a dashboard, there are numbers, there are alerts when you go over. You know how much you’ve used, what you’ve spent, what’s left.
The growth bill is different.
An engineer who used AI to skip large amounts of the accumulation process — their “overdraft” won’t show up on any dashboard. No notification says “your judgment balance is running low.” No monthly statement reminds you “this month you skipped 47 problems you should have worked through yourself.” Everything looks fine, even smooth — code runs, features ship, performance reviews come back good.
The bill arrives years later.
It usually shows up at a critical moment when AI can’t help: a strange production issue that requires you to intuit where to start; an architecture decision with no right answer, requiring you to distill judgment from past experience; a technical interview where the question isn’t “how would you solve this” but “why did you make that decision at the time.”
That’s when you discover that the skipped B, C, D, E weren’t just steps toward a result — they left behind something called “I actually understand this.” And that thing can’t be made up for later.
The Distinction We Need to Make
AI doesn’t make this distinction.
It doesn’t know whether what you need right now is an answer, or the process of finding the answer yourself. It knows what you asked, and it tries to give the best response. That’s just how it works.
The responsibility for the distinction falls on humans.
The first kind of slow — in workflows — automate what can be automated, eliminate what can be eliminated. The inter-system friction, the format conversions, the repetitive manual steps — let AI handle those, so you can do the work that genuinely requires judgment. This is what AI should be doing. It’s also what it does best.
But the second kind of slow — in growth — you have to actively preserve it. Not every question should go to AI first. Some questions are worth sitting with for twenty minutes on your own, even if the answer you arrive at is the same as what AI would have given. Those twenty minutes aren’t waste. They’re your judgment getting recharged.
This isn’t an argument against using AI. It’s not a case for deliberate inefficiency. It’s saying this: the boundaries of a tool need to be drawn by the people who use it.
GitHub Copilot’s billing change is prompting developers to re-examine their usage — which calls were genuinely necessary, and which were just convenient. That re-examination is a good thing. And the same question is worth asking about growth: when do you actually need AI to give you the answer, and when should you think it through yourself first?
Once upon a time, we were slow because we had no faster option. Now we do — but between “can go fast” and “should go fast,” there’s a distance worth pausing to consider.
The first kind of slow: give it to AI. The second kind: keep it for yourself.