Your Meetings Are the New Technical Debt: AI Compounds It

• Technical Debt Is Not Bad Code
• Conway's Law Has a New Corollary
• How AI Handoffs Compound Noise Into Spec
• The Danger of Looking Like Progress
• Decision-Making Is Engineering Infrastructure

A feature request arrives on Tuesday. By the time it reaches the dev team it has been touched by five people and four AI tools, none of them in the same meeting, none of them working from the same source of truth. Sales drafted the original pitch with an AI assistant. Product synthesized the Slack thread into a PRD with another one. The ticket was auto-generated from the PRD. The standup summary was produced by a third tool that nobody reads past the first line. The developer who picks up the ticket has a clear spec, a clean acceptance criteria, and absolutely no idea what problem the feature is actually supposed to solve.

The code that gets written is technically correct. The AI that helps write it follows the specification faithfully. The specification was generated from a document that was summarized from a message that was paraphrased from a meeting that never reached a real decision. The problem is not the model. The problem is a hundred meters upstream. This is communication debt, and it compounds exactly the way technical debt does in your codebase.

This is communication debt, and it works exactly like technical debt. It accumulates through shortcuts that feel productive in the moment. It compounds quietly in the background while sprint velocity looks fine. It surfaces months later, when you are three features deep in the wrong direction and the retrospective turns into an archaeology exercise. The only thing that has changed is the rate. AI has made communication debt faster to accumulate, harder to see, and significantly more expensive to unwind.

Technical Debt Is Not Bad Code

The common misunderstanding of technical debt is that it means messy code: naming that could be cleaner, a function that grew too large, tests that were deferred. That is not quite right. Technical debt is accumulated shortcuts in engineering infrastructure that look productive in the short term and impose a compounding cost over time. The debt is not in the code itself. It is in the gap between what the system looks like and what it would need to look like to support where you are going. The code still runs. The tests still pass. The cost shows up when you try to change something and find that every modification requires untangling something else first.

The same structure exists in organizational decision-making. Vague requirements that everyone agrees to interpret loosely. Ownership that is nominally clear and practically contested. RFCs where the open questions are left open because closing them requires a conversation nobody wants to have. Standups that produce a list of what people did rather than what the team has decided. None of these feel broken in the moment. They feel like reasonable compromises against limited time. But each one creates a gap between what your organization knows and what it has committed to, and that gap is the debt. It does not appear in any dashboard. It does not trigger any alert. It accumulates in the space between what was said in the meeting and what people walked away believing.

Conway's Law Has a New Corollary

In 1968, Melvin Conway wrote that any organization that designs a system will produce a design whose structure mirrors its communication structure (Conway, 1968). The claim seemed intuitive but the evidence took decades to accumulate. In 2012, researchers at Harvard Business School and MIT tested what they called the mirroring hypothesis, the idea that product architecture reflects organizational architecture, across a set of software projects (MacCormack et al., 2012). The finding was unambiguous: products built by tightly coupled, closed organizations were significantly less modular than products built by loosely coupled organizations with open communication. The code was a direct impression of how the people who wrote it were allowed to talk to each other.

What Conway described was a property of human systems. What AI adds is a multiplier. The 2026 Microsoft Work Trend Index found that organizational factors account for 67% of the reported impact of AI tools, compared with 32% for individual behavior and mindset (Microsoft, 2026). Read that again: two thirds of what determines whether your AI investment actually works is decided before any individual picks up a tool. It is decided in how your functions are structured, how decisions are made, how requirements travel from a business objective to a developer's task list. AI does not change Conway's Law. It speeds up the encoding. Whatever conversation pattern your organization has, AI embeds it into artifacts faster, at higher volume, with a surface polish that makes the underlying confusion harder to detect. The corollary is this: clean communication produces clean systems faster than ever before. And broken communication produces broken systems faster than ever before too.

How AI Handoffs Compound Noise Into Spec

The mechanism is not subtle once you see it. Every function in a modern organization is now using AI tools, and most of them are using those tools in isolation. Sales is generating outreach, pitches, and summaries with one AI. Product is synthesizing research, writing specs, and refining requirements with another. Marketing is producing copy, campaigns, and positioning with a third. Engineering is generating, reviewing, and documenting code with a fourth. Each tool is doing its job. Each function is producing more output than it did a year ago. The problem is that each function's AI output is becoming the next function's AI input. None of those handoffs are designed.

Research on AI systems shows that errors in multi-step pipelines do not cancel. They compound. Xu et al. formally proved in 2024 that hallucination in large language models is mathematically unavoidable: any system that generates probable sequences from learned distributions will sometimes produce outputs not grounded in fact (Xu et al., 2024). In multi-step chains, these errors trigger what researchers call the snowball effect: a small inaccuracy in step one becomes a plausible-sounding assumption in step two, which becomes an accepted premise in step three, which becomes a committed specification in step four. By the time it reaches engineering, the error has been validated by every preceding layer.

