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. AI handles the mechanical translation from intent to code. The scarce skill is deciding what to build and how it should behave at.
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.
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. As an example, if you have an aggregate root “Order”, when the order is created, you may emit an event “order.created”. When the credit for the order is approved, you may have “order.approved”. When the order is shipped, “order.shipped” would be emitted and so on. What you end up with is an append-only log of all the things that are happening in the system.
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. AI has become a
game changer in the industry, automating many tasks that were once done by humans. At Wepala, we embraced this change,
leveraging GitHub Copilot and other AI tools to enhance our development process. This has allowed us to focus more on
architecture and design while AI handles the more mundane tasks. Projects that used to take months can now be completed in weeks,
with better code coverage and less technical debt.
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.
We’re putting our models in production and we want to improve the performance of our models. I am anticpating increased complexity and I expected langchain to provide an opinionated way to manage that complexity.
🔗 Langchain as a framework
Langchain seems to have 2/3 languages they support; javascript/typescript and python. I looked at the python version
because I prefer to use python over javascript for data science stuff. Right now we use a mix of Go and Python but I was
open to switching to python if it made sense.
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.
