Token Maxxing Is Over and Here Is What Comes Next
Pepijn Senders, a principal engineer and former AI enablement lead at HelloFresh, explains how his team rebuilt a banking platform in six months with about 800,000 lines of code, mostly written by Sonnet, and why choosing a model that keeps developers involved matters more than raw autonomy. He covers measuring AI ROI through token spend versus output, keeping humans in control of code, the risks of agent recommendations, team refinement sessions, prompt word effects, and a meta harness built on Claude Code.
Sonnet maxxing: choosing the model that keeps engineers in the loop
Pepijn Senders argues that the right model is the one that keeps developers thinking, not the one that does the most on its own. Opus will happily take a broad request like ‘go build this transaction engine’ and run with it, but on banking software full of hard business rules, a more autonomous model tends to produce work nobody on the team can fully account for. Sonnet reasons less and stops sooner, which forces the developer to steer, weigh trade-offs, and bring domain knowledge in at the right moments. That is the idea behind what he calls ‘Sonnet maxxing.’
His team rebuilt an entire platform in six months with a group of about 50 people, producing roughly 800,000 lines of code, about 60% of it written by Sonnet, with some Opus and occasionally Haiku. The platform launched two days before the conversation. There were gaps, but people had stayed engaged throughout, which he considers the real achievement.
Adoption turned out to be easier than expected. Nobody ran an evangelism campaign. Engineers already had GitHub Copilot and had barely touched it, so the jump to a tool that asked clarifying questions and produced small, reviewable pieces of code was a small step. Trust grew from there, and token spend rose as people started to see what the tool could do.
Proving the ROI of AI coding
Pep is persistent about measuring AI’s return, and he points out that the ’token maxxing’ period, when teams spent freely, cannot last under enterprise billing and CFO scrutiny. At HelloFresh, he built a dashboard that compared engineering output before and after a clear cutoff date when AI tooling was adopted, which made the productivity difference visible.
He is skeptical of raw line counts, which tell a poor story. A more useful lens is to pick a specific feature, such as a new home screen, and track how much time and how many tokens it consumed. That raises an uncomfortable question: if the screen is maybe 1% more valuable, was it worth $20,000 in tokens? He is clear that such numbers should start a conversation rather than trigger punishment. A high-spend, high-impact bet can be worth it, and a low-value one may not be.
He also reframes productivity. Instead of claiming a team is two or three times faster, he asks how many engineers the work would have required before AI. If 40 engineers would have been needed and 20 now suffice, the saving of 10 to 20 headcount is the return. He acknowledges the false dichotomy in this: organizing 40 people is not the same as organizing 20 people who use AI, so the comparison is imperfect.
His own failure at HelloFresh taught him something. The company was intensely product-driven, with every funnel A/B tested and every work item measured by customer value. Pep argued for AI in terms of speed and productivity, but he never connected it to the features the business cared about most. In hindsight, the story should have been something like ‘if we put AI on this feature, we ship it twice as fast.’ He is now much better at framing ROI that way and at focusing token spend on the bets that can produce outsized returns.
Token spend versus output
The scatter chart he likes most plots token spend on the x-axis against output on the y-axis, measured in features shipped, lines shipped, or pull requests merged. It reveals outliers in both directions. One engineer might spend $20,000 while shipping a million lines a month, while another spends $15,000 and merges a single PR in four weeks. The second person might be doing valuable research, which is exactly why the chart is a starting point for a conversation rather than a verdict.
He is also candid about what the spend revealed early on. A large share of usage, by his estimate around 30%, was personal: résumés, dating advice, and personal side projects, all charged to the company. He does not want to penalize anyone, and he points out that people using tokens on personal projects may be learning in ways the metrics can’t see. He also suggests that companies should share these metrics openly rather than simply writing large checks to AI vendors each month.
Keeping humans in control of the code
Pep’s most serious concern is what he calls unknown unknowns. As agents write more code, teams can lose track of what the system does. His test is simple and can be run on any repository: open the codebase and stop at the first function you cannot explain. Ask what it does, why it exists, and what business value it delivers. Even careful teams will find code nobody can account for, but he is confident that the search will not take long. In critical systems that handle customer data, that gap is a ticking time bomb, and problems often surface only in production.
He also describes how models can drift away from what the team actually understands. Some outputs, especially from newer models, ask questions that the engineer cannot follow, and the easiest response is to accept whatever looks plausible. His team tracks when humans steer away from the model’s suggestions and when they accept them, using dashboards to see which teams intervene more and less. Steering is treated as a signal to examine, not as a score that is automatically good or bad.
The recommended option trap
An agent that offers a menu of choices and recommends one is subtly narrowing the decision. When you do not have the energy to explore alternatives, you follow the path the model suggests. Pep points to an authentication problem he investigated in a postmortem, where the ADRs and code showed choices that seemed to have been made without much scrutiny. The model did not decide for the team, but its framing did. Engineers who work one-on-one with an agent are especially prone to repeatedly accepting its recommendations.
Multiplayer refinement sessions
To restore agency, his teams now run refinement together. Each feature begins with a product brief or PRD that is ingested by the agent. On Mondays, the team gathers, often with product and UX people present, and works through the agent’s questions live on a shared screen. The model surfaces the hard parts of the requirements, such as the places where the existing codebase would make implementation difficult. This brings back the role of the engineer who raises a hand and says a feature is too hard to build, and it shifts that discussion left, earlier in the process.
Group dynamics matter here. In a room, peer pressure makes people less likely to accept a suggestion just because it was recommended, and the product manager can steer the conversation. The team also keeps transcripts rather than full recordings, then uses an LLM to summarize the sessions, highlight the general direction, and show why a decision was made. Pep admits that he has not always understood past decisions well, but he sees this as a way to get ahead of implementation problems before they become entrenched.
Prompt words and designers writing code
An experiment shows how much small word choices shape output. Designers and front-end engineers were each given the same single-shot prompt to generate a page. The results looked similar on the surface, but the designers mostly produced a single HTML file with inline JavaScript and CSS, while the engineers built React apps. The difference came down to a few words in the prompts. Words like ‘scalable’ or ‘maintainable’ steer the model toward different architectures and patterns.
This matters more with Opus than with Sonnet. A wrong steering word in Sonnet stays small, while the same word in Opus can carry the model far in the wrong direction. Pep and a colleague describe these as magic words that place the model in the right latent space, and he argues that teams need to learn which words to use for which tasks.
His team applied this lesson by letting designers write code. They work in a dedicated repository where the context is set so that everything is written in a safer, stricter language than React, which makes mistakes harder to make. An output style then translates Claude Code’s responses into designer-friendly language, so a designer receives something like ‘I built your page, it’s done, find it here.’
A company meta harness on top of Claude Code
The team built a meta harness that orchestrates Claude Code. Pep is strict about what enters the context window. He describes a developer who installed every skill from a public repository, and the skills fought each other while the context was already at around 40,000 tokens before any work began. He wants control over what gets loaded at each step.
The harness was built after the team observed that 85% of their code followed the same path: refinement, specification, implementation, and verification. Because the artifacts from each stage were already recorded, they could measure this after the fact and then formalize it. Each stage now runs with an optimal context window and a specific set of skills, and the team can track token spend per stage for each task.
The mechanism is simple. The system prompt tells Claude to touch a particular file once refinement is finished. A watcher monitors that file, and when it changes, the harness closes the current session and opens a new one for the next stage. Metrics are captured at each transition, producing structured data about how work moves through the process.