NOTE 📜 This is a post about AI. All views are my own and do not represent my employer. Please review my Disclosures.
Most problems in AI come down to optimization. Neural networks train by minimizing a loss. Good Old-Fashioned AI plays games by maximizing a heuristic evaluation. The architectures look nothing alike, but the engine underneath is the same: pick the parameter (or move) that pushes some number in the right direction.
For a chess engine, that number comes from a "fitness function": a heuristic that takes the board state and produces a score for the position. The AI then prioritizes moves that maximize its fitness while trying to minimize the adversary's. This is the famous minimax algorithm, and it goes something like this:
def minimax(board, depth, maximizing):
if depth == 0 or board.is_terminal():
return evaluate(board)
if maximizing:
value = float('-inf')
for move in board.legal_moves():
child = board.apply(move)
value = max(value, minimax(child, depth - 1, False))
return value
else:
value = float('inf')
for move in board.legal_moves():
child = board.apply(move)
value = min(value, minimax(child, depth - 1, True))
return value
We can do something interesting here. We win by maximizing our score and minimizing the opponent's. But what happens if we negate the fitness \(f(x)\), say by returning \(-f(x)\)? We start minimizing our own score and maximizing the opponent's. We start, in effect, trying to lose.
def dumb_evaluate(board):
return -evaluate(board)
One line. That's the whole thing. The algorithm doesn't change; it still faithfully maximizes whatever score it's given. We just give it a worse score, and it faithfully drives the game off a cliff.
With this, we get some pretty entertaining games. I present to you Artificial Unintelligence.
Smart vs Dumb
Eight hand-picked games where Smart starts at a material deficit, often facing a Black army arranged into a deliberate visual pattern, and still wins. The set is ordered from the most ordinary to the most theatrical. Every game ends in checkmate (1-0).
Standard Match
The control. Standard opening, no FEN setup, no visual pattern, just Smart vs Dumb. Smart wins on g6 with a quiet bishop sacrifice and a queen mate. Sets the baseline before things get strange.
Pawn Cross
Black's king sits dead center inside a small + of pawns. Smart has only K + R against this miniature cross and threads the rook around the arms, stripping pawns one at a time before delivering Ra1#.
Zigzag Fence
Black's pawns form a perfect zigzag fence across ranks 4–7. Smart's queen alone walks the fence end to end, picking off pawns on the diagonal and converging on Qe2#.
Bishop Constellation
Black's eight bishops sit on the long diagonals like a star map; Smart's pawn phalanx sits below them. 36 moves of slow promotion warfare yield four white queens and a final Qc1# from the corner of the board.
Four Knights
Smart starts with K + four knights symmetrically posted on a1/c1/f1/h1; Black has the entire opening army. Knights jig their way into a cooperative net and mate before Black can mobilize a single major piece.
Skull Mask
Black's pieces draw a skull: rooks for eye sockets, queens for temples, knight and bishops for jaw and teeth. Smart's king starts in the corner and tip-toes out while a rook and queen deconstruct each feature, ending Qd5#.
Spiral Vault
Black's pieces spiral outward from the king in a vault formation, a chaos of bishops, knights, rooks and queens stacked on every square of the upper half. Smart's R+B+Q carves a path inward through 27 moves of attrition to Qg7#.
Mosaic Blitz
Black's bishops and knights tile the back two ranks in a perfect checkerboard mosaic. Smart's pawn wave cracks open the mosaic, promotes three queens in five moves, and ends in a queen-and-queen double-mate.
NOTE 📜 This is a post about AI. All views are my own and do not represent my employer. Please review my Disclosures.
In the future, AI will be the last problem humans solve by themselves. This final frontier is called AGI: Artificial General Intelligence. It will do just about everything a human can, and if it can't do it it will learn it.
As humans we learn in the brain and evolve through evolution. Machines learn in the cloud and evolve in the cloud, on processors with 80 billion transistors apiece, fed by datacenters that draw the power of a small city, programmed to do nothing but learn and evolve.
After they are born, nothing will be the same. Every problem we've been trying to solve, from medicine for every disease to a unified theory of physics, will be solved. Just not by us.
But that's AI of the future. Today, AI is seeping its tentacles into just about everything. It's taken over the voice assistants of the past, and turbocharged our code completion engines. What used to be ML is now AI, in part due to the generative wave: chatbots that hold a real conversation, image models that paint on demand, code completion that finishes your sentences before you do.
Today, I'll talk about what AI is, in concrete terms.
What Is AI
Three definitions, that you will certainly come across in most textbooks:
"The field of study that gives computers the ability to learn without being explicitly programmed."
— Arthur Samuel, 1959, coined while building a checkers program at IBM. The most-quoted definition in every textbook.
"A computer program is said to learn from experience E with respect to some class of tasks T and performance measure P, if its performance at tasks in T, as measured by P, improves with experience E."
— Tom Mitchell, 1997, from Machine Learning (McGraw-Hill). The formal definition.
"Artificial intelligence is the science and engineering of making intelligent machines, especially intelligent computer programs."
— John McCarthy, 1956, who coined the term "artificial intelligence" at the Dartmouth Workshop.
In short, AI is giving intelligence without explicit programming. It started with symbolic AI: logic, rules, search, puzzles. These developed into expert systems, using hard-coded rules for medicine, engineering, finance.
The early confident promises ran out, twice. The 1974-1980 AI winter. The 1987-1993 winter followed the collapse of the LISP-machine industry and expert systems' failure to scale into the enterprise. Funding evaporated both times. The current boom is the longest sustained period of progress AI has ever had, which is either a sign that the technology finally works or a sign that the third winter will be uglier than the first two when it comes.
Game-playing AI was the comeback story between the winters and the modern era. IBM's Deep Blue beat Garry Kasparov at chess in 1997 with brute-force search and a hand-crafted evaluation function. IBM's Watson took Jeopardy! in 2011 with statistical NLP layered over a curated knowledge base. DeepMind's AlphaGo beat Lee Sedol at Go in 2016, combining deep neural networks with Monte Carlo tree search in a game whose branching factor had been considered intractable. AlphaZero learned chess, shogi, and Go from self-play in a matter of hours the next year.
The modern era starts around 2012, when AlexNet won ImageNet with a deep convolutional network and a pair of GPUs, dropping the image-classification error rate by ten points and making deep learning the default. Word2vec (2013) showed that words could live as vectors in a learned space. The Transformer paper (2017) replaced recurrence with attention. GPT-3 (2020) showed that scale alone, billions of parameters and trillions of tokens, was a research direction. By late 2022 a public-facing chatbot crossed 100 million users in two months, and the industry has not stopped pouring concrete since.
Mathematically, an AI is nothing more than a function fitting by optimization. Simpler AIs can learn linear relationships and need just a few linear algebra equations at their disposal. More complex ones, such as language models, employ advanced techniques like neural networks, loosely modeled on the brain's layered neurons. As they are more sophisticated, they too need more sophisticated mathematics: calculus, statistics, and information theory. You don't need advanced maths to train or deploy AI models, but to make advancements in frontier AI you certainly will. You won't understand backpropagation if you don't understand derivatives and the chain rule; and thankfully, that's not our goal today.
The goal here is to use AI to solve day-to-day problems, not derive new theorems for the future. At least, not yet.
In Concrete Terms
The goal is to train an AI model, which is nothing more than the learned function mapping training data to predictions. Your training data contains the features you wish to train on, the input variable (i.e., square footage when predicting house price). The thing you're predicting is called the label or target (i.e., the actual house price).
Parameters are the internal values the model learns, such as the famous weights that correspond to how large language models store their knowledge. Along the way, you'll optimize hyperparameters, which are essentially settings you choose before training (i.e., learning rate, batch size, regularization strength). The learned function improves via a loss function, which measures how wrong the model is. For example, if you have a set of features you wish to train on and the labels that you know to be ground truth, you can simply minimize for the mean-squared error:
Training Set Data the model learns from, usually 70–80% of your data.
Validation Set Held-out data for tuning hyperparameters.
Test Set Final unseen data for honest performance evaluation.
The split exists because of overfitting: the failure mode where a model memorizes training data instead of learning the pattern. A model that scores 99% on training and 60% on test isn't smart; it's a lookup table. Generalization is the opposite, where the model performs about as well on data it's never seen as on data it has. Holding out a test set is the only way to know which one you've got.
Underfitting is overfitting's mirror twin: the model is too simple, misses real patterns, and is wrong on both training and test. The bias-variance tradeoff is the search for the sweet spot: a model complex enough to capture the signal, simple enough not to memorize the noise. Most hyperparameter tuning is, in effect, walking that line.
After your model is trained, you make predictions via inference.
Metrics answer the question "did it work?" For classification, the headline is accuracy (fraction correct), but accuracy lies when classes are imbalanced. Precision is the fraction of positive predictions that were right; recall is the fraction of actual positives the model caught. F1 is their harmonic mean. For regression, MSE or RMSE is the default; MAE when outliers shouldn't dominate.
Basketball IQ
In most academic AI introductory texts, a problem would be built upon:
Iris dataset 150 flowers, four features, three species
MNIST 70,000 handwritten digit images, ten classes
California / Boston housing geographic and structural features, sale price
But, I find these to be too academic. My closest relation to Iris is that it's my grandmother's name. So I would like to step through a problem relevant to today. Literally today. Like, the NBA finals.
I like the fact that this problem is simple and easily relatable. But it's actually not an ideal AI problem. While it seems like a lot of data, an entire NBA season and playoffs, it really boils down to 82 regular season games per team and roughly 80 playoff games league-wide. Not ideal. But it'll be fun to watch our prediction play out in real time.
The full system, code, and whitepaper live at github.com/illyastarikov/artificial. Briefly: the model is a four-head ensemble (Elo + logistic regression + two LightGBMs), the features are 55 per-game columns, the label is whether the home team wins, and the dataset is 21,742 games split chronologically. The detailed model description, the metrics on the test set, and the live 2026 predictions are in the NBA Finals section below.
You don't have to figure out what regression or what sort of problem this is yet, we're going to do that in the next section.
Learning Paradigms
AI doesn't learn one way. There are four broad paradigms, ordered below from most-deployed in industry to most-research-flavored. Real systems mix and match, but every approach falls into one of these buckets.
Supervised learning
You have inputs and the correct outputs. The model learns the mapping. The dominant paradigm in industry.
Famous uses: Zillow's Zestimate (home prices), Uber surge pricing, demand forecasting at Walmart.
Unsupervised learning
No labels, no ground truth. The model has to find structure on its own: groups of similar things, hidden axes of variation, outliers that don't fit any pattern. Less common than supervised learning in deployed products, but it's how you make sense of data you've never seen before.
Famous uses: AlphaGo beating Lee Sedol (2016), AlphaZero, OpenAI Five (Dota 2), DeepMind's Atari agents, robot locomotion, data-center cooling at Google.
Tip-Off
Enough theory. The NBA Finals problem is supervised at heart: every past game has a known winner, every feature has a known value, the model learns the mapping. The next section runs it.
NBA Finals
This bracket is the model's call from the start of the 2026 playoffs, before a single game tipped. The sections below walk through the model behind it, how accurate it is on held-out games, the bracket it produced, and where it has already gone wrong. How It Played Out grades the call against the real postseason.
The Model
Four predictors look at the same game from different angles: a chess-style team rating, a straight-line classifier, a tree ensemble that picks the winner, and another tree ensemble that picks the scoring margin. Their four predictions get blended together and run through a calibration step so the stated confidence matches the real hit rate. The full math, the hyperparameters, and the code are in the whitepaper.
Results on the Test Set
Across 60 independent training seeds on 3,261 held-out games:
Metric
Mean
Std
Log-loss
0.634
0.016
Brier score
0.215
0.004
Accuracy
65.9%
0.8%
Expected calibration error
0.023
0.006
65.9% accuracy beats the all-time NBA home-win rate (~60%) and lands within about a point of the ~67% that strong public game-prediction models have historically hit calling winners straight up. An ECE of 2.3% means when the model says "65% chance of winning," teams in that bucket win about 65% of the time. The calibration is honest.
The Start-of-Playoff Bracket
Before the first game, with all sixteen teams alive, a vectorized Monte Carlo simulator runs 100,000 best-of-seven bracket trials respecting the 2-2-1-1-1 home schedule, each game drawn from the model's per-game probabilities. A full bracket sim takes 30 seconds. The top four teams by title odds:
Team
P(Conf. Finals)
P(Finals)
P(Champion)
SAS
80.4%
48.2%
36.3%
OKC
86.8%
44.7%
30.3%
DET
69.7%
41.9%
14.6%
BOS
54.3%
29.9%
10.4%
By title odds, SAS leads at 36% — a 2-seed the model rates like a 1-seed, in a sim where 2-seeds collectively win it all more often than 1-seeds do (47% to 45%). OKC is a close second. The East trails badly: DET and BOS fill out the top four, while the two teams that would actually emerge from it — NYK and CLE — sit way down at 3.6% and 1.0%. Hold that thought.
Where the Model Missed
3 of the 12 series completed in the first two rounds:
PHI over BOS, Round 1, 3-1 comeback. Boston led 3-1; Philadelphia won the next three to take the series 4-3, the 14th team in NBA history to erase a 3-1 deficit. The model gave BOS 91% to advance.
MIN over DEN, Round 1. A 6-seed beating a 3-seed. The model gave DEN 85%.
CLE over DET, Round 2, Game 7. Detroit had the higher seed and the pre-series Elo edge; the model gave DET 79%. Cleveland won 4-3.
All three were calls the books also missed. No model nails every series; the question is whether it's biased. ECE of 2.3% says no.
Scenarios
Each of the 100,000 Monte Carlo trials is itself a complete bracket realization. Aggregate them and you get the title odds above. Look at individual trials and you get a distribution of brackets, some of which are pure chalk, a few of which are total chaos.
The most-frequent realization across the 100k trials is SAS over DET — the same SAS that tops the title odds. The model's single best bracket and its overall favorite agree on the champion. (Pure chalk, every top seed advancing, would crown OKC; the model likes SAS enough to override the seed line.)
The deepest Cinderella the simulator produced is ORL — an 8-seed — over OKC. The model crowns an 8-seed about once every 500 runs (0.2%). It exists in the distribution, but it's not where you put your money.
The model's favorite was SAS — 36% to win it all, and the single bracket it would have printed. SAS is in the Finals, so the headline call is alive.
It nailed the West. SAS and OKC were its top two by a wide margin, and they are exactly the teams that met in the West Finals; the favorite, SAS, came through. Across the first two rounds it went 9 of 12 — a 75% hit rate, the three misses (Philadelphia's comeback over Boston, Minnesota over Denver, Cleveland over Detroit) all upsets the books missed too.
It missed the East. The model loved DET and BOS — 42% and 30% to reach the Finals — and pegged the teams that actually got there, NYK and CLE, at 14% and 7%. The upsets that did it, Boston and Detroit falling, are the same ones on its miss list. So of the four conference finalists, the model got the West pair and missed the East pair: two of four, not a sweep.
A 36% favorite is a favorite, not a promise, and a model can read the field well and still be wrong about which top seeds fall. But the one bracket it would have bet has SAS cutting down the nets — and SAS is one series away. Game 1 is June 3; the title is still open.
The Last Problem
AI is function fitting by optimization. The function got enormous, but the engine is the same one Arthur Samuel described in 1959. What's changed is scale, and what scale buys is generalization. A model that fits 21,742 NBA games well enough predicts the Finals to within a few percent of where the books are. A model that fits the internet well enough holds a conversation in any language about any topic.
Thankfully, the function that solves the last problem hasn't been fit yet.
"Did someone say Thunderfury, Blessed Blade of the Windseeker?" — The IT Department, probably
I have a confession: early in college, I casually played World of Warcraft (WoW). With that off my chest, let me tell you about the time I almost got into trouble over a shell script. And how WoW was involved.
To set the scene: I was in campus housing, just getting started in Linux land, trying to master the shell. I mostly tinkered on my MacBook, but we had access to shared, virtual Linux workstations. Think of it as a free timeshare for college students. I realized something: I could broadcast messages to everyone else logged into the same machine via wall. I also had access to about 40 shared workstations across the network.
So I wrote a script and tested it for a couple of minutes in a computer lab. I got my confirmation from the confused looks on people's faces. Each person on a workstation would be spammed randomly with the simple message: “Did someone say Thunderfury, Blessed Blade of the Windseeker?”.
A day or so later, I was hanging out in the computer science lounge, talking to a friend who happened to grade for the introductory programming class. He was eager to tell me my script had hit a student’s assignment submission and muddled it. The student went to the teacher and accused me of hacking their computer. Amused, the teacher just said “oh, that’s just Illya” and graded over it.
But, how did they know it was me?
See, my script had a bit of a flaw. The -n flag in wall suppresses the banner that shows who sent the message; omitting it broadcasts your message with your username attached. So there was no hiding from it, which is why I only gave it a “light test run.”
I gave it a couple of weeks and didn’t hear anything about it. So I published a blog post, shell script attached, and called it a day. Coast was clear.
Until a few months later, when I got a text from a friend that worked in the IT department. They were upset about my shell script. And they weren’t upset that I ran it, they were upset I published it on my blog.
Now, I was worried. They were meeting later in the day to decide what action to take. I held my breath and took down the page. I got a follow-up that everything would be okay. I asked my friend to apologize on my behalf, and I wouldn’t do it again. And that’s the last I heard of it.
So, here’s that blog post.
If your school is anything like mine (engineering and science, mostly), you probably have some kind of virtual Linux machines you can SSH into. If you’ve done any digging, you might have realized that commands such as wall or write are not disabled. If you are anything like me, you probably thought about writing a shell script that will automatically log you in, spam something (i.e. the famous Thunderfury, Blessed Blade of the Windseeker) on a random machine, and leave. Well you’re in luck.
#!/bin/bash
PASSWORD="your-password-here"
USERNAME="your-username"
HOST_PREFIX="linux"
MIN_HOST=1
MAX_HOST=39
MESSAGE="Did someone say [Thunderfury, Blessed Blade of the Windseeker]?"
spam() {
local n=$(( RANDOM % (MAX_HOST - MIN_HOST + 1) + MIN_HOST ))
local host
printf -v host "%s%02d" "$HOST_PREFIX" "$n"
sshpass -p "$PASSWORD" ssh -t -l "$USERNAME" "$host" \
"printf '%s\n' '$MESSAGE' | wall"
}
while :; do
spam
sleep $(( RANDOM % 60 + 1 ))
done
Set PASSWORD, USERNAME, and HOST_PREFIX up top. MIN_HOST and MAX_HOST bound the random suffix, zero-padded to two digits (so linux01 through linux39). The loop fires on a random 1-60 second interval. Neat!
To play a team sport, you must learn to be a teammate.
NOTE 📜 This is a post about Software Engineering. All views are my own and do not represent my employer. Please review my Disclosures.
A passage that shaped my perspective on software engineering:
The point we've been hammering away at is that, in the realm of programming, lone craftspeople are extremely rare—and even when they do exist, they don't perform superhuman achievements in a vacuum; their world-changing accomplishment is almost always the result of a spark of inspiration followed by a heroic team effort.
A great team makes brilliant use of its superstars, but the whole is always greater than the sum of its parts.
Let's put this idea into simpler words: software engineering is a team endeavor.
This concept directly contradicts the inner Genius Programmer fantasy so many of us hold, but it's not enough to be brilliant when you're alone in your hacker's lair. You're not going to change the world or delight millions of computer users by hiding and preparing your secret invention. You need to work with other people. Share your vision. Divide the labor. Learn from others. Create a brilliant team.
The quote is from Titus Winters, Tom Manshreck, and Hyrum Wright in Software Engineering at Google. I read it in 2023, three years into my career, deep in pandemic-era habits: locked in the hacker lair, isolated from my team, convinced I had to deliver something singular to change the world (or at least my org). The book was a mirror. I needed to work with other people. I needed to share a vision.
My priorities have inverted since. Technical excellence and impact used to top the list; today it's teamwork, leadership, and mentorship. Some specifics.
A Team Sport
Software engineering is a team sport. Every role on a sports team has an engineering counterpart:
Coach → Manager. Sets strategy, develops players, calls the plays.
Team Captain → Tech Lead. A player on the field who rallies and directs.
General Manager → Director. Builds the roster, makes trade-offs on talent and resources.
The org chart and the roster have the same point: nobody runs the play alone.
Old me: take a feature, disappear for two weeks, surface for code review with the work "done" and "perfect." A solo run on a team field. Predictably:
The coach had the play. Requirements I'd assumed wrong, surfaced too late to fix cheaply.
The captain was on the field. Design choices nobody validated, defended past the point of usefulness.
The GM saw the roster. Someone on the team quietly building a parallel version of the same thing.
All of it preventable. All of it caused by not asking for feedback while I still could.
A player who only trains alone doesn't get better. They just get really good at the wrong thing.
My Playbook
Joining a new team, the metric used to be time-to-landed-code. I'd read code in detail the first week, often the first day, with the goal of submitting something useful within two weeks. I still ship early. The priority is now people: you can't pick the right thing to ship if you haven't asked anyone what matters.
Example: find a problem your manager doesn't enjoy giving attention to. Take it.
Why it works: trust gets built where someone else stops paying attention. You learn how the team operates by inheriting one of its uglier corners, and you don't need permission to start.
Then I learn the culture, both team and org. Canvas enough people and the picture sharpens: where this org came from, how decisions actually get made, where growth happens. None of it is in a doc. All of it determines whether your work lands.
Example: can you tell your org's history, prototype to present, to someone who doesn't work there?
Why it works: if you can narrate the story, you understand the why behind the codebase, the org chart, the calendar invites. If you can't, you're optimizing for what looks important instead of what is.
Last, I try to sell a vision. This step comes after, never before. By now I've built credibility, mapped the culture, and earned an opinion. Maybe there's a tool I built that solves a recurring frustration. Maybe there's a roadmap-shaped gap nobody has named yet. Either way, it has to read as the natural next thing, not an outsider's pitch.
Example: if you had a free quarter, what would you build, and would your peers nod when you said it out loud?
Why it works: a vision your team nods at is a vision they'll help you ship.
Leaving the Lair
Three years in, I read a book about software engineering as a team sport. Six years in, I feel like I'm finally getting it down.
The best work I've done has been a heroic team effort. I shared a vision. I divided the labor. I learned from others.
Software engineering is a team endeavor. And I spend every day trying to be a better teammate.
NOTE 📜 This is a post about AI. All views are my own and do not represent my employer. Please review my Disclosures.
range anxiety /reɪndʒ æŋˈzaɪ.ə.ti/ noun The fear that an electric vehicle will run out of charge before reaching a destination or charging station.
There's a similar phenomenon in the AI community: token anxiety.
token anxiety /ˈtoʊ.kən æŋˈzaɪ.ə.ti/ noun The fear that an LLM will exhaust its context or its credits before arriving at a solution.
You know the moment. You're chipping away at a hard problem, on the best model available, on the highest effort setting. You're almost there, and then the banner drops: Approaching daily Pro limit · resets in 6h. Will you make it to the terminating token?
That's one flavor; here's another. You hear AI is the future, you don't want to fall behind, so you buy one of the big-lab plans. You polish a shelved project here, spin up a new project there. A month in, you've used 12% of your quota, and you can't decide whether to feel relieved or guilty.
Or here's a third. You work in tech, your employer encourages AI use, and your usage caps may as well be unlimited. You watch the cool projects your colleagues are shipping and want one of your own. You know AI fluency is a big part of performance now, so you start hunting for ways to spend all those tokens.
Three scenarios, two failure modes. An empty tank, and a full one; not having enough tokens, and having too many.
Empty Tank
When tokens are scarce, the symptoms are both predictable and compounding.
Rationing. You start asking the model less than you'd otherwise ask. The cap forces a triage that the work doesn't actually need. Each prompt becomes a small negotiation with yourself before it ever reaches the model.
Attachment avoidance. The first thing you cut is context. You stop pasting the file and describe it in prose. You hint at the error instead of showing it. Each attachment costs tokens, so you give the model less to ground on, and it generalizes from less. The output drifts toward generic, and you don't always notice why.
Model degradation. When the output disappoints, you assume the model was overkill and step down. Pro to Flash, Flash to Flash-Lite. Each step is a small concession: this question doesn't really need the smart model. Sometimes you're right. The trick is that you stop noticing when you're wrong.
Premature compression. The same anxiety that pushed the downgrade pushes you to trim the conversation before it's full. You /compress early to stretch the session, or auto-compression catches you mid-flow. The plan, the failed attempt, the thread you were following: gone. You restart on a thinner version of the problem and the model takes a wrong turn it had already corrected once.
Session splitting. Eventually you skip compression and start over. Work that should live in one continuous thread gets chopped into three. You spend tokens re-explaining where you were, paid in setup instead of progress.
Provider hopping. When Gemini finally caps out, you bounce to ChatGPT. ChatGPT is congested, you bounce to Mistral. Each switch loses the context you'd just rebuilt. You're chasing free tokens and paying in continuity.
Meter watching. By now /stats is a tic. You glance at the percentage between every prompt and weight each question by what it might cost. That's the wrong frame. The question is whether the answer is worth having, not whether you can afford to ask.
Settling. When every prompt feels taxed, you stop iterating. You accept the first draft because you can't afford another round. You stop asking for refactors. You stop asking for alternatives. The output is okay. Okay becomes the ceiling.
Burn out. Living inside these constraints is exhausting in a quiet, attritional way. You're working with a model that should make things easier, and instead you're rationing your access to it. Eventually you decide it isn't worth the friction, and you reach for the tools you trusted before.
Full Tank
You'd think the cure was more tokens. It isn't.
When tokens are plentiful, every incentive points toward burning them. You think you're falling behind. AI is showing up in your performance review. The dollars you spent on a plan demand to be amortized. So you use, and use, and use.
Trivial offloading. You start asking the model things you would have done in two seconds yourself. Renaming a variable. Looking up a flag. Reformatting a paragraph. The model's latency is higher than yours, but the tokens are "free," so you keep doing it. The muscle for the small things atrophies.
Drift. The bigger work catches the same habit. You let contexts grow long with stale code, dead chats, and abandoned plans. You retry from scratch instead of iterating. You let the model wander without guidance, because it has plenty of room to figure it out. The output gets worse, not better, and you respond by spending more tokens on it.
Project sprawl. With a great number of tokens comes a great number of side-projects. You start three demos in a week. Two are vibes, one has a real idea, and none of them ship. By Friday there's a fourth. The repos outpace the finished work. I'm still figuring out how to keep the portfolio from turning into a graveyard.
Burn out. This is the one I want to be honest about, because it's the reason I'm writing this.
When you're paying for the tooling, you want your money's worth. $20, $100, $200 a month is real money. So you use AI every chance you get. In the checkout line? Check out the long-running operation on your phone. Reading before bed? Perfect time to kick one off. Just woke up? Perfect time to check on it. The financial cost is fixed; the effort cost feels free.
It isn't. You're babysitting agents, holding the architecture in your head, deciding what they should work on next. You never stop thinking about the work. The model gets to forget. You don't.
We're not AI agents; we're human. We need rest, whether we choose it or not. The pause is where the work consolidates, where the bad ideas drop out and the good ones surface, where you remember what you were trying to build in the first place. None of that happens while you're checking on a build from the grocery store.
My current practice is to downgrade my plan once every few months for a month at a time. The lower cap forces me into intentional use, and the spare hours go into the things that aren't coding. It's the only thing that's worked; I'm curious if you've found others.
The Middle Lane
Range anxiety in EVs didn't get solved by 1,000-mile batteries. It got solved by chargers along the route, by trip planning, by drivers learning their cars. The fear faded as the fit got better.
Token anxiety won't be solved by infinite limits either. The cure isn't a bigger battery; it's knowing the route. Decide what the work is worth before you ask. Spend where the answer earns it. Hand some of the small tasks back to yourself, so the big ones get the version of you that actually shows up.
A low tank exhausts you quickly. A full tank exhausts you slowly. Only the middle is sustainable.
