Category: Games

Image and research source: Thomas Taylor (GitHub)

If you want to see what an LLM is really good at (and where it still slips), don’t ask it to write a poem or generate code. Ask it to make the same small decision again and again under clear rules.

That is why blackjack basic strategy is such a useful lens.

Basic strategy is basically a decision table. Given your hand and the dealer’s upcard, there is a best move for a given rule set. Hit, stand, double, split, surrender. It is not a vibe. It is a lookup problem.

So you would expect modern models to nail it. And some do. But what makes this benchmark interesting is not “who got the highest score.” It is how the models fail.

The result that matters is not the winner, it is the pattern of mistakes

Check out Thomas’ Page: https://thomasgtaylor.com/blackjack/

When models get decisions wrong in blackjack, they do not usually fail randomly. They tend to develop a consistent style of mistakes.

One model might double too often. Another might be overly cautious and miss good doubles. Another might surrender in spots where it should fight on. That is a big deal because it mirrors what many developers see in real products: the model is mostly reliable, but it has a few recurring blind spots.

This is the key point for builders. LLMs do not fail like buggy programs. They fail like inconsistent policies.

Accuracy and outcomes are not the same thing

The benchmark tracks two things that people often confuse:

• decision accuracy: did the model pick the basic strategy move?
• outcome: did the bankroll go up or down over the run?

These can diverge. Blackjack has asymmetric payouts. A single bad double can hurt more than a small hit/stand mistake. And over a limited number of hands, luck still matters. So you can see a model that is slightly less accurate end up with a better balance simply because variance went its way.

This is not just gambling trivia. It is a reminder that your evaluation metric shapes what looks “best.” If your product cares about costly failures, you should measure cost-weighted errors, not just raw accuracy.

Why this matters outside blackjack

A blackjack hand is a tiny state with a clear action set. Software is full of the same structure:

• incident triage rules
• retry and backoff policies
• access control and permissions
• billing and pricing logic
• feature rollout rules
• compliance checks

In all of these, you often have clear policies you want followed. If a model struggles to consistently follow a small decision table, it will also drift when it is asked to follow your company’s rules unless you design around that.

The better mental model: LLMs behave like learned heuristics

A traditional program executes rules. A plain LLM often imitates rules and sometimes improvises. That is why you see those “error personalities.” The model is not just retrieving the correct table cell every time. It is applying a learned pattern that is usually right, and occasionally biased.

This is the important angle for the Finxter community: treat the model like a policy learner, not a calculator.

What to do with this insight

The engineering move is not to argue with the model harder. It is to change the shape of the task so the model cannot drift.

A few practical approaches:

• Put the strategy table in code and have the model call it.
• If you keep it in the prompt, force a structured lookup format and validate the output.
• Log mistakes by category (too many doubles, early surrenders, split errors) because that tells you what to fix.

A simple Finxter challenge you can copy

The real win here is not blackjack itself. It is the idea of a small, repeatable benchmark.

Pick any domain where ground truth exists as a clear set of rules or a decision table. Generate a lot of reproducible test cases. Score both accuracy and cost-weighted outcomes. Then look for recurring error patterns, not just the overall score.

That gives you something far more useful than “model A feels smarter than model B.” It tells you how a model behaves under repetition, which is what matters when you are building real systems.

Join the Finxter AI Newsletter to be on the right side of change – with 130k readers!

The post Stop Testing LLMs with Poetry: Use Blackjack Instead appeared first on Be on the Right Side of Change.

The post Play Arcade Tennis Online (Free, No Signup) appeared first on Be on the Right Side of Change.

This code creates a simple Snake game using the Pygame library in Python.

The game starts with a small snake moving around the screen, controlled by arrow keys, eating randomly placed food items. Each time the snake eats food, it grows longer, and the game gets faster.

The game ends if the snake collides with itself or the screen borders, and the player’s goal is to keep the snake growing as long as possible.

