Blog

AI Foundations

Ball don't lie, and neither does linear algebra.

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:

$$ \mathrm{MSE} = \frac{1}{n} \sum_{i=1}^{n} \left( y_i - \hat{y}_i \right)^2 $$

The dataset is usually broken into a:

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.

Classification Predict a discrete category.

Algorithms: logistic regression, SVMs, random forests, gradient boosting, k-NN, naive Bayes, neural nets.
Famous uses: Gmail spam filtering, breast cancer detection from mammograms, ImageNet (AlexNet, 2012), credit card fraud detection.

Regression Predict a continuous number.

Algorithms: linear/ridge/lasso regression, regression trees, gradient boosting (XGBoost), neural nets.
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.

Clustering - Algorithms: k-means, DBSCAN, hierarchical, Gaussian mixtures. - Famous uses: customer segmentation, news topic grouping (Google News), gene expression analysis.

Dimensionality reduction - Algorithms: PCA, t-SNE, UMAP, autoencoders. - Famous uses: visualizing high-dim data, image compression, eigenfaces (face recognition, 1991).

Anomaly detection - Algorithms: isolation forest, one-class SVM, autoencoders. - Famous uses: fraud detection, network intrusion, manufacturing defect detection.

Association rules - Algorithms: Apriori, FP-growth. - Famous uses: Amazon "frequently bought together", market-basket analysis.

Semi-supervised & self-supervised learning

Mostly unlabeled data with a sprinkle of labels (semi-), or labels invented from the data itself like "predict the next word" (self-).

Famous uses: Google's early image search labeling, word2vec (2013), and the entire pre-training era of modern AI.

Reinforcement learning

An agent takes actions in an environment and learns from rewards. No labeled examples; feedback comes from outcomes.

Algorithms: Q-learning, SARSA, policy gradients, actor-critic, DQN, PPO.
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.

Modal bracket: the single most-frequent realization across the 100k trials

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.)

Cinderella champion: ORL (8-seed) over OKC

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 full whitepaper, code, and per-trial scenarios live at github.com/illyastarikov/artificial.

How It Played Out

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.

Tuesday, 2 June 2026

, & Illya Starikov

AI Computer Science

The Thunderfury Incident

"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!

Wednesday, 27 May 2026

, & Illya Starikov

Missouri S&T Self Code

Software Engineering is a Team Sport

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.

Tuesday, 19 May 2026

, & Illya Starikov

Software Engineering

Token Anxiety

Approaching daily Pro limit · resets in 6h

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.

Gemini CLI showing Pro and Flash both at 100% used, hours until reset

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.

Claude Code session usage at 12%, weekly at 7% — plenty of room left

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.

OpenAI Codex showing 5h limit at 51% left, weekly at 61% left — the middle of the tank

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.

Tuesday, 12 May 2026

, & Illya Starikov

AI Software Engineering

You Should Host a Website

Not have one. Host one.

Everyone tells you the same thing: you should have a website. A place the algorithm can't touch. A URL that's yours. Words that outlive the platform.

They're right. But this isn't a post about having a website; it's about hosting one.

Decade of Hosting

I've been running websites since 2014. From WordPress onward, through a handful of CMSes, none of them have made me money. None have been wildly successful. All of them taught me more about running a real service on the internet than any job ever did.

Hosting forces you to see the full stack. Before you see a working page, you need three things:

A domain
A server
A CMS

After that, the web opens up with endless possibilities to tinker. To name three:

Web development. I started because the theme didn't have a contact form. Then I wanted a landing page. Then I wanted the whole layout rewritten. Within a few months I could scaffold a component, wire up a build, and deploy without thinking. None of it was "job" work.

Web design. I'm not a designer. But running my own site meant the stakes were zero, so I designed anyway. I picked fonts. I argued with myself about spacing. I redesigned the nav three times in a weekend.

Something odd happened along the way: I became opinionated. I'd see a well-designed site and think can I do something like that? I started noticing other people's patterns, their hierarchy, their whitespace. I shifted from user to contributor, an active participant in the ecosystem.

Ops. The frontend was the fun part. Then came everything underneath, roughly ranked by how much each will ruin your day when it breaks:

Reliability. Is the site actually up? Does it stay up when you push? Do you know when it's not?
Security. Any open ports? TLS 1.3? Are your admin panels behind a login that a bot can't guess in an afternoon?
Performance. Is anything cached? How long is first paint? Are your images doing work they don't need to?
Observability. When things break, do you hear about it from your logs, or from a friend texting you "hey, your site's down"?
Accessibility. Alt text. Contrast. Semantic HTML. The baseline is cheap; skipping it is rude.

Every one of these is a specialization; every one is yours to obsess over or ignore. It's a gift and a curse.

Or Not!

Self-hosting isn't for everyone. Reasons to skip:

Money. Self-hosting is often more expensive than a managed blog once you value your own time. If you're counting hours, the math rarely works in your favor.
Time. Other side projects fail quietly in staging. A self-hosted site fails loudly, in production, at the worst moment. It asks for attention even when you have none to give.
Data responsibility. You own the data, which means you also own the backups, updates, abuse reports, and the incident when something goes wrong.

If any of those rings true, self-hosting isn't right for you. But I still think you should have a corner of the internet. Any of these will give you one without the operations tax:

Getting Started

If you're still curious, here's a rundown of hosting options.

If you haven't used AI for development, start here. A chatbot is the closest thing you'll get to pair programming with a patient senior web developer. Tell it your vision, let it walk you through the tradeoffs, have it vibe-code you through the parts that feel over your head.

Pick a Domain

Registrars that don't upsell you into a funnel:

Pick a .com if you can get one; a .co or .dev if you can't. Don't overthink it, you can always move a domain.

Pick a Host

For a real server: DigitalOcean, Linode, or Hetzner will rent you a VPS for a few dollars a month. If your site is static, Cloudflare Pages, Netlify, and Vercel have generous free tiers.

Pick a CMS

Pick one and commit:

Ghost for a modern blog with a good admin
WordPress if you want every plugin ever made
Jekyll, Hugo, or Eleventy if you want static output and don't mind the build step
Whatever you vibe-code yourself if you want to learn the most

You can (and probably will) migrate later, so pick one to get started.

Your Corner

The best reason to host your own site isn't cost, control, or credibility. It's that the web stops being something that happens to you and starts being something you make. You stop reading the internet and start writing it.

That's worth more than any plan.

Sunday, 3 May 2026

, & Illya Starikov

Technology