Tracking Every Decision in Payments: The Context Pattern Approach

Chasing the AI God: Why We Worship Every New Model

It's like a new diet pill has hit the market, promising instant weight loss with no effort, and now everyone's scrambling to get their hands on it because it's all over their TikTok.

Some folks are talking about DeepSeek as if it's the second coming of AI.

The clamour might be because it's the first serious open non-US model with reasoning capabilities from China.

Most people are confused about which version of DeepSeek they're using.

Most providers offer a distilled, watered-down version that'll run anywhere, so you're not getting the actual full fat version people are talking as to really see its magic, you'd need a small fortune in computing power.

It's like being promised a rare vintage white wine, only to find the bottle filled with slightly grape-scented water. Same brand, same label, but all the depth and character stripped away, leaving you with a hollow imitation.

The hype suggests it can keep pace with anything OpenAI does, which might sound thrilling if you're already tired of whatever ChatGPT or its siblings spit out.

But here's where the alarm bells should start ringing.

Lessons from Building AI Products with Stakeholders

Building AI products with stakeholders requires a fundamentally different approach than traditional software development.

From my experience working with AI, success depends not only on technical implementation but also on bridging the gap between AI capabilities and stakeholder expectations.

In this post, I’ll share lessons from guiding stakeholders through AI’s possibilities and limitations.

Whose Responsibility Is It Anyway? Defining Boundaries with Event-Driven Architecture

Defining clear boundaries is essential to building clean, scalable, and reliable architectures.

In my experience, organisational demands often override the focus on boundaries and domain-driven design. This reflects the tension between following technical best practices and delivering business outcomes quickly. While theoretical approaches are widely discussed at conferences, in books, and in videos, the practical implementation of these ideas is often shaped by cultural dynamics, resource constraints, tight deadlines, and internal politics.

In this post, we'll explore the challenges of maintaining boundaries and potential solutions, using a payment system as an example. This system facilitates transactions between clients and payment providers, such as PayPal or Stripe, highlighting the distribution of responsibilities within its architecture.

The Determinism Dilemma: Why Traditional Software Engineers Struggle with AI Development

The goal of creating something "predictable," reliable, and consistent is a shared principle across all the teams I've worked with throughout my career.

Knowing that the same code would always return the same output when given the same inputs was the foundation of everything we built.

We aimed for no surprises, no matter how complex a workflow might be. Whether implicitly or explicitly using finite state machines, this determinism enabled us to build testable, monitorable, maintainable, and, most importantly, predictable workflows.

We read and shared ideas at conferences, promoting patterns and principles like SOLID and DRY to create functional, composable, and extensible software.

Déjà Vu: AI Agent Frameworks and the JavaScript Gold Rush Revisited

Having lived through the era of a "new JavaScript framework every week," we now find ourselves in the gold rush of the AI agent framework space.

New frameworks appear daily, each claiming to be the 'ultimate' solution for building AI agents, often backed by YouTubers enthusiastically promoting demoware and usually their own library, framework, or SaaS offering. Unfortunately, this enthusiasm can lead companies to uncritically adopt these tools without considering the long-term implications.

What About Using Structured Naming for Event-Driven Messaging?

It's a well-known adage that naming things is hard.

In event-driven architectures, a consistent naming convention is essential for scalability, communication, collaboration and maintainability.

At the moment, I'm architecting a new event-driven solution, and I planning to adopt a Structured Naming approach for event types.

In this post I'll share my thoughts on this approach and its benefits.

AWS Step Functions Cookbook

This is my AWS Step Functions Mapping and Patterns and cookbook covering data manipulation, concurrency patterns, error handling, and advanced workflows.

Sometimes Boring is Best

As I stood in the rain as a volunteer race marshal at my local park run, it occurred to me that I wanted the same thing when running applications in production, and that's absolutely nothing to happen.

The last thing I wanted to do was be a hero.

🎸 "Always keep on the right side of the path" – the Parkrun version of Monty Python's song.

I'd rather everyone enjoy a safe, smooth race where I can cheer and encourage people on as they pass, reminding them to keep to the right so they don't collide with runners coming the other way.

It's the same in the land of IT. The only thing I want to see when viewing Grafana dashboards is a sea of green, 200 status codes and steady traffic patterns.

Don't Look Back in Anger: Let's Design a Better Ticketing System

Saturday's Oasis ticket sales left thousands of fans disheartened after spending hours in virtual queues. As reported by the BBC and echoed by fans on X (formerly Twitter) and Reddit, the experience could be aptly described using a quote from Liam Gallagher himself:

Shite

— Liam Gallagher (@liamgallagher) April 20, 2023

Like many others, I have long been frustrated with platforms like Ticketmaster, See Tickets, and Gigs and Tours. This weekend, their reputations took another hit as fans faced inflated prices and technical glitches.

This made me think if I could design a better, more reliable ticketing system that prioritises fairness and user experience.

Let's not make Sally wait any longer than she has to.