The Post-Tokenmaxxing Engineering Team

This article was originally published on LinkedIn and Substack.

For a long time, software was a scarce asset. Code took time to write, systems took time to be understood, and every meaningful change had to pass through the narrow gates of review, testing, deployment, and ownership. So when AI made code cheaper to produce, it was tempting to assume that the whole machine would speed up with it.

This idea was taken to an extreme by “tokenmaxxing” - the trend of maximizing spend on agentic coding tools. The thesis was simple: if agents are the future, then the teams willing to burn the most tokens will discover that future first.

After witnessing little public evidence of substantial output from the “AI software factories” or other agent swarms, the market is beginning to correct from usage-maximization toward cost control and output verification. If shooting tokens from the hip is not the way, then what is?

In this piece, I’ll cover a practical outlook on how an agile engineering team can still benefit greatly from adopting agentic coding without turning AI usage into a goal itself. The point is to ask where AI gives you breadth, where it gives you depth, and where it gives you nothing worth chasing.

More code, same physics

In agentic software development, if you don’t want to spin in place but deploy actually meaningful changes, you’ll hit some constraints. Some of them are:

• Not every layer of the system can benefit from more code
• There is often no structured queue of easily verifiable tasks to be done
• Your agent submitted 10 PRs, but now a human has to read it

These limitations will put you at a crossroad: do I accept them and build them into my SDLC or do I reject them and completely rebuild my practices with agents and speed in mind? What’s important is you often can’t have it both ways. You have to agree on a certain composition of speed and safety, and it has to add up to 100%, not a magical 200%.

Software is an onion

The easiest way to decide where agents belong is to map the layers of your system. Layers will grow and depend on one another. The most inward layers form the core. The core dictates how the more outward layers are shaped and so on.

At Saleor, we build a commerce engine (the core) and an ecosystem around it (apps, storefronts). The engine layers hide a lot of complexity: the business logic, the API, infrastructure - but it’s all nicely packaged and exposed under a clear GraphQL interface.

Around the world, there are thousands of businesses that rely on this piece of software. If Saleor’s core were frequently destabilized with vibe-coded PRs that lack understanding of the code and its impact, we could easily disrupt their operations. This is where we choose to be conservative.

But that does not mean you, as a developer adopting Saleor, have to be equally conservative. It’s actually the inverse: if you have high trust in this core technology and it prevents you from making expensive business logic errors, you can afford to get loose.

Let’s take a storefront. When building one around Saleor, there is often very little business logic the storefront owns. Authentication, checkout, payments, search, variant representation - that’s all provided by the Saleor API. The majority of the remaining complexity will be on the UI side.

That changes the risk profile. If most business logic is isolated from the storefront, the agent has less room to create expensive business errors. If it looks good, works fast, and successfully implements the contract with Saleor, you have a green light to go.

My general recommendation is the following: you don’t need to have one AI policy for the entire company and all its products. You can differentiate by taking into account: risk, impact, nature of work, language, and more.

Review the risk, not the diff

With or without differentiation, one thing is certain: you will end up with a shitload of PRs. And unfortunately, our ability to verify them didn’t grow in harmony with our ability to output them. We are the “weak link” that constrains the overall automation gains.

Not long ago, I was under the spell of “soon a new review paradigm will emerge that will make it better”. Maybe that’s going to be stacked diffs, code review platforms or another shiny tool. Unfortunately, for the most part, we see many people acknowledging the problem (“code review is the bottleneck!”) but not many proposing solutions.

So my advice is to stay pragmatic and accept the reality: if your goal is to push more agent-written code to production, you can’t expect to have the same level of understanding as if you manually crafted and verified each line yourself.

This, once again, makes it a decision time: speed over safety?

If you want to be somewhere in the middle, a suitable path may look like this:

1. Place focus on validating the product intent behind a PR, not implementation. Make sure you understand why we built this piece of code and make sure the author does too.
2. Put human review on the inner layers of the onion and deliberately spend less time on the outer ones. A human frontend engineer spending three hours reading Tailwind classes is usually a bad trade-off if the result can be visually inspected, changed in five seconds, and safely reverted.
3. The closer you get to the core, the more human attention becomes required. Allocate resources carefully. Make sure that payments experts are assigned to the payments part of the PR, not the optimizing useEffect usage in React part.
4. Blast AI code review on every PR if you can afford it. Let an agent check for common security, privacy, transactional, and regression risks. Treat it as another CI/CD signal to clear before merging, not as a replacement for ownership.
5. Acknowledge that the balance between you writing code and reading code changes in favor of the latter. Will your ability to successfully do your job deteriorate over time? Do you need to do a manual coding routine just so the coding part of your brain gets activated every now and then?

