From Conversation to Documentation: A Modern Dev Workflow with AI

We've all been there. You've just wrestled with a complex technical problem for hours, maybe even days. You've navigated the trade-offs, explored the options, and finally landed on a solution that actually works.

...and then a little voice whispers, "Now you have to document it."

The energy drains from the room. Writing documentation, Architecture Decision Records (ADRs), and blog posts often feels like a chore - an after-the-fact task that's easy to put off until it never gets done.

But what if it wasn't? What if documentation was a natural outcome of the problem-solving itself? For the last few weeks, I've been refining a workflow that does exactly that. It all comes down to treating my AI assistant not as a search engine, but as a development partner.

#The Workflow: A Four-Step Process

Instead of solving a problem in isolation and then writing about it, I now do both at the same time. Here's the process.

#1. The Collaborative Brainstorm

It all starts with a conversation. Instead of just Googling for an answer, I open up a chat with an AI and describe my problem, just like I would to a colleague.

Today, for example, I was working on a C# API and needed to handle concurrency to prevent race conditions. So, I just asked.

This kicks off a collaborative dialogue. Whether I'm diving into a completely new topic or just want a sanity check on something I know well, the process is the same: the AI suggests options, I ask clarifying questions, and together we explore different paths, uncovering new approaches or details I might have otherwise missed.

#2. Exploring and Refining Options

This is where things get interesting. The AI isn't a "one and done" answer machine - it's a sounding board. We discussed multiple strategies for my locking problem:

• Database-level pessimistic locks
• An in-memory, C#-only solution
• A full-blown distributed lock with Azure Blob Storage

For each option, we dug into the trade-offs and performance implications. That back-and-forth helps clarify my own thinking - I often find I understand a problem better after explaining it than before.

#3. Making the Decision

After exploring the options, a clear winner emerged for my current needs: a high-performance, in-memory lock that was architected to be easily swappable later. The decision was made, and the solution was implemented.

In a traditional workflow, this is where the "real work" ends and the "documentation work" begins. But not anymore.

#4. Generating the Artifacts (Instantly)

Here's where the workflow pays off. All that context from the conversation - the problem statement, the options considered, the trade-offs, the final decision - is already sitting in the chat history.

So, I simply asked the AI to use it.

First, I needed an ADR for our internal repository. I gave the AI our company's ADR template and a simple prompt.

Seconds later, I had a fully filled-out ADR capturing the entire decision-making process. No staring at a blank page required.

This blog post? Same thing. I asked the AI to describe the process we just went through. A bit meta, but it works.

#Less context switching, more done

For me, the biggest win isn't the time saved on writing - it's that the documentation actually gets written. Documenting something days after the fact means reconstructing context you've already forgotten. Doing it during the conversation means the context is right there.

The quality is better too. An ADR written at decision time captures the "why we didn't do X" just as clearly as "why we did Y" - and that's usually the more valuable part six months later when someone asks.

If you haven't tried using an AI as a thinking partner rather than an answer machine, give it a go on your next tricky problem. You might end up with working code and a draft ADR by the time you're done.