DEV Community: Malisa

Claude Code Experiment: More Tokens Doesn't Mean Better Code

Malisa — Wed, 14 Jan 2026 01:05:10 +0000

As we kick off the new year, many companies are full speed ahead on leveraging AI tooling for productivity. In fact, some companies are looking at token usage as a way to assess AI adoption and productivity. As I began my own exploration of the Claude Code CLI, I couldn't help but wonder...are tokens the new lines of code; easy to count, impossible to trust?

After taking Anthropic's "Claude Code in Action" course, I developed an experiment to test my new knowledge. My hypothesis was simple: Claude Code features follow a diminishing returns curve. At some point, more tokens don't return better code.

My Experiment: Build a good ol' toy app, CLI Tic Tac Toe, four times, each using a different Claude Code technique. For each build, I logged token usage, created a QA agent to find bugs, and created a prompt to assess code quality. Then I used these data to create a metric: quality per token (QPT) and compared the QPT per technique to test my hypothesis.

The Four Techniques for building Tic Tac Toe:

Zero-shot: Raw prompt, no context
Plan Mode: Explicit planning step before execution
CLAUDE.md: Project context file, no planning
CLAUDE.md + Plan Mode: Combined approach

I used claude --verbose to track token usage.

Note: I used a fresh Claude session for each experiment.

Experiment 1: zero-shot prompt
> Can you create a CLI tic tac toe game using vanilla javascript with minimal dependencies. I would like it to be tested using jest and I would like it to be good quality code using classes.

Experiment 2: Plan Mode

> --plan <Same Prompt from Experiment #1>

Experiment 3: CLAUDE.md context file
I created a file in the project directory like this:

and ran it:

> create the game

Experiment 4: Same CLAUDE.md file from Experiment 3 + plan mode

--plan create the game

Assessing Quality: Role based prompt
> You are a senior engineer, can you assess this code for quality and give it a score code 1-5 on correctness, clarity, structure, maintainability, and extendability? Can you return an average of the scores?

Manual QA Agent
I created a test.js file and added context for the agent to play 10 TTT games and report any bugs found. All four iterations reported zero bugs.

Notes:

This experiment was designed very small for fast understanding using a well-known problem.
This experiment used a lot of AI, but that was by design. I wanted to understand the tooling and token use, not how to build TTT... I've done it many times 😉.

Results

Approach	Tokens	Quality	QPT
CLAUDE.md	25,767	4.9	0.190
CLAUDE.md + --plan	32,191	4.6	0.143
Zero-shot	42,737	4.8	0.112
--plan	52,910	4.8	0.091

Conclusion

My assumption was partially true, the least expensive approach was also the best quality. As tokens increased, quality stayed flat or dropped. However, I didn't anticipate that the lowest token investment returned the highest quality.

My colleague Rani recently wrote:

"Context is Currency... In the world of AI, if you don't give the model the right background and constraints, it will confidently give you the wrong answer."

In this case, less context meant lower quality for more tokens.

I suspect the next wave after AI adoption will be understanding optimization and return on AI investment.

Some of the earliest company wide AI adopters are already weighing in:

For AI models, context matters more than token use. I'm interested in digging into context engineering next, it seems that well structured context yields better results than simply feeding more tokens to the model. It really does seem like an art.

🖼️ Cover Art: "Urania" depicted by Giacinto Gimignani, 1852

Duck Typing: What do ducks have to do with polymorphism?

Malisa — Fri, 13 Mar 2020 13:39:51 +0000

I have been reading Practical Object-Oriented Design in Ruby aka "POODR" by Sandi Metz. The book is coveted and frequently referenced as a beacon for establishing good software design habits. I just made it through chapter 5: "Reducing Costs with Duck Typing." POODR is very detailed and helpful; however, as a beginner I needed more examples to grasp the concept. I went on a journey through the internet and found endless resources that said "If it talks like a duck..", you know the rest. Once I had an 'aha' moment the phrase made more sense, but before that moment I was like:

Each resource was tangential to my goal of understanding duck typing, especially the hot debate between static and dynamic language users, y'all are serious. To get to the bottom of the duck typing concept, I have to start with some overarching concepts.

Dynamic vs. Static Languages

Sandi Metz wrote "..languages use the term "type" to describe the category of the contents of a variable...knowledge of the category of contents of a variable or its type allows an application to have an expectation about how those contents will behave."

Statically typed languages such as Java type-check before run time.

Basically static languages do some pre-flight checks before turning the human written code (source code) into code that the computer understands (machine code). This is advantageous because larger programs can run faster since all of the safety checks have been done. Another advantage is that visible type information can serve as documentation in the source code.

Dynamically typed languages such as Ruby type-check during runtime.

Dynamic languages are more spontaneous and take a laissez faire approach by type-checking when the code is being executed. No compiling and a more lax syntax are some advantages to using a dynamic programming language.

Need more info?

If you are still learning or need a refresher about the differences between dynamic and static languages here is an excellent resource.

Polymorphism

Polymorphism translates to "many forms." In programming it is the ability of an object with different types to be handled by a common interface.

The concept of polymorphism is not a novel concept in programming. The concepts are referenced as early as
Carl Hewitt, Peter Bishop & Richard Steiger's proposal paper for A Universal Modular ACTOR Formalism for Artificial Intelligence in 1973.

"One way to build an ACTOR machine is to put each actor on a chip and build a decoding network so that each actor chip can address all the others."

Static Polymorphism aka compile time polymorphism in languages such as Java have interfaces that have special contracts on how to interact with other classes. One implementation of polymorphism is called method overloading which allows a class to have more than one method with the same name. Another implementation is called method overriding, which allows a method declaration in a sub class contained inside a parent class. Methods in static languages only work correctly if they know the classes and types of their arguments.

Dynamic Polymorphism aka runtime polymorphism in languages such as ruby refer to the ability of different objects to respond to the same message signature (method name and specified parameters). One example of dynamic polymorphism in an object oriented language is called "duck typing."

Duck Typing

What is it?

Duck typing is a programming method that allows any object to be passed into a method that has the method signatures expected in order to run. In short, it's not important what an object is, rather what it does. Objects of different types can respond to the same messages as long as they have the specific method behavior. It solves the certain design qualms such as large cases statements and dot methods such as .is_a or .respond_to? that can potentially cause software rot. Essentially allowing your code to rely on public interfaces rather than object types allows for flexibility and change over time.

How does it work?

Example:

The implementation of the Cook class on the left is very rigid and resistant to change. The implementation on the right is an example of duck typing. The Cook class calls the method prepare_recipe and passes in the objects that allow each individual class to handle their own business logic. The classes don't have to keep track of another class's methods allowing for clean flexible interfaces.

TDD Implementation

Recently, I used duck typing to build better Rspec tests by stubbing out a fake console. Instead of relying on user input in the console I added a Console class and a FakeConsole class. Each class contained the same methods signatures so they would behave the same when testing the generate_primes method.

Alex Martelli summed it up well when he said "You don't really care for IS-A-- you really only care for Behaves-LIKE-A-- so, if you do test, this behavior is what you should be testing for."

Conclusion

If you stuck with me up to this point, thanks for reading. I have more topics to explore to reach full enlightenment, such as other implementations of polymorphism and statically typed language interfaces. Feel free to leave feedback or helpful comments 🙃 Cheers

Duck Typing Enlightenment