Salesforce AI Research engineer Ben Stolovitz says he spends about $3,000 a month on model tokens and manages roughly five to six coding agents during his workday. In his October 2026 workflow review, he describes software that writes code, runs tests, and creates and reviews pull requests.
He is also drafting a personal AI policy. His goal is to decide where these tools support his ambition to make things with other people, and where they get in the way.
That combination makes the review useful beyond its eye-catching spending figure. An enthusiastic user is drawing boundaries around delegation, including in research and engineering, where he relies heavily on AI.
The post is a self-reported account, explicitly framed as opinion and speculation. Its performance claims are anecdotes, not independent measurements. Read that way, it offers a practical case study in auditing AI use without treating every successful task as permission to automate the next one.
His Job Changed Alongside His Tools
Stolovitz’s previous annual review came while he worked on Microsoft’s Windows AI team. He now identifies himself as a research engineer at Salesforce AI Research, supporting scientists and building rapid prototypes more often than working with a large engineering team.
That change matters when interpreting his workflow. A prototype-heavy role creates opportunities to try an implementation, inspect the result and discard it. His account cannot separate the effect of better tools from the effect of different work.
His coding routine has nevertheless changed substantially. GitHub Copilot autocomplete previously helped him write code line by line. Now, he says, he assigns features, bug reproductions and other tasks to agents using tools such as Claude Code, OpenCode, Codex or Pi.
Each agent gets its own Git worktree: a separate working directory that lets it work on a version of the code without placing every agent’s edits in the same directory. This makes parallel development more manageable, although the resulting changes still need evaluation and integration.
Stolovitz reports that agents can produce feature prototypes in about 20 minutes. He describes using them to investigate audio code on macOS and iOS, fix urgent bugs while he works on something else, and experiment with improved noise cancellation in his Mumble client. These are his reported examples, not a general turnaround guarantee.
The practical shift is from composing code to specifying tasks and supervising several attempts. That can expand how many ideas a person explores, but it also changes what consumes their attention.
Fast Code Still Needs Engineering Judgment
“Writing code is solved,” Stolovitz declares in the review. His subsequent examples put a substantial boundary around that statement.
He says unattended agents can produce poorly functioning, overcomplicated and unreadable software. Human judgment remains important for choosing a design, recognizing unnecessary machinery and deciding whether a result is worth keeping.
His strongest counterexample comes from his own work: he describes hand-writing a tool that replaced roughly 4,000 lines of AI-generated code with a few hundred. He says the replacement was more flexible, easier to test and more generalizable.
Those two observations belong together. Agents helped him generate implementations quickly; a human-written redesign later removed much of one implementation. The review therefore supports a distinction between speed to an implementation and quality of the resulting system. It provides no independent measurement of either, but it illustrates why they should be evaluated separately.
I’d treat the replacement tool as the more consequential detail than the 20-minute prototype claim. A fast first version is valuable when it helps answer a question. Keeping that version can become expensive if its complexity makes every subsequent change harder.
Stolovitz also reports a less visible cost: managing several simultaneous conversations is overstimulating and exhausting in a way that writing code was not. Early on, he felt pressure to answer agents as though human colleagues were waiting for him.
That suggests a useful operating limit. The right number of agents is the number whose work a person can meaningfully review, not simply the number they can launch. Parallel execution helps only while supervision remains effective.
What the $3,000 Figure Actually Tells Readers
Stolovitz describes approximately $3,000 per month in token spending. Tokens are the units models use to process and generate content; the figure should not be read as a $3,000 consumer subscription.
The review excerpt provides no itemized allocation by model, task or project, and does not identify who pays the bill. It therefore cannot support a coding-versus-research cost breakdown or a return-on-investment calculation.
What it establishes is the scale of his reported usage. He describes a workday built around multiple coding agents, alongside other AI activities.
For readers considering a similar setup, the useful accounting question extends beyond the model bill. How much time goes into task definition, reviewing output, resolving conflicting changes and replacing unsuccessful work?
My view is that an AI budget should track those costs alongside spending. A workflow that produces more code can still be a poor trade if it leaves its operator with an unmanageable review queue. Conversely, a disposable prototype may justify its cost if it quickly answers an important question.
Teaching and Novel Research Get Different Verdicts
Stolovitz’s experience outside coding shows why a personal policy needs more detail than “use AI for research.”
According to LavX News’s summary of his review, he is especially enthusiastic about AI as a teacher. Examples include learning how to fine-tune Mistral to speak like a pirate, practicing responses to emergency medical services calls, and exploring approaches to semantic endpointing for voice agents.
Semantic endpointing concerns deciding when someone has finished a conversational turn. It is a useful example of a task that can involve both learning established concepts and investigating an unresolved design choice.
His experience with novel research was less positive. LavX reports that, while working on turn detection, AI helped him locate research and datasets but led him astray when assessing possible architectures. He also describes spending days discussing training-data annotation with models before a conversation with a human teammate made the problem seem straightforward.
The distinction is consequential. A system can help explain known material while being a poor judge of whether a research direction is promising. Fluent explanations do not automatically make it a reliable collaborator on an unfamiliar problem.
Stolovitz describes an “AI fog” in which reviewing responses requires more effort than developing his own answer. A practical stop condition follows from that account: when successive exchanges add interpretive work without resolving uncertainty, change the method. Read the underlying paper, sketch the problem independently or involve a knowledgeable colleague.
His Other Uses Have Narrower Boundaries
The LavX summary describes a varied set of preferences across search, transcription, writing and creative work. These are individual choices, not evidence that a particular product or category will suit everyone.
| Activity | What Stolovitz reports | Useful distinction |
|---|---|---|
| Search | Google’s AI summaries are generally decent, while product search remains untrustworthy to him. | Retrieving an answer and making a good recommendation are different jobs. |
| Summarization and transcription | He considers both dependable and describes using local models on his computer. |
Frequently Asked Questions
3 questions
1Is $3,000 the price of his AI subscription?
No. Stolovitz reports approximately $3,000 per month in model-token spending. The evidence does not provide a complete bill, allocation by tool or payer.
