The Two-Month Memory Gap
It was November. I’d just finished an intense two-week period of user acceptance testing, spending hours each day with stakeholders. On the final Friday afternoon, I had a crucial conversation with a product owner about complex accounting needs. We spent 30-40 minutes diving deep into the problems that accountants and financial controllers face when closing books and ensuring everything balances.
Fast forward to mid-January. I couldn’t remember the details from that conversation. What reports were needed? What tools would solve their pain points? The specifics had vanished, lost in the swirl of other work and the passage of time.
But I had something better than memory: I had the transcript.
AI as Business Analyst
I pulled up that conversation transcript and gave it to Cursor, my AI coding assistant, in that moment. My prompt was simple: “Give me a comprehensive document describing this conversation about accounting needs, problems, and pain points.”
The AI delivered a beautifully organized summary of everything we’d discussed. Then I asked it to perform business analysis on that document and create user stories. It produced well-structured stories from a business perspective rather than a technical one. It organized the stories within features, and ordered them in a way that made sense.
From Stories to Working Software
The real magic happened when I moved from planning to implementation. I took one feature with six or seven user stories, switched Cursor into plan mode, and asked it to implement the solution.
I gave it a few hints about where to find existing domain events and tests in our codebase. It created a plan, which I reviewed and tweaked slightly. Then I hit “build” and let it run.
The AI wrote code, wrote tests, ran tests, and fixed failures until everything passed. Sometimes it got stuck and needed a gentle nudge—“keep debugging” or “try this approach”—but mostly it worked autonomously.
While it was coding, I was working on other parts of the project. The AI was my assistant developer, handling the implementation while I handled higher-level project concerns (analyzing information and context to plan other features).
The Stakeholder Reaction
When I showed the working software to the product owner, they were amazed. The solution was better than what the legacy system provided, with a different approach that addressed their needs more effectively.
I hadn’t prescribed any specific UI or user experience. I’d let the AI learn from the conversation transcripts and user stories, which were written from a business perspective. This approach created something that genuinely solved their problems.
The reaction from other stakeholders, including the company’s CFO, was even stronger. “What are you giving me?” she asked, describing tools that addressed pain points she’d faced for years. These solutions would give her everything she needs to work through these issues—and even anticipate problems before they become critical.
Beyond Implementation: Discovering Insights
The AI implementation revealed something unexpected: domain events we hadn’t considered. Most people think of things like invoice due dates as simple date fields, but the AI identified them as actual events—“this invoice has aged because payment terms have passed.”
When those events happen, there are policies for how to handle them. This perspective exposed business logic that most people overlook when focusing only on dates and deadlines.
The Power of Captured Conversations
This experience shows the power of having conversation transcripts. A 40-minute conversation from two months ago, captured in a transcript, became the foundation for working software that solved real business problems.
During those two months, I was busy with other work and had forgotten the details. I didn’t need to re-read transcripts or listen to recordings. I leveraged AI to consolidate the conversation into documentation, perform business analysis, create stories, and build something using our existing codebase.
The result was working software we could put in front of stakeholders to continue the conversation, impress them with what’s possible, and collaboratively find the best solutions to their problems.
Continuing the Cycle
When we showed the software to stakeholders, those conversations were also recorded and transcribed. As I go back to refine the implementation, I’ll feed those new transcripts to the AI.
“What do we need to work on next?” The AI will extract the relevant feedback from sprint reviews and stakeholder discussions, focusing on whichever features we’re prioritizing. I won’t need to remember every detail from every conversation.
This creates a continuous cycle: conversation → transcript → AI analysis → implementation → stakeholder feedback → new conversation. Each iteration builds on the last, with AI as the bridge between spoken words and working code.
What I’m Noticing
I’m noticing that AI isn’t just a coding assistant—it’s a business analyst that never forgets. It captures the nuances of stakeholder conversations and transforms them into actionable development work.
The value isn’t in replacing human judgment, but in amplifying it. The AI handles the details I’d forget, the documentation I’d postpone, the analysis I’d rush through. This frees me to focus on what humans do best: understanding context, building relationships, and making strategic decisions.
Most importantly, I’m noticing that the gap between conversation and working code has never been smaller. What used to take weeks of analysis, documentation, and handoffs now happens in hours, with better results and happier stakeholders.
The question I’m sitting with now is: How many other valuable conversations are sitting in our archives, waiting to be transformed into solutions?
Leave a Reply