You can't tokenmaxx your way to an agentic operating model

For the past year, many engineering teams were encouraged to use AI tools, experiment widely, and report usage. Adoption charts climbed, and it looked like progress. Tokenmaxxing treated greater token consumption as evidence of transformation.

Then the bills came. Bloomberg's piece on the end of tokenmaxxing cited a survey in which 68% of 300 executives said that at least some AI initiatives had run over budget. It also described the resulting spending caps at Uber and, reportedly, Tesla.

That reads like a cost story, but overspending was a symptom. The backlash revealed the deeper problem: organizations had mistaken a tool rollout for a transformation strategy, without changing the engineering system AI was entering or designing an operating model to manage the transition.

Tokenmaxxing looked like progress because activity resembles transformation

Shishir Mishra, a Founder and Systems Architect (AI) who runs 166 agents at KORIX, notes: "Distributing tools produces activity, and activity is the thing that most resembles transformation while least being it." And the data backs it up.

In the 2025 DORA survey, 90% of respondents reported using AI at work, and more than 80% believed it improved their productivity. Yet adoption was associated with both higher delivery throughput and greater instability.

Plandek's Q4 2026 AI Adoption & Impact Benchmarks, drawing on data from more than 2,500 engineering teams, found that token consumption had increased approximately 10–13x since January 2025. Yet among agentic teams, a 16% reduction in Cycle Time translated into only around a 4% improvement in Lead Time to Value.

And Plandek's earlier 2026 Engineering Productivity Benchmarks, based on more than 2,000 teams, found that bottom-quartile teams using AI took more than 35 hours on average to merge a pull request, compared with under 21 hours for top performers.

These patterns reinforce an important point: AI amplifies the engineering system it lands in. Faster coding can accelerate delivery in a healthy system, but where workflows, reviews, or codebases are constrained, the gains can be absorbed before they translate into better engineering performance or business results.

That forces us to think more about why AI activity isn't translating into the impact leaders expected. Are agents being applied to the wrong tasks? Is faster coding just shifting bottlenecks further down the SDLC? Do existing roles, workflows, and controls need to change around this new way of working?

What an agentic operating model actually is

Successful transformation doesn't come from introducing new technology alone. You must consider how AI will fit into or change the way work gets done in your organization, starting with deciding where AI should assist, automate, or act with autonomy.

• Assistance keeps a person involved and in control of the outcome.

• Automation executes a defined task without requiring a person to perform each step.

• Autonomy lets an agent choose its own steps toward a goal, within bounds you set.

Each needs different workflows, permissions, and oversight, and that's exactly what an agentic operating model defines. It makes explicit decisions about how agents work, assigns responsibility, and sets processes for review and governance.

But it also needs to account for the engineering system around those agents: whether repositories are ready for agentic work, whether reviews and releases can accommodate increased output, and how leaders will measure whether AI is improving performance.

Without that operating model, you risk scaling AI activity and costs without improving outcomes.

Joe Phillips, author of the Hybrid Workforce Standard, compares skipping this step to hiring before defining the job: "No serious company hires someone first and then holds a meeting to decide what to do with them."

The agentic operating-model map: 5 decisions every CTO has to make

Consider these 5 decisions to think about how agents fit into your organization's software delivery. Context determines the answers.

1. What work should agents do?

Just because an agent can perform a task doesn't mean it should.

Jeet Pattanaik, Founder and CTO of Glokal AI, draws the line at failure cost: "Agents do the work where being wrong is cheap and obvious." That could include scaffolding, test generation, and well-tested refactoring.

Similarly, he recommends that "Humans keep anything where being wrong is expensive or quiet." Think data models, credentials, and changes whose failures stay hidden until later.

But failure risk is only one side of the decision. Safe isn't the same as worth doing. A second filter is whether assigning the work to an agent actually relieves a constraint or improves how work moves through the delivery process.

Plandek's benchmarks, for instance, identify review as a potential constraint that emerges as coding speeds up. Bottom-quartile teams using AI take more than 35 hours on average to merge pull requests. For these teams, using agents to produce more code could worsen the existing review backlog instead of relieving it. But applying an agent elsewhere, for example, to perform an initial review before someone steps in, might relieve the bottleneck.

So the decision isn't just about what AI can do, but what kind of tasks it can meaningfully improve, and whether the consequences of getting it wrong are acceptable.

2. How much autonomy should they get, and on what basis?

A model can be confidently wrong. Granting autonomy based on confidence alone can let faulty changes reach production unchecked. According to Pattanaik, actions that can't be cheaply undone need human sign-off.

Reversibility, however, isn't the only consideration. Potential impact matters too because even a reversible change could disrupt a critical service. Tasks like repository access, pull request creation, and deployment authority, therefore, warrant separate consideration. Bhaskar Bharat Sawant, Lead Engineer and Solution Architect at Cornerstone Building Brands, says: "Each step up in authority should require a separate approval decision."

Importantly, decisions about autonomy and authority shouldn't be treated as permanent. Evidence from representative tasks can inform quality baselines and thresholds, while teams need to define "demotion triggers" for reducing autonomy when those thresholds are no longer met.

For example, repeated out-of-scope changes might move an agent from creating pull requests to proposing patches for review. A newly sensitive deployment environment could also justify withdrawing release permissions.

Changing permissions, therefore, requires both evidence and someone accountable for granting, restricting, or restoring them.

3. Where does human accountability come into the picture?

Delegating work, even with complete autonomy, doesn't remove human accountability. "The person who merged it owns it, exactly as before," Pattanaik says, "and I'd resist any model where 'the agent wrote it' appears in a post-mortem as an explanation." His objection concerns using AI authorship as an excuse for an incident; understanding the agent's contribution remains necessary.