import pygame
import sys
import random # Initialize pygame
pygame.init() # Set screen dimensions
WIDTH = 640
HEIGHT = 480
CELL_SIZE = 20 # Colors
WHITE = (255, 255, 255)
GREEN = (0, 255, 0)
RED = (255, 0, 0) # Create the game screen
screen = pygame.display.set_mode((WIDTH, HEIGHT)) # Set the game clock
clock = pygame.time.Clock() def random_food_position(): return (random.randint(0, (WIDTH-CELL_SIZE)//CELL_SIZE) * CELL_SIZE, random.randint(0, (HEIGHT-CELL_SIZE)//CELL_SIZE) * CELL_SIZE) def draw_snake(snake_positions): for pos in snake_positions: pygame.draw.rect(screen, GREEN, pygame.Rect(pos[0], pos[1], CELL_SIZE, CELL_SIZE)) def draw_food(food_position): pygame.draw.rect(screen, RED, pygame.Rect(food_position[0], food_position[1], CELL_SIZE, CELL_SIZE)) def main(): snake_positions = [(100, 100), (80, 100), (60, 100)] snake_direction = (20, 0) food_position = random_food_position() game_speed = 10 while True: for event in pygame.event.get(): if event.type == pygame.QUIT: pygame.quit() sys.exit() if event.type == pygame.KEYDOWN: if event.key == pygame.K_UP and snake_direction != (0, 20): snake_direction = (0, -20) elif event.key == pygame.K_DOWN and snake_direction != (0, -20): snake_direction = (0, 20) elif event.key == pygame.K_LEFT and snake_direction != (20, 0): snake_direction = (-20, 0) elif event.key == pygame.K_RIGHT and snake_direction != (-20, 0): snake_direction = (20, 0) new_head = (snake_positions[0][0] + snake_direction[0], snake_positions[0][1] + snake_direction[1]) if new_head in snake_positions or new_head[0] < 0 or new_head[0] >= WIDTH or new_head[1] < 0 or new_head[1] >= HEIGHT: break snake_positions.insert(0, new_head) if new_head == food_position: food_position = random_food_position() game_speed += 1 else: snake_positions.pop() screen.fill(WHITE) draw_snake(snake_positions) draw_food(food_position) pygame.display.update() clock.tick(game_speed) if __name__ == "__main__": main()

This simple implementation of the classic Snake game uses the Pygame library in Python — here’s how I quickly lost in the game:

Here’s a brief explanation of each part of the code:

1. Import libraries:
   • pygame for creating the game window and handling events,
   • sys for system-specific parameters and functions, and
   • random for generating random numbers.
2. Initialize pygame with pygame.init().
3. Set screen dimensions and cell size. The WIDTH, HEIGHT, and CELL_SIZE constants define the game window size and the size of each cell (both snake segments and food).
4. Define color constants WHITE, GREEN, and RED as RGB tuples.
5. Create the game screen with pygame.display.set_mode((WIDTH, HEIGHT)).
6. Set the game clock with pygame.time.Clock() to control the game’s frame rate.
7. Define the random_food_position() function to generate a random food position on the grid, ensuring it’s aligned with the CELL_SIZE.
8. Define draw_snake(snake_positions) function to draw the snake’s body segments at their respective positions using green rectangles.
9. Define draw_food(food_position) function to draw the food as a red rectangle at its position.
10. Define the main() function, which contains the main game loop and logic.
    • Initialize the snake’s starting position, direction, food position, and game speed.
    • The while True loop is the main game loop that runs indefinitely until the snake collides with itself or the screen borders.
    • Handle events like closing the game window or changing the snake’s direction using arrow keys.
    • Update the snake’s position based on its current direction.
    • Check for collisions with itself or the screen borders, breaking the loop if a collision occurs.
    • If the snake’s head is at the food position, generate a new food position and increase the game speed. Otherwise, remove the last snake segment.
    • Update the game display by filling the screen with a white background, drawing the snake and food, and updating the display.
    • Control the game speed using clock.tick(game_speed).
11. Run the main() function when the script is executed by checking if __name__ == "__main__".