Part 2 of 12 – Conversation Intelligence Platform series Back to Part 1
There’s a version of the AI-in-software-development story that you’ve probably heard: developer uses Copilot to write boilerplate faster, saves a few hours a week, productivity up 20%. That’s not this story.
What Charles Chance and his team did here was different in kind, not just degree. The platform was not built and then documented. It was documented first – thoroughly, precisely, as a set of structured briefs that could be consumed and reasoned about by both humans and AI – and then built. The distinction sounds subtle. The implications are not.
Let me be concrete about what that actually looked like.
Before a line of product code was written, the team produced a set of architecture briefs. Not vague design documents. Not PowerPoint slides. Precise, structured documents: the API architecture, the auth model, the service decomposition map, the Keycloak migration plan. Each one described the system’s goals, the constraints, the decisions already made, and the questions still open. They were written to be fed directly into an AI context window – not as an afterthought, but as the primary design medium.
The effect was that the AI could reason about the architecture, not just implement it. When you hand an AI a precise brief and ask it to think about where the design might fail, or how one service’s assumptions conflict with another’s, you get something qualitatively different from autocomplete. The architecture briefs contain notes about inconsistencies that were surfaced and resolved. There are ADRs – Architecture Decision Records – documenting not just what was decided but why, what the alternatives were, and what the follow-on questions are. Those records exist because the AI asked for them, or because it became obvious when reasoning with AI that undocumented decisions were a liability.
This is not AI replacing engineering judgement. It’s AI amplifying it, at a pace and with a consistency that a small team would struggle to sustain.
The result is a platform that shipped fully documented. Not partially documented, not “we’ll write the guides later.” The API reference for Conversation Intelligence was written before the service went live. The OpenAPI spec is the contract, not a post-hoc description – Part 11 covers how that’s surfaced to developers. The internal ADRs exist and are findable (Part 12 covers how). Any engineer picking up this codebase in two years will find the decisions recorded and the reasoning preserved.
That matters enormously. I’ve seen too many engineering projects where institutional knowledge lives only in the heads of whoever was there at the time. Decisions get unmade and remade. Mistakes get repeated. Onboarding takes months. What Charles and his team have avoided, by building documentation-first with AI, is the gradual entropy that turns a clean codebase into an archaeology project.
The productivity story is also real, and I want to be honest about what it means.
A platform of this scope – a new service architecture, a new auth model, a Keycloak migration, a documentation site, an internal knowledge system, and the Conversation Intelligence product itself – would historically have taken a team considerably larger than the one that built it. It took the time it took because the team was small and focused, not because AI did the work for them. What AI did was remove the bottlenecks. Architecture review that would previously have required bringing in senior people for days of discussion happened through iteration with a well-briefed AI. Documentation that would have been deferred until after launch happened during the build because the AI could draft it from the briefs already written.
The honest answer to “how long did this take?” is: less than it should have, for something this large. And the honest reason is: AI.
There’s a broader implication here that I think the industry is still figuring out. The old model was: you write the spec, you write the code, you write the tests, eventually you write the docs. Each stage is bottlenecked by human time and human attention. AI doesn’t collapse that model entirely – you still need engineers who understand what they’re building – but it does change where the time goes. If your documentation is machine-readable from the start (which it is, if you’re writing it to be fed to an AI), and your decisions are recorded as they’re made (which they are, if you’re using ADRs), then the cost of quality is no longer prohibitive for a small team.
I don’t want to oversell this. Charles and his team are genuinely excellent engineers. The AI didn’t make this platform; they did. But they made something bigger than they could have made without it, and they made it faster, and they made it better documented, and I think that’s worth being straight about.
What does that mean practically? It means we can ship independently versioned services without coordinating a single monolithic release. It means the documentation is accurate because it was written from the same source of truth as the code. It means a new engineer joining the team can read the ADRs and understand why the auth model works the way it does, rather than asking Charles and hoping he remembers.
And it means, I think, that this is the model for how serious engineering teams will work from here on. Not AI-assisted. AI-integrated – from the first design brief to the last test.
Part 12 of this series covers the internal documentation infrastructure specifically – the ADR system, the simwood-docs MCP server, how you actually make all this knowledge queryable. That’s the bit most teams overlook until it’s too late.
Previous: Part 1 – The biggest thing we’ve ever shipped