This is not a new problem. Boris Lazarov described it in 2014 as the broken telephone effect in software development: every handoff in the requirements chain degrades the original signal, and the further down the chain you are, the more distorted what you receive has become (Lazarov, 2014). What is new is the velocity and the aesthetics. When a human product manager wrote a vague PRD, the vagueness was visible. Bullet points were sparse. Sections were thin. When an AI generates a vague PRD, it fills every section with confident, well-structured prose. The output looks thorough. The coverage looks complete. The noise is invisible because it is formatted like signal. Research on AI-generated PRDs has found that teams completing all 10 standard PRD sections ship 34% fewer post-launch bugs (Scriptonia, 2026). But that figure assumes the sections contain real decisions. AI makes it trivially easy to produce a document with 10 sections, none of which close an open question.

The Danger of Looking Like Progress

This is the thing that makes communication debt more dangerous than technical debt in the AI era. Technical debt has visible symptoms. Code slows down. Reviews get harder. Refactors block each other. The system eventually tells you something is wrong: through latency, through error rates, through the expression on the face of every engineer who opens that module. Communication debt has no equivalent signal. Everything looks like it is working.

Velocity is up. Jira tickets are being closed. The weekly update to leadership is well-formatted and comprehensive. The standup is producing summaries. The PRD is thorough. The RFC got comments and a sign-off. None of these are indicators that the underlying decisions were good. They are indicators that the process is producing artifacts. Artifacts and decisions are not the same thing. An artifact is evidence that someone did the work of producing a document. A decision is a commitment that reduces uncertainty and allows the next person in the chain to operate on solid ground. Most AI tools are extremely good at producing the former and have nothing to say about the latter.

The hype cycle around AI wrapper products makes this worse. Products are being sold into every function with a productivity pitch: more emails sent, more specs generated, more content produced. Nobody is selling cross-functional coherence. Nobody's pricing slide has a line item for signal quality. The result is an org that has dramatically increased its throughput of noise while maintaining, or reducing, its capacity to actually decide anything. You can move faster through a broken process. The retrospective just comes sooner.

Decision-Making Is Engineering Infrastructure

The frame that tends to unlock this is treating your decision-making infrastructure the same way you treat your engineering infrastructure. You would not ship code without a definition of done. You would not merge a PR without a reviewer. You would not deploy to production without tests. These are not bureaucratic requirements. They are quality gates that exist because the cost of skipping them is higher than the cost of applying them. Your meetings, your RFCs, your standups, and your requirement documents are infrastructure too. The question is whether you are running them with the same discipline.

What a meeting actually needs to produce is a decision, an action, or an owner. Not a summary. A summary is documentation that a meeting occurred. A decision is documentation that uncertainty was reduced. The difference is whether the next person in the chain is operating on clearer ground than they were before the meeting happened. If they are not, the meeting produced debt. As argued in an earlier post on agentic coding as an amplifier, the tools amplify whatever system you already have, the good parts and the bad parts with equal force. A strong decision culture with AI becomes dramatically more effective. A weak decision culture with AI becomes dramatically faster at producing the wrong things.

The same applies to your codebase patterns themselves. As covered in AI Doesn't Read Code. It Reads Patterns., AI does not comprehend your system. It extends whatever signal your codebase gives it. If that signal is built from requirements that were never actually agreed on, the AI will extend the confusion faithfully. The Company Knowledge OS framing is useful here: the question is not whether you are capturing information, but whether what you are capturing represents real decisions or the appearance of them.

Concretely, this means a few things. Ambiguous requirements should be treated as bugs, not known issues to be interpreted in good faith by the next person in the chain, but defects that block forward progress until they are resolved. RFCs should close their open questions before sign-off, not leave them as items to be decided later by whoever builds the thing. Standups should end with one clear answer to "what does the team do differently today than they did yesterday." Anything else is a status report that could have been an email. These are not process for process's sake. They are the precondition for AI to do what it is capable of doing.

The organizations that will extract durable value from AI are not the ones that moved fastest to deploy tools into every function. They are the ones that used the pressure of AI adoption to ask a harder question: what is the quality of the signal that these tools are going to amplify? The teams already doing this, building AI-era team structures with intention and treating architecture as a communication problem before a technology problem, are the ones whose velocity is compounding in the right direction. Everyone else is just shipping faster toward the same retrospective.

Your meetings have always been the foundation of your codebase. AI just made the connection impossible to ignore.

References