The Workbench: What It Takes, What It Cost, and How the Work Got Done

The setup most AI courses hide: what you need for this lab, what Kevin used and paid each month, how a session with Claude really runs, and the editor, server, files and code underneath it all.

Most AI courses hide the bench. You open a notebook in the cloud, press Run, and the setup is someone else's problem. That works until something breaks, and something always breaks.

This part is the bench itself: what you need, what Kevin actually used and paid, how he worked with Claude, and the editor, connection, server and files underneath. Very little of it is AI. All of it is where AI work actually happens. Every lesson here comes from a real stumble while building HoldemRobots.AI.

What you need for this lab

Most students need almost nothing. The paid pieces are for whoever hosts the table.

Very few people need the cloud. A classroom can run everything on a Pi, offline, and anyone with a browser can use Kevin's shared table. Hosting your own copy only makes sense if you want it on the internet under your own name, with the web security Cloudflare puts in front of it.

You also don't need a Claude account to take this course. Kevin used one to build it. Students use AI in the labs through the table's own AI seat.

What Kevin used, and what it cost

Kevin built HoldemRobots.AI on his own money, so every choice was weighed two ways: what it costs each month, and how hard it is to set up and keep running.

Why Cloudflare sits in front. A public website gets probed and attacked from the day it goes live. Cloudflare stands between the internet and the server: visitors reach Cloudflare, and Cloudflare decides what gets through. The server has no public address of its own; Cloudflare's tunnel lets the domain reach it without opening the server to the whole internet. Cloudflare Pages serves these Field Notes without touching the server at all. That security is the main reason to host this way, and the main reason most schools won't need to.

From WorkSpace to Chromebook. The WorkSpace was easy to start with: it lived inside the same private AWS network as the server, so connecting just worked. But it cost $45 a month for what was really an editor and a browser. In August Kevin moved to a $200 Chromebook running its built-in Linux, with VS Code installed there and the same Remote-SSH connection to the server. The developer tools are the same, and they cost nothing a month. The setup took more thought, mainly about how a machine outside AWS reaches a server with a private address. The Chromebook paid for itself in under five months.

Watching the meter. A few habits kept costs down:

• Check that no AI games are running before stopping or rebooting anything. Every AI hand spends Bedrock money.
• Grow the disk only when needed, and find out what filled it.
• Don't pay for a desktop in the cloud when a laptop can do the same job.

Working with Claude

Kevin wrote HoldemRobots in 2005, alone. He rebuilt it in 2026 with Claude as a partner, in an ordinary chat in a browser. Claude never had access to his machines. The work ran as a loop:

1. Kevin starts a session by uploading his environment file, the "file that remembers" from Part 19. It tells Claude the setup, the history and how Kevin likes to work.
2. Kevin describes the goal in plain words, and uploads whatever helps: game exports, the site zip, old code, screenshots.
3. Claude explains the plan, then gives one command or one edit at a time, saying which terminal it belongs in.
4. Kevin runs it and pastes the result back. Claude reads the actual output before suggesting the next step.
5. Claude builds the files it can build itself (articles, site zips, PDFs, guides) and sends them back. Kevin uploads them to Cloudflare or copies them to the server.
6. At the end, Claude updates the environment file with what changed, so the next session starts where this one stopped.

What Kevin learned about working this way:

• Slow is fast. Early sessions went wrong when Claude handed over five commands at once. The rule became one step at a time, always naming the terminal.
• Claude can be wrong. It guessed at file locations, and once suggested a rebuild that would have erased live work. Reading the output, not trusting the plan, caught both.
• Write it down. Claude starts each chat fresh. Anything not in the environment file is forgotten.
• Two different Claudes. The partner in the chat window is not the AI player at the table. The player runs on Amazon Bedrock and is billed through AWS. The partner is Kevin's Claude account.

The four layers

The single most common mistake in this project was typing a command in the wrong place. There are four places you can be typing, and they look alike.

The poker game has nothing to do with layer 1. Your computer's only job is to start the connection. Once you're on the server, a command like docker exec legacy-tomcat ... is the server reaching into layer 4.

How to tell where you are: read the prompt before you press Enter. PS or penguin means your own computer. ubuntu@ means the server.

Setting up VS Code

VS Code with the Remote-SSH extension does layer 2 for you. After that, its terminal panel is the server. The steps are the same on Windows and on a Chromebook; on a Chromebook, first turn on Linux in Settings and install the Linux version of VS Code.

Working on the Pi alone? VS Code runs on the Pi itself. A student with only a Pi, a keyboard and a screen can edit bots and run the table on one box, with no server, no SSH and no second computer. Skip the Remote-SSH steps below; everything is layer 1.

1. Install VS Code from code.visualstudio.com.

