This week at the bridge club we had a minor crisis. We have a system for collecting scores each round and feeding them into a computer, which then produces the rankings. This week it lost both — the scores and, more importantly, the rankings. I say “more importantly” because we came top. Others may be less exercised about this.
As the club techie, it fell to me to sort it out. The results collection system works like this: small gadgets sit on each table for entering scores, these communicate wirelessly with a dedicated server, which is linked to a PC. A program talks to the server and creates a results file on the PC. So that file was the obvious first port of call.
Since my last post I’ve been using Claude Code more, and I’m pleased to report it works well and is genuinely powerful. As a confirmed control freak, I was also pleased to find that I stayed in control throughout.
After spending a year building fintechbenchmark.com the traditional way—writing code, testing it, iterating—I’d grown comfortable with GitHub Copilot as my AI assistant. It delivered a significant productivity boost, though I’d learned when to trust it and when to ignore its suggestions and push forward on my own.
Then, weeks before our soft launch, our lead contractor dropped a demo of Google Antigravity (Project IDX) that made our entire workflow look like stone tools and campfire stories.
The assumption that bigger AI models always deliver better results is being quietly dismantled — and the economics behind this shift are compelling. Now we have Small Language Models (SLM) to distinguish them from Large language Models (LLM). How do we measure the size of a model?
When I was seeding the database for fintechbenchmark.com with Claude-generated or Openai-generated content, I needed structured data that matched my database schema. My format of choice was JSON, and my approach was straightforward:
Request JSON in the prompt
Provide an example of the desired structure
Parse Claude’s response—a text string containing JSON wrapped in markdown code blocks with triple backticks
MCP (Model Context Protocol) solves a fundamental problem: how do you give an AI model access to external data like databases, files, or APIs without embedding everything in each request? Introduced by Anthropic in November 2024, MCP is now mature enough (15+ months old) for serious production use. Think of it like a USB-C port for AI—a standardized way to connect AI models to external systems.
When we planned fintechbenchmark.com (currently in beta), we realized that AI wasn’t optional—it was essential. We could either embrace this revolution or watch competitors leave us behind.
We faced a classic startup dilemma: build a custom AI solution (expensive and slow) or use an off-the-shelf product to launch quickly and learn what our visitors actually need. We chose the pragmatic route.
I am thinking about putting together a presentation on AI for the uninitiated. I thought a good starting point would be a SWAT analysis (Strengths, Weaknesses, Opportunities, Threats). It is a technique that is very useful in analysing new projects. A number of people have done this but why not have another go.
After retiring 15 years ago from professional software development, I had a clear picture of what source control should provide for a commercial development team:
Prevention of simultaneous edits – avoiding the chaos when two developers unknowingly work on identical code
Real-time visibility into who’s currently working on what files
Version metadata embedded in code files – a lifesaver when you find a piece of code and need to know what version it is
A comprehensive audit trail showing who modified which files and when
Automatic version incrementing for every modification
A single authoritative codebase representing the current production state
The ability to roll back to any previous version
When a business opportunity pulled me out of retirement and back into managing a development team, I naturally asked about source control. The universal response? “We use Git.”
Bob Browning's blog 