AI engineering reminds me of playing online poker in 2006

Back in the mid 2000s I was an avid online poker player. Texas Hold'em was everywhere. It was on TV most nights and online casinos were springing up every month. I was an active member of several of them, including Party Poker, Paradise Poker, and PokerStars.

I can't say I won much, but I loved it.

Ah, the nostalgia of that website screenshot.

It got to the point where I was playing four tables simultaneously, with software running to detect who was a 'fish' in an attempt to give me an edge.

I didn't jump straight to playing four tables. I started with one, built up my skills, learned where all the buttons were and how the software worked.

Then I added another.

Then another.

Then another.

At the start I was so overwhelmed by one table that I wondered how anyone could ever concentrate on more than one. But just like after a few months of driving a car, things that once were high cognitive load became easy. Much of the skill was so practised it could be done with little thought. Pattern recognition and muscle memory kicked in hard.

Four tables was my limit (even though I knew people who played eight).

Coding with AI reminds me of those good ole' days. The four poker tables neatly arranged into the quadrants of my CRT monitor have been replaced by 2 or 3 Visual Studio Code instances and a couple of terminal windows.

I didn't think I'd manage to get past one agent running, but here I am with several agent teams working for me in the background whilst I write this article.

The difference, however, between AI and poker is that the rules in poker never changed. I had memorised the odds of every hand and every possible play. Those odds didn't change hand over hand.

With coding, the rules are constantly changing. Not because the models are improving (although vendors constantly releasing new features and commands does sometimes throw a spanner in the works), but because each agentic session is trying to achieve something different from the last.

For example, when I want to create a new feature I brainstorm back and forth with an agent, write an Openspec, file Beads, have an agent team implement the Openspec in phases, and have a reviewer review their work. In the meantime I'm watching the output just in case I spot the agent making a mistake or needing guidance. Reading the output and the specifications IS the work. And it's demanding work. It requires a lot of mental effort to think through everything being proposed, and if I agree with the suggestions.

Addy Osmani calls this "comprehension debt" — the growing gap between how much code exists in your system and how much of it any human being genuinely understands. His line stuck with me: "making code cheap to generate doesn't make understanding cheap to skip. The comprehension work is the job."

Multiply this by the number of features and bugs I'm working on at any one time.

This high cognitive load doesn't get easier because there are no repeating patterns. It's draining. But it's also highly addictive. Write a prompt, get something built, get a dopamine hit. 10-12 hour AI coding sessions fly by. I wake up and I'm straight on my phone at 7am chatting to Claude, having it spin up a dev environment and do some work so that by the time I sit at my desk I already have something to review.

Steve Yegge, quoted by Quentin Rousseau, describes the mechanism better than I can: "the intermittent reinforcement of those dopamine and adrenaline hits creates the core addictive pull. It can become near-impossible to tear yourself away." That's it exactly. It's not steady reward, it's the variability — the same loop that keeps people sat at a slot machine, or a poker table.

I don't think I can cope with more than two agent teams running at once. I know some people do, but I have no idea how they check their work. It might work for less risky UI changes in a NextJS app, but when you're orchestrating data-heavy pipelines in GCP that are tricky to test, I really need to make sure nothing is going wrong.

Ed Lyons puts it well in a different analogy: "Think of using multiple coding agents as you would think of walking multiple dogs at once. If you're going to hold four leashes at a time, you'd better be good with dogs." Same idea, different mess.

The other thing poker taught me is that table count isn't the flex. The good players weren't the ones running eight tables, they were the ones who knew which hands to fold. With AI coding the same thing is starting to feel true. The skill isn't how many agents you can run in parallel. It's knowing which ones to stop, which output to actually read, and which work is too risky to let run unattended in the first place.

Four tables was my poker ceiling. Two agent teams seems to be my coding one. I'm okay with that.