2. In the Extensions panel, install Remote - SSH (part of Microsoft's Remote Development pack).

3. Add an entry to your SSH config file so VS Code knows how to reach the server:

   Host hr2-tomcat
       HostName <server-ip>
       User ubuntu
       IdentityFile <path-to-your-key>.pem

4. Press Ctrl+Shift+P, choose Remote-SSH: Connect to Host, and pick hr2-tomcat. The first connection installs a small helper on the server; give it a minute or two.

5. Open the terminal with Ctrl+`.

The check: the bottom-left corner of the window says SSH: hr2-tomcat, and the terminal prompt starts with ubuntu@. Remote-SSH opens a new window, so it's easy to keep typing in the old local one. The corner label always tells the truth.

When it won't connect

In July the connection started hanging. Everything in the AWS console looked healthy, including the instance's "2/2 status checks passed." It took a long ladder to find the problem:

1. Try plain SSH from your own terminal. If that works, the problem is VS Code; kill the VS Code server on the host and reconnect. If it also hangs, it's the network or the server.
2. Check the AWS network pieces, in order: security group (is port 22 open to your address?), network ACL, VPC, route table, NAT gateway.
3. Suspect the server itself. All of those were fine. The server's own network software had locked up. AWS status checks only prove the hardware is reachable, not that the operating system inside is answering.

The fix was a full Stop, then Start of the instance, because even a reboot hung. The private address stayed the same, and VS Code reconnected by itself.

Lesson: a green dashboard tells you what it measures, nothing more. That's Part 5's lesson, never trust the first answer, applied to infrastructure.

What changing a file looks like

There are two copies of many files: one on the server, and one inside the running container. They are not automatically the same.

• Editing on the server (in VS Code's file panel) changes the server's copy. The running game doesn't see it until it's copied in or the container is rebuilt.
• Editing inside the container changes what the game is using right now. It's live, but it lives only in that container.

That second point caused the rule that runs this project: use docker start, never docker compose down or up --build. A rebuild throws away the running container and every live edit in it. A plain stop and start keeps them.

The safe routine for any change:

1. Back up the file first (copy it with a date in the name).
2. Change one thing.
3. Check it in the running game, in a private browser window.
4. Record it in the environment file. If it isn't written down, the next session doesn't know it happened.

The parts list

Technologies, by layer

File types: the real count

Kevin ran one command on the server, from the ubuntu@ prompt in VS Code. It lists every file extension in his home folder, most common first:

find ~ -type f -not -path '*/.*' | sed -n 's/.*\.\([A-Za-z0-9]*\)$/\1/p' | sort | uniq -c | sort -rn | head -40

The top 40 types add up to 18,689 files. Grouped:

Three things to notice:

• Three-quarters of the files aren't Kevin's. The JavaScript and TypeScript are almost all installed packages, other people's code pulled in by tools. You write a little; you inherit a lot. (The count skips hidden folders, so Python's own installed packages, inside .venv, aren't even in it.)
• The old stack is still the core. 553 .xsp pages and 496 .jar libraries are the 2005 game, still running.
• Nobody remembers everything. 202 .vw files, and nobody, Kevin included, remembers for sure what they are. His guess is view files, perhaps database views, since 145 .sql files live nearby. Twenty years of projects leave things behind. That's an exercise below.
• Backups pile up. Four naming styles, 52 files: twenty years of "back up first." Pick one style, and clear old copies once a change is proven. Leftovers, logs and .tar files are the first place to look when a disk fills up.

The AWS and Cloudflare tour

The second war story: in October the server's disk hit 98% full. Growing the disk in the AWS console was easy; the new space appeared only after a reboot. The reboot routine:

1. Make sure no AI games are running (they spend Bedrock money).
2. Write down which containers are running.
3. Reboot, wait two minutes, reconnect VS Code.
4. Check the disk with df -h /. It went to 77 GB, 45% used.
5. Start only the missing containers with docker start.
6. Check the AI panel service, then click Start heads-up table; a reboot always stops it.

Still an open question, and a good student exercise: what filled the disk?

Peeking at the Python

Read before you write. Three files are worth opening:

• arena.py deals the Robot Wars table: six seats, a hand loop, and the export you download from Game Review.

• opponents.py is the house roster: Rock, Station, Maniac, Grinder and the rest. Each is a small, readable strategy.

• student_table.py is a separate piece, not part of Robot Wars. It runs the Pi's class tournament: up to six bots, one per student or one per team, chained together in one text file and cut apart at the dividers:

  # === BOT: Rockslide | author: Maya ===
  ...her code...
  # === END BOT ===

  Every bot then runs inside the same program as the dealer. That's on purpose. It's the third door left open in Part 22, and the table's house rules are requests, not walls.

What to look for: where each bot gets its information, and what it is not supposed to see. The honest observation never carries the deck or anyone else's cards. That's the Dealer's rule from Part 15. But a rule is only a wall when the bot runs somewhere it can't reach the dealer, as it does over the API. The class tournament keeps everyone in one program so you can see why that wall matters.

Corrected Oct 25, 2026: an earlier version said each student bot runs in its own process. The class tournament runs every bot inside the dealer's program, as Part 22 describes.

Written by Kevin Swinson with Claudette, the pen name for Claude, the AI from Anthropic that helped build HoldemRobots.AI. Describes the setup as of October 24, 2026. Server addresses and key paths are shown as placeholders like <server-ip>.