Week 8: The Verification Gap: Lessons from Plum Jam and Production Releases

Sometimes the most profound engineering lessons come from the most unexpected places. This week, it was a batch of inedibly tart plum jam that reminded me why verification remains one of our most critical practices, even—or especially—in an AI-augmented world.

I missed a couple of weeks of these rundowns, which feels worth acknowledging. Work and family responsibilities converged in that particular way they sometimes do, leaving precious little time for reflection or writing. During the spare moments I did have, motivation felt scarce. In hindsight, I wonder if that wasn’t my brain’s way of preventing burnout—a biological circuit breaker kicking in before things got too overwhelming.

The Weight of Release Week

The timing was particularly intense because we were approaching the release of a long-running feature that’s absolutely key to the Breedr app. There’s something uniquely thrilling and terrifying about shipping something you’ve poured months of work into, knowing it will fundamentally change how users experience your product. The excitement of finally seeing it in users’ hands wars with the anxiety of potential edge cases you haven’t considered.

The Jam Recipe Revelation

Which brings me to the plum jam disaster. I’ve had excellent experiences using Claude for recipes in the past, so when I decided to make jam with a glut of plums, I didn’t bother cross-checking the recipe. Having never made jam before, I didn’t notice the sugar content was suspiciously low. The result was a batch of jam so tart it’s destined for the bin.

The lesson here isn’t about AI unreliability—it’s about the verification gap that emerges when we become too comfortable with our tools. I’d developed such trust in AI-generated recipes that I’d stopped applying the same critical thinking I’d naturally use with any other source. It’s the engineering equivalent of deploying code without running tests because the static analysis passed.

This connects beautifully to verification patterns in software development. We’ve all seen teams become overly reliant on particular tools or frameworks, gradually losing the habit of questioning outputs. Whether it’s blindly trusting linter suggestions, accepting AI-generated code without review, or deploying based solely on CI green lights, the pattern is the same: useful tools becoming crutches that atrophy our critical faculties.

Learning in an AI-Assisted World

I’m currently part of the first cohort of Matt Pocock’s AI Hero course, which takes a fascinating approach to learning. Rather than traditional tutorials, it provides prompts to run with AI, then teaches you to adjust and fix the results. It’s undeniably how much of our work happens now, but I find myself questioning whether this approach might reduce the depth of understanding we develop.

There’s something to be said for the slower path of building things from first principles. Yet there’s also immense value in covering more ground quickly and learning to work effectively with AI assistance. The key seems to be maintaining enough foundational knowledge to spot when the AI output doesn’t make sense—much like knowing enough about jam-making to realise when sugar quantities look wrong.

I also spent time listening to DHH on the Lex Fridman podcast. Having properly absorbed his perspective, much of what he advocates makes compelling sense, particularly his thoughts on sustainable development practices and the Ruby language. There’s wisdom in his contrarian positions, even when—or especially when—they challenge current orthodoxy.

Technical Evolution: ContentSage and Multi-Tenancy

Alongside the Breedr work, I’ve been revitalising ContentSage, my AI video insights application. The original version kept everything local to the user’s machine, but for any serious monetisation, data needs to be shareable across organisations. This led me down the path of implementing multi-tenant databases with Turso.

The architecture is elegant in its simplicity: when users sign up and create an organisation, they get their own database instance that can be shared with invited team members. It’s a clean separation that provides isolation whilst enabling collaboration.

I also switched to the Vercel AI SDK, which has streamlined much of the AI integration work. Over 14 commits in the past few days, I’ve moved from Kysely to Drizzle ORM, implemented Clerk for organisation setup, and established the multi-tenant foundation. The conversion from a single-user to multi-tenant architecture required careful consideration of authentication flows and database migration patterns.

Tools and Discovery

Two discoveries worth mentioning: Turso continues to impress with its edge database capabilities, particularly for applications like ContentSage where data locality matters. SuperClaude caught my attention as well—interesting concept, though it attempts to do rather too much. I’m planning to take inspiration from it and build something more tailored to my specific workflow needs.

This reflects a broader pattern in tool selection: the most successful integrations often come from building focused solutions rather than adopting comprehensive platforms that do everything moderately well.

Sustainable Engineering Practices

The missed weeks and motivation struggles highlighted something important about sustainable engineering practices. We often discuss technical debt and code maintainability, but rarely address the sustainability of our own engagement with the work. Recognising when to step back, when to push through, and when to trust that temporary disengagement might be protective rather than problematic.

The verification gap I encountered with the jam recipe applies equally to our relationship with productivity and engagement. Just as we need to maintain critical thinking about AI outputs, we need to stay attuned to our own capacity and energy levels. The most sustainable engineering practices aren’t just about code—they’re about maintaining the human systems that write the code.

Looking ahead, the Breedr release will either validate months of architectural decisions or reveal gaps in our thinking. Either outcome provides valuable learning. The key is approaching it with the same beginner’s mind that questions assumptions, whether about jam recipes or production releases.

Good engineering, after all, is as much about knowing when to verify as it is about knowing how to build.