The reasoning behind your code exists. Your team just can't find it.
By Kaia Colban
Last month I spent 45 minutes tracking down why a service in our codebase retries exactly three times. Not because nobody knew. Someone did. The decision was right there in a Claude Code session from two months earlier: a specific constraint, a rejected approach, a comment about what would break if we went higher. The whole thing, written out clearly, by the engineer who understood it best.
Closed tab. Personal account. Gone.
I'm not telling this story because it's unusual. I'm telling it because in 2026, it should be.
The thing that actually changed
AI now writes around 46% of the code that engineers at high-adoption teams ship. That number gets quoted constantly. What doesn't get quoted is what comes with it: for the first time in the history of software engineering, the reasoning behind a code change is being written down in real time, by the person who understood it most, with no extra effort.
Before AI coding tools, the why behind a decision lived in three places: the commit message (one line, if you were lucky), the ticket (usually a feature request with no context about tradeoffs), and the engineer's head (perfect, until they left or got pulled onto something else). If you needed to know why the payment service retried three times, you walked over and asked. Slow, but possible.
The reasoning was real. It was recoverable through a human. That was the system.
Now that same engineer works through a 14-turn conversation in Claude Code. They explain the constraint. They reject two approaches for specific reasons. They catch an edge case mid-session. They commit. The diff looks identical to what it would have been three years ago. But the reasoning? It's sitting right there, in the session, in full sentences.
This is the most under-discussed shift in engineering right now.
The reasoning isn't disappearing. It's just not findable.
I keep seeing the framing that AI is making engineering context worse: decisions made faster, less deliberation, reasoning that evaporates. I think that's backwards.
The actual problem is different: we have more captured reasoning than at any point in engineering history, and it's completely disorganized.
That's not a context loss problem. It's a context indexing problem. They look the same from the outside. They're very different to solve.
Your team's sessions live in chat windows that close. In Claude.ai accounts tied to individual logins. In Cursor's local history on one laptop. In Codex threads that nobody exported. The reasoning is there. It's just trapped in thousands of disconnected threads, none of which are searchable, shareable, or indexed against the codebase they describe.
And meanwhile, the standard response to this is to ask engineers to write more documentation.
Why the standard answer is anti-leverage
I've been in the ADR mandate meeting. Probably you have too. Someone notices that decisions aren't being captured, so the team rolls out a template. Write up your architectural decisions. Explain your reasoning. Keep it current.
It fails. Every time. Not because engineers are bad people who don't care, but because it asks them to produce a worse version of something they already produced. The Claude Code session already has the reasoning. Asking an engineer to re-derive it in a Notion doc two days later, from memory, is strictly worse than what already exists. And it's more work.
Faros AI's research across more than 10,000 developers found that teams with high AI adoption are merging 98% more PRs per day while review time has gone up 91%. Volume is surging. So is the reasoning behind all that volume: sitting in sessions, unindexed.
Asking engineers to also maintain documentation on top of that is not going to work. It hasn't worked. Onboarding still takes 4 to 6 months at most companies. New engineers still spend weeks asking questions that were answered definitively, somewhere, in a session nobody can point them to.
The right move is to take what already exists and make it usable.
What usable looks like
A team thinking substrate is a continuous, automatically maintained, team-owned record of the team's own reasoning. Sessions get ingested from Claude Code, Cursor, Codex. The decisions, dead ends, open threads, and handoffs get extracted into first-class objects. The next engineer who needs to know why the payment service retries three times searches and finds the actual session where that was worked out.
Not a wiki. Not a Notion page someone half-updated in Q3. The session itself, indexed, searchable, shared.
The difference matters because knowledge bases require authoring. Someone has to write the thing. The whole point of a substrate is that nobody has to author anything extra: the reasoning is being written every day by the work itself. The substrate is the layer that makes it findable.
Average prompt length in AI coding tools grew nearly fourfold between 2024 and 2025, from around 1,500 to over 6,000 tokens, as agentic workflows got more complex. That's not bloat. That's reasoning. That's your team working through problems out loud, in text, at a level of detail that never existed before. The question is whether it compounds or evaporates.
Right now, it evaporates. Session by session, engineer by engineer, sprint by sprint.
The opportunity is abundance, not recovery
This isn't about preserving context before it's lost. It's about using context that's already there.
With 84% of developers now using AI tools in their daily workflow, your team is generating a record of its own reasoning at a scale that no documentation initiative ever achieved. Not because anyone mandated it. Because the work itself produces it as a byproduct.
The engineers who worked on your most critical systems this quarter didn't just ship code. They had conversations. They made tradeoffs. They explained constraints to a model that asked good follow-up questions. That reasoning exists. In text. Right now. Somewhere.
The question is whether your team can find it next month, or whether the next engineer is going to spend 45 minutes rediscovering what their teammate figured out in a session that closed on a Tuesday.
That's a substrate problem. It's solvable. And in five years, we're going to look back on this period as the years we let our best engineering thinking sit in chat logs that nobody opened.
You can start fixing that today. Here's where to start with Lore.
FAQ
Isn't this what design docs and ADRs are for?
Design docs capture decisions after the fact, filtered through memory and polish. AI sessions capture reasoning in real time, including the dead ends and the tradeoffs that didn't make it into the final doc. Both have value. The session is strictly more complete.
What's the difference between a knowledge base and a substrate?
A knowledge base requires someone to author content and keep it updated. A substrate ingests what's already being produced: the sessions, the decisions, the handoffs. Nobody writes extra. The reasoning gets structured automatically from the work that's already happening.
Do engineers have to change how they use AI tools?
No. That's the whole point. The sessions are already being generated. A substrate indexes them without requiring any change to how engineers work.
What if sessions contain sensitive or incomplete reasoning?
Good substrates handle this at the team level: what gets shared, what stays private, what counts as a decision vs. a half-formed thought. The goal isn't to expose everything. It's to make the useful parts findable by the right people.
How is this different from just searching Slack or Notion?
Slack captures conversation fragments. Notion captures whatever someone decided to write down. A substrate captures the actual engineering reasoning, structured by project and decision, indexed against the codebase. The signal-to-noise ratio is completely different.