How I use AI (November 2026)
Ben Stolovitz writes an inventory every October of how he actually uses AI. The 2026 edition is a really good read. It is specific, it says what did not work, and it will be worth more in a year than any prediction published this month.
So here is mine. I plan to write it again next November and find out what I got wrong.
Background
I use AI from two seats.
During the week I run device software engineering at Samsara: several teams, from firmware and edge AI up through the cloud, shipping to hardware that rides in commercial vehicles. On weekends I am one person with a stack of agents, a ten-year-old game called All Is Vanity, and a growing pile of smaller things.
I have been shipping software for other people for more than twenty years. In January my personal site was a dead CMS with Flash embeds that had not worked since 2020. Today the projects page has eight playable browser games, a comic maker, and a token dashboard, and all of them exist because of what follows.
The two seats disagree more than I expected. The weekend seat is where I find out what agents can do. The weekday seat is where I find out what it costs to trust them. Most of this post is the argument between the two.
I will go area by area, the way Ben does:
- Writing code
- Proving the code works
- Running an engineering organization
- Models and money
- Writing
- Art, sound, and video
First, the two rules that travel between seats.
Two rules I carry between seats
Verification first. Agents can write firmware, or a boss fight, faster than anyone can prove the result works. So proof is where the effort goes: harnesses, hardware in the loop, a check that would fail for the reason I care about. I have written about what an agent has to prove before I call it done, and I will not repeat it here. Everything below is that rule meeting reality.
Autonomy by risk. The question is never “do I trust the agent.” It is “what is the blast radius of this change, and who has to be in the loop at that radius.” A text fix gets the smallest check that means anything. A change to a boot chain gets a human, every time, forever.
Writing code
I do not type much code anymore.
The year started on a Saturday in February. I sat down with Claude Code to see how much I could get done in a day, and the answer embarrassed every estimate I have ever given. By the end of the day: my dead website resurrected as a Jekyll site with the old Flash demos running again under Ruffle, three old game-jam games ported from Haxe to Godot and playable in a browser, a tower-defense game built from scratch, and a 122,000-line Haxe game loading in a browser tab for the first time. About twelve hours of wall clock. 128 million tokens, 95 percent of them cache reads replaying the conversation to itself.
Two days later I built the game I had carried in my head since childhood. Space Taxi In Space: 8,143 lines of GDScript, 26 levels, four characters based on real friends, a speech synthesizer that sounds like a drunk Commodore 64, zero sprites. First playable commit 46 minutes after the first prompt. Finished in a day. The thing that had stopped me all those years was never ability. It was the 200 hours of evenings between the idea and the artifact, and that number is gone.
The ratio changed, not the work. I used to spend 20 percent of a project deciding what to build and 80 percent building it. Now it is closer to 70/30. The thinking is the job. The typing is handled.
All Is Vanity had been dormant since 2020. Between mid-February and the start of November its repository took 2,161 commits across 4,283 files, and I published the counting method because a number like that deserves a footnote. I did not type most of those changes. I chose them, bounded them, and judged them.
What agents still cannot do is share a working tree. In February I ran eight of them at once, organized by theme, all editing the same checkout. Commits ballooned, the levels stopped loading, and the root cause was a one-line null check buried in commits that touched dozens of files. The lesson has held all year: containment matters more than capability. Parallel agents are fine. Parallel agents in one tree are not. Give each one its own git worktree, or its own project, and the velocity is excellent; most weekends now have one session on the game, another on the comic maker, another on a game port, none of them able to see the others’ files. Let several of them own a theme in a shared checkout, and reliability drops fast.
My favorite failure was smaller, and it is the shared-tree problem in miniature. An agent finished a task with a compound shell command that ended in git stash. In a tree shared by four lanes of work, that one command swept 31 files of other agents’ uncommitted edits out from under them. A data file appeared to revert to the last commit while a build from minutes earlier still had the changes. Nothing was lost, but I spent the morning restoring files one at a time, because git stash pop refused to touch a log file the dev server was holding open. Agents now read git and never write it. Commits happen when I ask, staged by hunk, and nothing gets pushed by a machine.
The newest thing on the projects page is the oldest. TakeToon was a comic maker I built in Flash and PHP in 2008. In February an agent rebuilt it as a React and Node app. This month it got rebuilt again, with a drawing engine, art packs, a character builder, and export to GIF and video. Then I found out my shared host cannot run Node at all, so the backend was rewritten in PHP against the same API, and taketoon.com is back up this week. Eighteen years from Flash to live, with a long nap in the middle.
Do I miss writing code? Some. I still write some by hand on weekends because I like it, not because I need to. The thing I actually miss is the certainty that came with having typed it. That certainty was never as justified as it felt, which is the subject of the next section.
| Usefulness | Notes | |
|---|---|---|
| Agents writing code | 👍👍👍 | Eight games and two apps this year |
| Agents in parallel | 👍👍 | Own worktree or own project each |
| Agents touching git state | ❌ | Read-only, forever |
| Typing it myself | 👍 | A hobby now, and I am fine with that |
Proving the code works
This is where the hours go, in both seats.
For two days this summer my game’s overworld had animated water that was a painting. The agent that built the shader checked its work, and the check passed: frame diffs looked animated, because the day-and-night tint drifts a little every frame. Three fix attempts chased shoreline artifacts that turned out to be painted into the static fallback. The real cause was a one-line platform quirk: the shader filter renders once and caches, and nothing re-renders unless you invalidate it. I now have a rule for any “is it animating” claim: show me two frames half a second apart.
My other favorite: an agent writing the capture scripts for a trailer picked weapon number 19 for my lead hero, a scroll called Ecclesiastes, because it was “the on-theme payoff.” It was. It was also a weapon that hero cannot hold. The game silently drops an illegal weapon to nothing equipped, so a full trailer batch and an entire playthrough capture show him fighting bare-handed. No one looked at the first two seconds of a take. Now every capture must show the weapon icon in the HUD and the hero firing before it counts.
Both bugs taught the same thing I wrote in February after a week of identity drift: reminders are weak, executable constraints are strong. A rule in a prompt is a suggestion. A check that fails is a rule.
The weekday version of this story is better. On our core device products, an agent now tests every merge on real hardware and writes its own scenarios from the diff. A year ago, feedback on a firmware change arrived the next morning from the nightly run. It now arrives in a little over an hour. A new product reached full automated functional coverage in a matter of weeks. A root-cause investigation that had been open for months closed in a day once an agent was pointed at it.
The thing to be honest about is that agents test the way they implement: with the same misunderstanding. A test generated from a wrong model of the feature will agree with a wrong implementation perfectly. I wrote about this from the quality engineering side. The scenario and the assertion are still mine.
And “verified” in a chat report is a claim, not evidence. I have had verified changes that did not survive my first minute of playtesting. The fix was not a better model. It was asking for the build identity, the route, the action, and what was not exercised, every time.
| Usefulness | Notes | |
|---|---|---|
| Agents on real hardware | 👍👍👍 | The best thing we built this year |
| Harness-driven smoke checks | 👍👍👍 | The game has one for nearly every system |
| Agent-written tests | 👍 | Same blind spots as the implementation |
| “Verified” in a report | ❌ | Ask what ran, on which build |
Running an engineering organization
At work the question is not what one person can do with agents. It is what a large team can do with them on hardware that makes safety decisions on the road, with a release that cannot be rolled back by closing a tab.
So the autonomy is narrow by design. An AI reviewer that knows our firmware rules reads every pull request. I mostly agree with Ben about that reviewer: it catches bugs and style problems well, it cannot judge a design, and it is no replacement for a human. Its value is that it never gets bored, and a recurring mistake can become a rule it enforces next time. Small changes in a short list of low-risk paths can be approved automatically once the checks and the reviewer pass. Anything that touches boot, updates, or security always gets a human. Rollouts halt on their own. None of that is exciting, and all of it is why the exciting part is allowed to exist.
The exciting part is not code generation. The biggest gains came from the work around the code: an agent triages every nightly failure before an engineer sees it, a risk-ranked digest of the day’s merges arrives every morning, and agents answer diagnostics and coverage questions that used to cost someone an afternoon. We took on new areas this year without growing the team. That is the result I care about.
Here is the number I do not trust, and it took me a while to say so. Pull requests per engineer went up and to the right this year, a hockey stick on every chart. A chart like that proves agents make pull requests cheap, and nothing else. The question that matters is whether we are having more impact and getting more done, and a count of merges cannot answer it. Where agents have changed the workflow, the work takes a fraction of the time it did. Where they have not, nothing happened, and no number of licenses changes that. Pull requests were never the unit of value. Validated changes, time to hardware feedback, and escaped defects are.
So here is what “10x the org” actually means to me. Every team carries a backlog of features customers asked for that never made the cut, not because they were bad ideas but because there was never the time, the bandwidth, or the priority. That list is what the extra capacity is for. We are building things from it now that would have stayed on the list for years, and that is the version of 10x I will put my name on.
What changed for the engineers is the shape of the day. Less typing, more architecture, requirements, and judgment. AI tools are not replacing engineers. They amplify the ones who know what to build and why, and the gap between “can write code” and “can ship a product” got wider this year, not narrower.
One more thing from this seat. The AI I work on runs on a device bolted to a moving truck, on a tight power and compute budget. We spent part of the year making room for more models on hardware that is already in the field, and on sending less of what they produce to the cloud. Some of the most valuable AI decisions I made this year were about where the inference runs, not which model runs it.
| Usefulness | Notes | |
|---|---|---|
| AI review on every PR | 👍 | Bugs and style, not design |
| Auto-approval in low-risk paths | 👍 | Narrow on purpose |
| Agent triage and digests | 👍👍 | Gave engineers their mornings back |
| Agent hardware testing | 👍👍👍 | Overnight to about an hour |
| Pull requests per engineer | 😒 | Hockey stick, answers nothing |
| “10x the org” | 👍👍 | The unserved backlog finally gets built |
Models and money
I pay for the highest consumer tiers of two coding tools that I can justify, and I have hit the limits of both.
In February I ran eight agents, eight to ten hours a day, first on Claude Max and then on Codex Max, both $200 a month at the time. Claude burned its weekly allocation in two and a half days. Codex was at 75 percent after five. Between them that week they produced about 149 commits and 176,000 changed lines across four projects for roughly $92 of pro-rated subscription. I did the junior-developer math in that post and then spent the rest of the year learning why lines are the wrong denominator.
By May the limits had changed how I work enough that I built a tool to look at them. AI Spend Live reads the local usage logs and shows burn rate, the biggest turns, and session concentration. In one seven-day window I had pushed 7.4 billion tokens through 34 sessions, and a single session that had stayed open too long accounted for 44 percent of it. A long context has gravity. Every new prompt pays for all the history behind it. The rule I took from the dashboard is simple: when a session changes purpose, stop it and start a new one, and move the durable context into files.
In September I tried to run my weekend work like a budget airline. The frontier model would plan and review. Several cheap models would do the mechanical work in parallel. A medium model would take the multi-file slices in between. It lasted about two weeks. The cheap tier was cheap for a reason. Unsupervised, it produced asset sheets labeled as authentic that were not, balance math that fell apart under inspection, and commits that swept up other people’s hunks. The cross-tool hand-offs were worse: jobs died under load, line endings flipped, and “verified” did not match what I saw when I played. I collapsed everything back into one session, where the biggest model writes the brief and reads the diff and a cheaper sibling does the typing. The evidence chain stays in one place. That turned out to matter more than the per-token price.
Which is why I have stopped arguing about which model is better. The real metric is cost per validated feature shipped, and at this point the limiting factor is metered access to the tools. The price is so low compared with traditional programming that I am not going to take the time to do the comparison. I keep two subscriptions whose weekly windows reset on different days, so there is always something to work with, and I come back to Claude when I have the choice.
| Usefulness | Notes | |
|---|---|---|
| Frontier model to plan and review | 👍👍👍 | Worth every token |
| Cheaper model to implement | 👍👍 | Inside the same session |
| Bottom-tier models unsupervised | ❌ | Cheap for a reason |
| Watching the usage logs | 👍👍 | One session was 44 percent of a week |
| Comparing models | 😒 | Cost per validated feature, or nothing |
Writing
The draft is the cheap part. The rewrite is where I find out whether I believe the sentence, and most of a first draft does not survive that. Anything that ships under my name is mine to defend, so the rewrite is where the hours go.
Where AI earns its keep on writing is as a reader. I hand it a draft and ask what is unclear, what is unsupported, and what I would have to show to make the claim stand. It is good at that: specific, fast, and indifferent to my feelings.
Where AI has been useless is flattery. This week LinkedIn offered to rewrite my profile. The rewrite credited me with “patented vehicle-abstraction technologies,” a portfolio I do not have. The tool did not lie on purpose. It regressed to the mean of every profile it had seen, and the mean is a liar. I declined.
| Usefulness | Notes | |
|---|---|---|
| Reading a draft back to me | 👍👍 | Finds the unsupported claim |
| First draft | 👍 | Only if I rewrite it |
| Publishing it unread | ❌ | Not under my name |
| Editing for truth | ❌ | It rounds everyone up |
Art, sound, and video
No generated art ships in my game. That is the rule, and this is the year I finished enforcing it.
Early on, generated animation sheets stood in for bosses and enemies that had no finished art yet. They were useful as sketches: they told the artist what the move was and told me whether the fight read on screen. By September I had pulled them out of the shipped build. Where the artist’s frames exist, they are in. Where they do not, the fight runs without the flourish until they do. Four frames of one enemy’s dive are still generated, and they are on the list. In October I published a list of the 89 graphics the game still needs from the artist, each with a stand-in preview, so the brief is a picture rather than a paragraph.
Effects are where generated-looking art hides best, because particles are easy. In August I looked at two of my own effects and called them AI slop, and I was right. They have the look: too much glow, no silhouette, a palette nobody chose. People recognize that look faster than you think. Both are on the rework list.
The small games took the opposite route, and it is the one real art lesson of the year. Space Taxi and Squirrel Defense have zero image assets. Every taxi, squirrel, and star is drawn from code. That was not an aesthetic decision. If a game’s visuals live in PNG files, the agent cannot touch them. If they live in code, it can iterate on a chef hat as fast as on a physics bug. Procedural art is not AI art, but it is the art AI can help with.
The trailers contain no generated footage. Every clip is captured from the game, which is how we found the unarmed hero. The night sounds are mine too; the owl and the dawn birds are my own samples, and the one placeholder bed is a free human recording, not a model’s idea of crickets.
The exception is 3D. For a Roblox prototype I generated the models with an AI tool, and they were fine for a prototype. I tried the same for the game’s heroes and weapons and rejected it. The game stays 2D. That decision is about the product, not the tool.
| Usefulness | Notes | |
|---|---|---|
| Image generation as a sketch | 👍 | Tells the artist what the move is |
| Image generation as shipped art | ❌ | Never |
| Art drawn from code | 👍👍 | The agent can iterate on it |
| Generated video | ❌ | Not in a trailer, not once |
| Generated 3D | 🤔 | Prototypes only |
Conclusion
A year ago, a firmware change got its first hardware feedback the next morning. Now an agent tests it on the real device in a little over an hour and writes its own scenarios. Nine months ago my website was a time capsule and my game had been asleep for six years. Now there are eight games you can play, a comic maker that outlived Flash, and a repository with two thousand commits I chose and did not type.
What I did not expect is how little of the year was about models. The models got better on schedule. The work was containment, evidence, and deciding what not to build. The agents gave me speed; every hard problem was about direction.
Ben ends his post with the hope of using AI to help people make things together. Mine is narrower, and it is the same from both seats. I want the people I work with, and the person I am on Saturdays, to spend their time on judgment: what to build, what it has to prove, and when to stop. The typing was never the job.
See you next November.
Appendix: my subscriptions
- Claude, at the top consumer tier. Claude Code is where most of my hours go.
- Codex, also at the top tier, on a weekly window that resets on a different day than Claude’s.
- Gemini, occasionally, for cheap text work.
I keep more than one because the weekly limits are real and the work does not stop when one runs out. AI Spend Live is how I know where it went.