A YC-backed startup that is looking for its product-market fit will laugh at this. It has a limited window in which it needs to complete its search. Not enough experimentation or product development is more likely to kill them than bad code.

A company maintaining 35-years old banking system written in COBOL will laugh at this, too. In such critical infrastructure, the room for error is marginal. Relying on an unpredictable AI agent to do any in-code work is a blasphemous idea.

Most companies will land in the middle. I recommend being surgical with building your agentic coding practices, treating each case differently.

Measure verified change, not generated code.

Not every backlog is agent-ready

Parallelizing the execution of large numbers of product development tasks may end up being out of reach for many companies. There are several reasons:

• You need to have a strong conviction of what to build
• You need to have a reliable way to verify if it was built correctly
• You may need to measure the impact of the deployment (do users use the feature etc.)

Those constraints require time and human attention. Agentic coding can help around them, but it cannot scale them infinitely. Luckily, there might be other streams of work that are prime candidates for automation.

Bugs, security fixes, dependency updates, docs, and tests are different. They are often scoped, highly verifiable, and lower impact. If you can build a reliable harness that provides the necessary context and produces the right output in a feedback loop, this stream of work is the most likely to be automated first.

There is already a lot of movement in this space. Sentry Seer turns telemetry into debugging context and can investigate issues, identify root causes, and prepare fixes. GitHub Copilot Autofix applies the same pattern to security alerts by using code scanning context to suggest targeted patches.

The lesson is not that every product task should become an autonomous agent run. The first automation wins may come from work that already has a tight feedback loop: an error, a failing test, a vulnerable dependency, a missing doc page, a flaky workflow, a reproducible support case. The better the harness, the less the agent has to guess.

Build rails, not prompts

To call an implementation successful, you need to know the code the agent produced:

• is compatible with the rest of the system
• actually solved the problem

Congratulations, you are now a “software janitor”: you make sure the right context is surfaced and the results don’t add to the mess. You often build a system for the agent to understand how to do things and verify them, instead of doing the thing itself.

This is often called harness engineering - creating the scaffolding that increases the performance of a specialized agent compared to a general-purpose one. Since we don’t do manual coding anymore, the good news is that the agent can also build the scaffolding for itself.

Example: a support agent with production-safe tools

I recently implemented an example of that at Saleor. Part of my work is answering customer questions and verifying bug reports. The work is tedious and can go deep, but it is bounded: there are known data sources to inspect and known environments to operate in. So, of course, I had to create an agent that automates most of it.

I started by evaluating some of the steps I might take during an investigation:

• Checking on Slack if anybody has recently reported a similar issue
• Checking Linear for anything unique about this customer’s use case
• Checking docs and source code to see whether the customer hit a corner case
• Verifying the reported behavior on the client environment
• Reproducing (and often solving) the reported issue on a clean sandbox environment to rule out client-unique dependencies

To give similar capabilities to an agent, you could create tools or connect an MCP. But some of them are too specific for existing tooling to handle, so we have to build the rails on which the agent will operate ourselves.

A human support engineer will know that if you are interacting with the client’s production instance, you have to be extra careful, especially if you have write permissions. You don’t want to fire a mutation and accidentally change their tax configuration. On the other hand, on your own test environment, you can go wild and quickly burn through all evaluated scenarios. That’s two very different approaches to the same entity type: a Saleor instance.

For this reason, I’ve built a little CLI tool for my support agent that enforces these practices through code. It’s not “please please don’t break anything in a client environment” but instead “you can only use this tool to communicate with the Saleor API and it has different rules for working in production vs. a sandbox environment”.

Since the agent has to rely on the tool for the API communication, it has no available path to execute a mutation on a production environment because the CLI doesn’t allow it. The only way it could do so is if it went rogue and wrote a bash CURL (but for that, the line of defense is the permission policy in your coding agent).

The concept of different rules applying to production vs. sandbox environments doesn’t exist in the Saleor API itself; it’s agent-agnostic (as many existing systems). Building a custom harness gave us a way to enforce them and change how an agent interacts with the otherwise standard GraphQL API.

---

Tokenmaxxing was an interesting phenomenon, but it was never a complete agentic coding strategy. In the real world - especially if the current, heavily-subsidized token economy collapses - we have to be more tactical about how we use coding agents at scale. As of June 2026, deep expertise and ownership of critical systems, product vision and conviction, and accountability for risk remain human and organizational responsibilities.

And models will, of course, continue to get better. But good outcomes will still depend on the rails of your organizational culture, structure, and operations. You can start laying down these rails today.