Ak33m

I’ve been using AI agents exclusively to write code for a few months now. It’s been a cool experience, but some surprising things have surfaced, showing that my main challenge is not writing code, but capturing and organizing the work agents uncover.

• Agents surface more work than I can write down by hand.
• I like to build entire epics in a single run, but agents lose context and can’t see the whole picture, which makes that harder to sustain.
• I also like to have agents work unattended overnight and “pick up” new work, but that creates another transition problem.
• Beads turns out to be a better way to capture and organize work than tickets.

Behavior-Driven Development spent a decade as a niche testing discipline. AI coding just promoted it to core infrastructure for how software gets built. When a model writes most of the code, your job shifts from typing to specifying. Gherkin, the plain-language “Given / When / Then” format behind Cucumber, turns out to be one of the cleanest ways to specify intent for humans and machines at the same time. The shift You’re doing product work now.

For years, I’ve searched for the right name for a distinct sensation: the moment a window opens in finances, in a career, or in a game of chess, where the challenge isn’t whether to act, but when and how much. Three ideas interlock precisely to frame this feeling: Kairos, the Kelly Criterion, and optimal stopping theory. Each is interesting on its own, but together, they become operational; offering a way to act on that sensation.

The Problem I Wanted to Solve I’m a builder, and the hardest part of building good software isn’t the code; it’s listening. Specifically, listening to what users are actually struggling with, not just what they say they want. AI already helps me write code faster. I wanted it to help me with the part that matters more: understanding the problem before I build the wrong solution. What Is Candor? Candor is an AI-powered digital twin that lets product managers and developers run product discovery interviews without needing a real customer in the room.

A few months ago, I was introduced to spec-driven development with AI and Kiro. While I didn’t continue using Kiro, I kept using the technique because it helped guard against the challenges of working with AI at the time. I’d spend time building out a detailed spec requirements, edge cases, acceptance criteria; hand it to the model, and watch it produce something technically faithful to the document but somehow still wrong.

So I’d refine the spec. Add more detail. Go back and forth. Recently, I realized this is waterfall development on a tighter loop. I’d just rebuilt the waterfall inside my AI workflow without realizing it.

Event sourcing is an architectural pattern in which every change to an application’s state is recorded as a sequence of events (Fowler, 2005). Event sourcing is a companion architecture to domain-driven design, with events related to aggregate root entities within the domain. In domain-driven design, we model the domain by creating a ubiquitous language that captures its core concepts. Those objects are subject to certain actions, and it’s natural to think of these actions as events that have occurred.

What a difference 3 years makes. In 2022, I wrote about running Wepala as an agency and celebrating 5 years of building amazing things. Now, in 2025, I find myself reflecting on the evolution of our business and the industry as a whole. Are we witnessing the end of the era of the agency? (TLDR; yes, at least for me.) Over the last few years, I’ve seen a significant shift in how businesses approach software development.

With the rise of chatbots and voice assistants, there has been a lot of talk about the rise of conversational user interfaces (CUI). CUIs allow users to interact with a system using natural language. The most common CUIs are chatbots and voice assistants. CUIs are not new. They have been around for a long time. The first chatbot was created in 1966, and the first voice assistant was built in 1978.

After reading Andressen Horowitz’s article on LLM Architecture I decided to look into Langchain. Langchain describes itself as a framework for developing applications powered by language models. I have been working with OpenAI for some time now ❓Why I decided to look into Langchain I’ve been working with OpenAI for some time now and I was intrigued that there are already frameworks for building applications powered by language models. One of the problems I’ve been working on is effectively testing and iterating models and I hoped that Langchain would help with that.

I started Wepala to create a company that would build amazing things. At a time when outsourcing work to Asia was the thing to do, I realized that the Caribbean was better positioned to deliver (no time or language barriers). I was pitching Nearshoring before there was a buzzword for it. Over the last five years, we’ve developed relationships with our clients as we built out minimal viable products (MVPs) for them and watched as they’ve found their place in the market. We’ve also been able to develop our products, and we’ve learned a tremendous amount along the way.

Photo by Clark Tibbs on Unsplash