What Tetris Taught Me About AI Decisions

I continue to use frontier AI tools to understand how product development is changing and how it will continue to evolve. Working in recommendations and search, I am interested in how we will build algorithms when these tools are readily available. Which decisions will we hand to a general-purpose model, and where will a conventional algorithm remain the better choice?

I knew Tetris did not need frontier AI, but it gave me a useful way to experiment with that question. The rules are explicit, the objective is clear, and I could watch the consequences of each decision. I built a small comparison harness so a conventional algorithm and an AI model could play beside each other, with the same rules and upcoming pieces. The target was to clear 300 lines and complete all the levels.

The project let me explore OpenAI’s Decisions API alongside conventional heuristics and general-purpose models such as GPT-6.1 Terra and Sol. In the final full comparison reported here, our Lookahead algorithm cleared all 300 lines. The Decisions API, using GPT-6 Luna, reached 125 lines before losing. The game kept moving while the model thought, so this result includes the effect of response time. The algorithm in that run evaluated placements for the current piece; it was a relatively simple baseline. The AI game made 331 successful requests and had an estimated API usage cost of about $0.93. The local algorithm made no paid model calls.

For Tetris, it was always clear that a conventional algorithm was the right approach. Tetris gives a specialized approach a considerable advantage: the rules and immediate consequences can be calculated directly. However, the game still gave me a working baseline against which to judge what the AI was actually contributing.

Working on Tetris also emphasized the importance of creating an efficient harness and providing the algorithms with the right signals and inputs to make decisions. Evaluating the complete product meant separating mistakes in our integration from weaknesses in the decisions themselves.

We supplied the rules, the board and the legal options, including the immediate result of each move. We continued to improve how we presented that information. We made the input more compact, described the consequences of a move more clearly, and added examples of planning ahead. A placement that looks reasonable now can make the next decision harder. We could already see the next five pieces, so the model had information about what was coming as well as the board in front of it.

I see a parallel with personalization and recommendation engines. Viewership history gives us one part of the picture. The device someone is using, the time of day and their location can add context. Genre and brand preferences help describe what they might want. Providing those signals gives a model more information to work with.

Richer context and stronger instructions did not produce a consistent improvement across the piece sequences we tried. Some changes helped one sequence and hurt another. For a personalization product, I want the same separation between an input that seems useful and an improvement we can demonstrate in the experience.

Cost becomes part of that evaluation when a model is making repeated decisions. The answer in our game could be a tiny move identifier, yet the model still received substantial context. For a general-purpose language model, internal reasoning also contributes to billed output. A short visible answer does not necessarily mean a cheap decision. When we evaluate models, we look at three dimensions: quality of results, latency and cost. The final algorithm has to strike a balance across all three to meet user and business needs.

The table below preserves our API cost estimates using the pricing assumptions recorded on October 27, 2026. The Decisions API column extrapolates from the final game. The Terra and Sol figures use the final Luna run’s input size and cache mix as proxies, with 500 to 2,000 internal reasoning tokens per decision. They are cost scenarios, not evidence of equivalent gameplay or a guarantee that any model would finish the game.

These figures cover API spend. In this experiment, the approach with no paid model calls also completed the game. Paying more for a different model would need to earn its place through better results under the same conditions.

A frontier tool can become the hammer that makes every problem look like a nail. Having one at our disposal does not make it the right choice for every problem. A conventional algorithm can be sufficient, and in other settings a specialized machine learning model may be the better fit. We did not train one for this project.

I have made the Tetris AI Harness public under the MIT license, including the failures, replayable records and cost assumptions. It gives us a way to repeat these comparisons as the tools improve.

I remain convinced that frontier AI will be able to handle more and more decisions, especially ones that require broader context and judgment. That is why I want to keep experimenting. In recommendations and search, I want to understand where those capabilities improve the decisions we already make and where they let us build something different. Keeping a working conventional approach beside the model helps me judge when that possibility becomes useful enough to put into a product.

---

This writing reflects my personal perspectives on product management, AI, and content discovery. It does not represent the official position of my employer or any affiliated organization.