Here’s something I spent six months assuming was true before I realized it was completely wrong: you need a separate pipeline to extract knowledge from LLM conversations.
The standard RAG approach: the LLM generates a response, a separate system processes it — chunking, embedding, maybe another LLM call for summarization — and the results go into a vector database for later retrieval.
It works. It’s also an extra pipeline, extra LLM calls, extra latency, extra failure modes, and — I eventually realized — extra mediocrity. Because the best knowledge extractor isn’t a separate system processing transcripts after the fact. It’s the model that was there when the knowledge was created.
The “aha” moment
I was watching a conversation between one of our engineers and the AI. They were debugging a subtle issue with retry logic in a payment service. Over forty minutes, the AI explored several hypotheses, discovered a race condition, traced it to a specific timing window, and proposed a fix.
The conversation was 50K tokens. The actual insight — “there’s a race condition in the retry logic where duplicate charges can slip through a 200ms window when the idempotency key hasn’t propagated” — was maybe 60 tokens. Structured as a knowledge item with the right type, scope, and tags, it would be instantly findable next time anyone touched that service.
I looked at our RAG pipeline, which was processing this conversation after the fact. It was chunking the transcript, embedding the chunks, and storing them. If someone searched for “payment retry issues” later, they’d get… chunks of a conversation. Maybe the relevant chunk. Maybe the chunk where the engineer was exploring a wrong hypothesis. Maybe both, with no way to distinguish them.
The model that just spent forty minutes understanding this problem could produce a clean, typed, accurate knowledge item in 60 tokens. The pipeline was producing noisy, untyped chunks of questionable relevance. And it cost an extra LLM call to do it.
That’s when it clicked: stop building a pipeline to process what the model already knows. Let the model capture the knowledge itself.
Why the writer is the best extractor
A separate pipeline sees the response text. That’s it. It doesn’t see the user’s question, the files that were read, the tool calls that were made, the dead ends that were explored, the reasoning chain. It has to decide what’s important based on the output alone.
The model that generated the response has everything. It made the decision. It understands the constraints. It explored the alternatives. It knows why the race condition matters — not just that it exists, but that it’s specific to concurrent requests within a particular time window, and that the fix requires changes in two files, not one.
This is the difference between a system that captures “there’s a race condition” (sort of useful) and one that captures the full context of why it matters and what to do about it (actually useful).
The flywheel nobody expects
The part that surprised me most was what happened after we let the model extract its own knowledge. It created a flywheel I hadn’t anticipated:
Engineer works with AI → AI captures knowledge → Next session, that knowledge is available → AI is smarter → Engineer works faster → More conversations → More knowledge → Loop.
Nobody was maintaining the knowledge base. Nobody was running documentation sprints. The team was just working, and the system was learning from the work.
After a few months, something subtle shifted. Engineers started trusting the AI’s context. Instead of re-explaining architectural decisions, they’d just start working and the AI would already know. That never happened before.
What the model learns to capture
The model doesn’t extract everything — that would flood the system with noise. It extracts typed knowledge: decisions with rationale, error patterns with fixes, conventions with examples, expertise signals with context. Each has a specific structure.
And it doesn’t extract on every turn. Routine coding — fix this syntax error, rename this variable — produces nothing. The model extracts when it encounters genuinely durable knowledge. Things that would save the next engineer from re-discovering the same insight.
When the model completes a meaningful piece of work — a bug fix, a feature, a refactor — it captures that too. What was done. What the outcome was. What was learned. This is the AI’s work diary, available to anyone who picks up the same work later.
Why not both?
I tried running both approaches and it was worse than either alone. Two systems extracting from the same conversation produced duplicates with slightly different structure and different quality signals. Engineers stopped trusting the knowledge base because they couldn’t tell which version of an insight was authoritative.
One extraction path. One source of truth. One quality bar.
The insight underneath the insight
The conventional wisdom is that knowledge extraction is a pipeline concern. This comes from the document-processing world, where you have static documents and need to extract structured data from them.
But a coding AI isn’t processing static documents. It’s participating in the creation of knowledge. It’s the primary source, not a downstream consumer.
Making the model extract its own knowledge isn’t a shortcut around building a proper pipeline. It’s recognizing that the best knowledge extractor is the one that was there when the knowledge was created.
The six months I spent building that separate pipeline were instructive. But the six months after I removed it were productive.
Next: what happens when documentation stops being a chore and starts being a side effect.