My Thoughts on Token-Maxxing: A Call for Learning, Creativity, and Real Impact Instead of Simple Token-Maxxing

Konrad Krajewski — Sun, 17 May 2026 16:13:50 +0000

Tokenmaxxing is an example of how a single parameter can push organizations toward either positive outcomes or harmful behavior.
How does the bad path begin? It starts very innocently. At the beginning, there is always a company-level initiative. Leaders and managers try to find the best way to optimize processes and boost company development. After 2025, there is mostly one direction - introducing AI tools.
So companies spend a lot of money introducing these tools, adapting them to their profile, and maintaining them. It is a significant investment. Over time, however, some disappointment may appear. There is neither massive optimization nor a visible boost in productivity. Of course, there is always some scale of improvement, as well as some scale of disappointment. Up to this point, there are no errors — this is simply reality.

The real problem may start afterward. At that stage, investigations begin to find where is the issue? Usually, the culprit is identified quite quickly — people who do not use the tools enough, or do not use them widely enough. What happens next? Pressure to use AI as much as possible. And this is where tokenmaxxing begins. Managers can easily see who uses AI tools the most. They may not check what kinds of problems people are solving; instead, there is only one visible parameter: token usage. The more, the better. But is it really?

As a result, people start burning tokens everywhere simply to avoid negative consequences — even for tasks where AI is unnecessary or where the AI-generated outcome is mediocre.This is the perfect recipe for disaster. And later it does not help when managers say that employees will not be judged by token usage. The show has already started, and stopping this snowball becomes very difficult. And from the employee’s perspective, there is always some kind of uncertainty: What can I do? How can I use it? What if I make mistakes? How will I find time to experiment? There are many more doubts, and it ultimately depends on the company culture how everything turns out.

I’m glad that the company I currently work for chose an experimentation-driven approach instead of simply following the tokenmaxxing approach.
During one week, we had an opportunity to experiment with AI tools at different levels and across different layers. We could split into different squads. There were no rigid rules regarding squad size or the types of employees involved. The idea was simple: experiment with AI tools as much as possible — but truly experiment. Define friction points, identify what works well and what does not.

From my engineering perspective, it was a great approach, and inspiring experience. In the team I was part of, we tried to implement a product-owner-defined concept starting from design and using spec-driven development. We used AI tools at every stage of the process. The high-level idea was to create a top-level specification with interfaces, while each developer in the squad could introduce their own sub-specifications for the area they were responsible for.

We ended up with the first draft of an MVP for our feature, as well as many AI-agent-related skills that can now be developed, improved, and used more broadly in our engineering work. At the company level, we could see how other teams approached problems and what they experimented with. Basically, we could learn from each other at both the squad and company level. But what was most inspiring, paradoxically, was that we cooperated as a squad more closely than we normally do. I could say that AI brought people closer together. And I think that should be the real idea. Inspiring, isn’t it?

AI tools should not separate people from the squad or team, pushing them toward working independently together with AI agents. The goal should be that AI tools help people collaborate more tightly, because we all know that AI still cannot replace human judgment, emotional intelligence, and creativity — at least not for now. Could there be a future where the product of a single human brain working with AI becomes better than collective human collaboration? Maybe. We will see. But that is a story for another time.

My main takeaway is that AI tools are great. We should use them, and we need to use them more. But nothing is better than collective human work. Instead of forcing people to use AI tools and judging their engagement based on a single parameter, it is far more important to create space for experimentation and making mistakes. Because only in that process, there is a space for improvement, development, and real growth.

Should I stay or should I go? Enums in TypeScript - error case study

Konrad Krajewski — Tue, 21 May 2024 11:35:00 +0000

The usage of enums in TypeScript is an ongoing debate. Voices for employing them as an integral part of the language can be found [Ref.], as well as those arguing against [Ref.].
Here [Ref.] you can find a very good set of bullet points which really convinces me why it is better to avoid enums in TypeScript.

Furthermore, depending on whether you are using enums or enum-like objects, you may encounter different errors if something fails. These for enums may not be straightforward to grasp at first glance. I experienced this once when, during refactoring, accidentally part of code was moved to the top of the module, resulting in the enum being referenced before it was defined. Below you can find a simplified example ( Object.values() method used to retrieve an enum properties is wrapped by the function):

function getNodeEnvValues(){
    return Object.values(NODE_ENV)
}

getNodeEnvValues()

enum NODE_ENV{
    DEV = "development",
    PROD = "production"
}

If you try to execute this code you will get a generic TypeError Cannot convert undefined or null to object.

At first, when I saw the error I was thinking why the object which I have passed to the method is undefined. Looking at the enum definition I was trying to figure out what is really going on there.
Then I realised that the error was telling the truth since the defined enum NODE_ENV has not been reachable for the method (it was undefined at that point). However, this error may be a little confusing especially when the code is more complex. We get this error because Typescript enums are transpiled to a self-invoking function which creates key-value pairs object and assignates it to a var.

On the other hand using enum-like object in the same situation, we will get a ReferenceError which helps to more straightforwardly identify the nature of the error.

function getNodeEnvValues(){
    return Object.values(NODE_ENV)
}

getNodeEnvValues()

const NODE_ENV = {
    DEV = "development",
    PROD = "production"
} as const

After executing the above code we will get: Cannot access ‘NODE_ENV’ before initialization. The reference error gives you precise information indicating that the variable hasn't been declared or is out of scope.

How about you? Are you using enums in TypeScript, or are you trying to avoid them?

DEV Community: Konrad Krajewski

My Thoughts on Token-Maxxing: A Call for Learning, Creativity, and Real Impact Instead of Simple Token-Maxxing

Should I stay or should I go? Enums in TypeScript - error case study