The tacit knowledge point is the one nobody wants to say out loud because it implies the whole documentation push is partly theater. I've sat in enough post-mortems to know the real process never lives in Confluence. It lives in the senior engineer who instinctively knows which PR is going to get quietly reworked before it ships. That knowledge doesn't get captured — it gets inherited, or it gets lost. But there's a step before the redesign question that this piece skips. Most teams don't have an honest picture of their explicit practices either. Not their runbook version — their actual version. What's really happening in review, in testing, in release. They assume the foundations are sound because nobody ever checked. AI didn't create that gap. It just made it matter more. When you accelerate a broken process you get more broken, faster. It's what I've been building against — measuring the actual process from toolchain data, not from what teams report. The delta between assumed and real is almost always worse than expected.
Most AI adoption advice optimises the existing process. Tickets, standups, code review, documentation — these didn't emerge from first principles. They evolved as workarounds for human limitations: forgetting, context loss, blind spots, communication bandwidth. AI doesn't share most of those constraints. Embedding it into workflows designed around human limitations means asking it to operate inside constraints built for a problem it doesn't have. The argument here is that the failure mode isn't tooling or team readiness — it's that the process itself was always the bottleneck.