The setup

Before the weekend I added a new league format. Instead of me entering everyone’s results, each player records their own score before the deadline, and the other player confirms it. If there’s a disagreement, the organiser has the final say.

It all worked in testing. Then real people started using it.

Here’s the table as it stands. Names are hidden apart from mine, and you can see I’m not winning my own league:

What the players showed me

You only learn some things when people are actually trying to get their game recorded before the deadline. Over the weekend players found a few bugs, and, more usefully, the spots where the app slowed them down. Some examples:

• Recording a game asked for too much. Now it just asks for the score.
• Typing in scores was a chore. Now you can take a photo of the result on your screen and the app reads it.
• A few features got in the way. I removed them. If something doesn’t help someone record a result, it doesn’t need to be on the screen.
• People weren’t sure how long they had. The league page now says it plainly, like “Ends tonight, 11:59 PM (21h left)”, and the colour changes as the deadline gets close.
• Almost everyone was on their phone. So I went through every screen on a phone: bigger buttons, long names that don’t break the layout, and your next game always easy to find.

Fixing data in the database

Not every fix was on the screen. A few players had problems with the email addresses on their accounts, and they had to be corrected in the database itself.

This was my favourite part of the week. I described what needed to change, and Opus wrote the SQL scripts to find the affected accounts and update them. The scripts were clean and careful, and easy to read and check before running. It took me back to my time at SAIT, writing database scripts to pull information out and update records. I really enjoyed that work then, and I enjoyed it again here.

Fast fixes, nothing broken

Most fixes went out the same day the problem showed up. That only works because Scoreline has automatic checks: before anything goes live, the app is built and tested from scratch, including the main things a player does. If something breaks, it doesn’t ship.

Over the weekend I pushed thirteen updates, and none of them broke anything that already worked.

What I learned

• Real users beat any amount of testing. Eight friends in one weekend found more friction than all my own testing, because they were trying to get something done, not trying the app out.
• Fast is only good if it’s safe. Claude makes fixes quick to write. The automatic checks are what made me comfortable shipping in the middle of a live league.
• Old skills still count. The SQL work reminded me that what I learned at SAIT still matters. It’s just faster now, with Claude doing the typing and me checking the logic.

Next week

• Run a second league and see how it goes when I’m not watching every game.
• Keep improving the score recording, based on what the players tell me.

Teaching an agent to watch video

Agents are good at text and bad at video. I want mine to be able to watch a tutorial or one of my own explainers and come back with notes I can trust, so I built a small toolchain for it.

A run goes like this:

1. An advisor picks the mode. Before spending anything, it recommends how to watch the video (transcript only, frames only, or a full video model) and estimates the cost.
2. Gemini watches the full video, while the toolchain pulls the transcript and extracts frames at 1024px.
3. Everything lands in an evidence pack: the model’s claims, the transcript and the frames, plus a checklist of claims that need checking.
4. Every claim gets a verdict against the frames and transcript: confirmed, corrected, dropped or unresolved. A check step has to pass, with at least 90% of the checklist resolved, before any notes get written.

Here’s one real row from a run on a public Cisco Packet Tracer VLAN tutorial. Gemini named the switch’s trunk port correctly in its summary, then got it wrong in its step-by-step:

That’s the kind of error that looks right to a reader and breaks a lab. Confirmed (✅), corrected (✏️) and dropped (❌) claims all count as resolved. Anything I can’t check either way is marked ❓ and stays in the note as a named caveat, not a fact. The 90% gate means the agent can’t write notes from a checklist that’s mostly unchecked.

This week I made the skill portable and added the toolchain as a git submodule to the two repos that produce my TechWithTosin videos, so the same “watch, then verify” loop runs wherever I need it.

What I learned

The video model is very good at the gist and unreliable on exact strings. In testing, the details it got wrong were the ones that matter most in technical content: passwords, channel names, domain names and IP addresses. The fix wasn’t a better prompt. It was treating the model’s output as claims to verify against primary evidence (the actual frame, the actual transcript line), and refusing to write notes until enough of them were checked.

Running a game milestone with AI reviewers

I’m also building a browser-based life simulation game, and this week it moved through milestones M2.3 to M3.2 in 46 commits: a rent goal and per-profile economy, shift events that fire by seeded chance instead of on a fixed calendar, clearer feedback on every action, and a first “make it feel like a game” pass.

Two lines a player now sees, as examples of what “clearer feedback” meant in practice:

• When a choice can’t be afforded, the card stays open and says why: “Not enough to cover it yet. The other options are open.”
• The rent outlook does the maths from the game’s own payslip and fills in the real numbers: “About $X by Feb 1, before bills. Gap: $Y. One more shift adds about $Z.”

The interesting part is the process rather than the features. Each milestone follows the same loop:

• Plan first. An agent drafts the milestone plan before any code is written.
• Separate reviewers. An architecture reviewer checks anything that touches the data model or save format, and an ethics reviewer pre-checks content about hardship (missed rent, losing a shift) so it’s handled with care, not played for drama.
• I sign off on judgement calls. Sensitive content doesn’t ship until I’ve approved it, and the approved version is pinned in a test so it can’t drift later.
• Playtest, then fix. A playtest pass on desktop and phone feeds the next round of fixes.

What I learned

Speed wasn’t the bottleneck. Judgement was. Agents will happily produce a week of features in a day, so the useful work moved to deciding where a human has to be in the loop and making that gate hard to skip. Pinning approved content in tests turned “I reviewed it once” into “it can’t silently change”.

Next week

• Point the video toolchain at my own TechWithTosin episodes and use it as a QA pass before publishing.
• Keep pushing the AI Kubernetes troubleshooter towards something I can demo outside my laptop.