cat posts/2026-01-05-what-im-betting-on-in-2026.md
What I'm betting on in 2026
On New Year’s Day I went through the folder where my side projects live and counted the ones that didn’t exist a year ago. There are 34. Most of them are under 500 lines, a few are single scripts, and two are things I now use every day: a tool that reads my bank’s CSV exports and tells me which subscriptions went up in price, and a small web page that shows me which of my notes link to nothing. I wrote by hand maybe three of the 34, and only parts of those.
That folder is the reason this post exists. I don’t usually do predictions, partly because the ones I made in the past were wrong in ways nobody wanted to read about, and partly because a list of predictions with no numbers on it can’t be wrong at all. So these come with a percentage each, and I’ll look at them again at the end of the year.
1. Review is where the engineering happens (85%)
By the end of 2026 most engineers on my team will spend more of their week reading code than writing it. I think that’s already true for about half of them. Since the summer every PR says how it was made, and in December about 80% of merged PRs said “agent with approvals” or “agent unattended”. A year earlier the column didn’t exist, because there was nothing to put in it.
What I’m betting on here is the consequence. The engineers who’ll be most valuable at the end of the year are the ones who can look at a 400-line diff that passes every test and say what’s wrong with it. That’s always been a senior skill, and we’ve never hired for it directly. I wrote in June that the converts who stopped reading the diffs worried me more than the skeptics, and nothing since has changed my mind.
2. My team doesn’t get bigger, and doesn’t get smaller (60%)
We’re about twenty engineers, roughly where we were a year ago, and we shipped noticeably more in 2025 than in 2024 by any measure I trust (which isn’t many). The obvious question from the rest of the company is whether we need twenty. My answer is that the work moved instead of shrinking. There’s more of it on the reviewing and deciding side, and that side doesn’t go faster just because the typing did.
I’m only at 60% because I can see two ways I’m wrong. Either agents get good enough at review that one senior person can oversee what three do now, or the company decides it would rather find out the hard way. I don’t think either happens this year. I’m less sure about next year.
3. Someone on my team replaces a SaaS product with something we wrote (70%)
This one comes from my folder. When a tool that does exactly what you need costs an afternoon, the math on a lot of small subscriptions changes. We have a vendor list (the spreadsheet, of course), and there are at least four products on it where we use one feature and pay for forty. I think one of them gets replaced by an internal tool this year.
I’m also fairly sure we’ll regret one of these. Somebody has to own the thing after the afternoon is over, and patch it, and remember how it works when the person who asked for it leaves. Software that’s cheap to write is not cheap to keep, and I’ve been on the wrong end of that since long before agents. So the bet has a second half, which I’ll put at 50%: by December, at least one internal tool we wrote this year will have been quietly abandoned.
4. My agents move off my laptop (75%)
Most of my personal agent work happens on a laptop that goes to sleep when I close it, which is the wrong place for anything that takes an hour. At work we’ve had a sandbox for unattended runs since last spring, with no credentials in it and a short list of hosts it can reach. For my own projects I don’t, and I’d like to start something on Friday night, check on it from my phone on Saturday morning, and not have it anywhere near the machine that has my password manager on it.
I haven’t decided where yet. A spare machine at home, a container, a cheap server somewhere. I’ll probably write about that soon, because I’m going to have to think it through before I do anything.
5. I write less code by hand than any year since I was 13 (95%)
This is the safest bet on the list and the one I like least.
I started with Clipper and Turbo C on DOS, and for most of the thirty-odd years since, the part of the job I liked best was the hour where the code finally does what I meant. I still get that, sort of, when an agent and I get something working. It isn’t the same, and I’d be lying if I said I didn’t miss it. Last year I’d guess I typed maybe a fifth of the code I shipped on my own projects, and less than that at work, where I mostly review anyway. This year it’ll be less.
What I got in exchange is the folder. I’d estimate I get somewhere between five and ten times as much done on my own projects as I did two years ago, and the 34 tools are the evidence. The subscription tracker found $34 a month I was paying for things I’d forgotten about, which paid for the agent’s time in about two months. None of those 34 would exist if I’d had to type them, because none of them were worth a weekend. They were all worth an evening.
I’m going to try writing one small thing by hand each month, with the agent off. Partly to keep the skill, and partly because I want to know if I still enjoy it as much as I remember, or if I’ve been remembering Turbo C with the bad parts left out.