But accountability also needs to be separated across the workflow.

A workflow owner governs scope, permissions, performance, and suspension, while individual approvers assess changes; recording what they approved separates their responsibility from workflow ownership.

Srinivas Chippagiri, Senior Member of Technical Staff at Tableau, describes another useful separation: "The agent that writes a fix isn't the one that reviews it." Independent checking supports assurance; people remain responsible for approval rules and consequential decisions.

4. How do we get from delegation to assurance to release?

Delegating work to agents shifts human effort from producing changes to verifying them. Review and assurance become more important because people remain accountable for work they didn't create, and plausible output can still contain errors.

Pattanaik's team, for instance, documents intent before delegation so reviewers can assess the result against it. The agent then prepares a branch and pull request with test results and unresolved uncertainty, giving humans the evidence they need to make an assessment.

Human review, security checks, and release controls then determine whether it proceeds or needs correction. But assurance only works if reviewers have not only the context, but also the capacity and authority to judge changes. If workflows are cumbersome, they risk being bypassed. Pattanaik warns: "They fund the policy and not the paved road, then wonder why people route around it."

This is where context and harness engineering become critical: giving agents the right information, specifications, and environment to work effectively, while building reliable checks and controls around their output. Otherwise, faster code generation can simply create more work for already-constrained reviewers.

5. What signals tell you to scale, adapt, or stop?

Anthropic's 2026 Agentic Coding Trends Report found that developers were using AI for roughly 60% of their work, yet reported being able to fully delegate only 0–20% of tasks. That gap makes review effort worth tracking as agent use expands. In addition to this capacity signal, equipping CTOs with quality and delivery signals can help them determine whether to scale, adapt, or stop using an agent.

For example, a combination of faster delivery, stable quality, and manageable review effort supports scaling. Meanwhile, rising overrides or rework might prompt teams to adapt tasks, permissions, or review support.

Rubber-stamping calls for governance intervention, and potentially a pause. But a complete stop could be justified when, despite redesign, agents repeatedly fail required tests or checking and correcting their output consistently takes longer than completing the task manually.

Crucially, leaders need to look beyond individual agents to understand what's happening across the engineering system. Are teams using AI effectively? Is review capacity absorbing the gains? Is higher AI contribution improving engineering performance, or simply increasing output and rework? And is the additional token spend producing a worthwhile return?

These questions require leading indicators, not just lagging delivery metrics or AI usage reports. Tracking adoption depth, how agents are being used, repository readiness, review friction, and developer trust can reveal where to intervene before constraints undermine performance. These signals then need to be connected to engineering outcomes and the economics of AI adoption.

This is the thinking behind Plandek's AIRadar™. Built around the RACER™ Framework — Rollout, Approach, Constraints, Engineering Impact, and Results — AIRadar brings together leading indicators from across AI tools and the engineering system. It gives engineering leaders one place to manage the AI transition, identify what's holding back impact, and act to improve engineering performance and AI ROI.

The point isn't simply to report whether AI is being used. It's to manage whether that investment is working, and what needs to change when it isn't.

Treat the model as a program, not a policy document

For organizations that have already ramped up AI activity, a useful starting point is to list the agents already in use, the systems they access, and their owners. That inventory shows where ownership or permissions are unclear.

From there, redesign one workflow at a time rather than trying to transform the entire engineering organization in one go. Pavel Bantsevich, Head of Partnerships and Project Manager at Pynest, says, "If no one's role changes, nothing ships past the pilot. Start with one workflow, prove it, then use it as the template for the next."

Before the pilot, define a manageable scorecard combining leading indicators with engineering outcomes and cost, rather than measuring tool usage in isolation. Plandek's Four Pillars of Engineering Productivity provide a balanced way to assess engineering health across Focus, Speed, Predictability, and Quality, helping leaders determine whether agentic ways of working are improving the wider delivery system.

Workflow changes also require training and reskilling. As agents produce more first drafts, engineers need time to learn how to direct agents and review their output. Bantsevich says: "A strong engineer is not automatically a strong reviewer of machine-generated work."

Finally, treat your agentic operating model as iterative, and continue to revise it as you learn where agents improve outcomes and where they create friction.

Make the next proof of progress about delivery, not adoption

Tokenmaxxing's overspending issue is a symptom of a deeper problem: treating uncapped AI rollout as a transformation strategy instead of changing the engineering system around it. AI can accelerate software delivery, but it can also amplify the constraints already preventing teams from performing at their best.

An agentic operating model makes the missing decisions explicit. It defines agents' scope and authority, human accountability, assurance, and the signals that determine when to scale, adapt, or stop.

But the model shouldn't become a static policy. CTOs need to manage the transition continuously, using leading indicators to identify where AI gains are getting stuck and what interventions will improve the outcome.

Ultimately, the measure of progress isn't how many agents are deployed or how many tokens are consumed. It's whether AI is improving engineering performance and delivering a stronger return on investment.

Explore AIRadar™ to see how Plandek helps engineering leaders manage the AI transition, from rollout to results.

Contributors

• Shishir Mishra, Founder and Systems Architect (AI), KORIX

• Joe Phillips, author of the Hybrid Workforce Standard

• Jeet Pattanaik, Founder and CTO, Glokal AI

• Bhaskar Bharat Sawant, Lead Engineer and Solution Architect, Cornerstone Building Brands

• Srinivas Chippagiri, Senior Member of Technical Staff, Tableau

• Pavel Bantsevich, Head of Partnerships and Project Manager, Pynest