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.
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.
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.