AI autonomy – AI can speed delivery, but unchecked autonomy can widen “cognitive debt,” increasing outage risk and eroding competitive differentiation. Misryoum urges matching AI control to blast radius and what truly defines your moat.
A senior engineer once paused mid-explanation of a critical algorithm and said AI wrote it—leaving the team with a working system they couldn’t fully explain.
That kind of disconnect isn’t brand-new.. Teams have always inherited software they didn’t build.. What’s changed with modern AI coding assistants is the cover story: the work arrives quickly. looks complete. and then knowledge evaporates faster than the organization’s usual habits can preserve it.. Misryoum sees the pattern forming around AI autonomy—describe the outcome. let the agent iterate. merge the pull request. and move on.. If nobody can answer why it works the way it does. the organization doesn’t just outsource implementation; it quietly purchases a dependency it can’t maintain when conditions change.
The central problem is bigger than “bad code.” The deeper issue is cognitive debt: the growing gap between how much code exists and how much anyone can truly reason about it.. Traditional technical debt shows up in backlog and failing tests.. Cognitive debt can sit invisible in plain sight. only becoming obvious when an incident hits. a customer question lands. or an edge case appears under load.. And because AI accelerates both production and release cycles. that gap can widen faster than review processes. onboarding. or documentation can catch up.
Misryoum breaks the decision down into two dimensions that most teams treat separately—sometimes even unknowingly.. The first is business risk: what’s the blast radius if the system fails or behaves incorrectly?. A bug in an internal tool might cost an afternoon.. A bug in authentication, billing, or pricing can affect customers immediately and trigger reputational damage.. The second dimension is competitive differentiation: does this piece of software embody how your company wins—its architecture. performance trade-offs. domain knowledge. and the hard-won judgment that shaped the system?. When your moat is tied to reasoning and institutional memory, code alone isn’t the advantage.
When these two dimensions aren’t considered together. teams can end up automating the wrong things—fast delivery without preserving understanding.. In practice, AI can improve output velocity, but it can also change who absorbs the cost of quality.. If review becomes lighter because the code “looks right. ” rework can shift to the engineers who are most capable of catching subtle defects—people who can least afford to lose time to repeated debugging.. The feedback loop breaks: teams perceive speed while the actual work of comprehension quietly accumulates.. That’s how the organization ends up with systems that can run, but can’t be confidently extended.
This is where AI autonomy becomes a strategic control question rather than a tooling preference.. Misryoum frames a useful lens: match how much AI drives to the stakes of what the AI is touching.. At low risk and low differentiation. fuller automation can be appropriate because failures can be caught quickly and the work doesn’t represent unique business logic.. At low risk but high differentiation—like UX behavior or cost dashboards where design judgment matters—AI can help generate options. but humans need to steer the trade-offs and ensure the system remains explainable to the team that will own it later.
The danger grows in the quadrants where stakes are high.. For supervised automation (high risk. low differentiation). a human may remain the safety gate. but the gate has to be more than a checkbox.. The critical question is whether an engineer can trace and explain what happens in every state transition—not just whether tests pass.. If the answer is no, then oversight isn’t really oversight; it’s passive approval.. For human-led craftsmanship (high risk. high differentiation). AI should support scoped subtasks after the design is already reasoned through—because that’s where understanding has to survive changes. staffing shifts. and the next incident review.
This isn’t an argument against using AI.. Misryoum’s point is sharper: the existence of AI doesn’t remove the need to know what you’re shipping.. The most convincing pro-AI stance isn’t “use it everywhere.” It’s using AI in ways that preserve comprehension—interrogating outputs. demanding rationale. and aligning review depth with blast radius.. If your organization treats every AI-generated pull request as interchangeable with a human-written one. it risks training engineers to think in patterns rather than systems. producing code that’s easier to generate—and harder to defend under pressure.
Misryoum also expects the competitive angle to intensify.. If the business moat is tied to architecture. performance tuning. and domain-specific failure handling. then relying on AI for core design choices can turn differentiation into commodity output.. Even if your model is good, your competitors can often replicate the same code patterns with similar tools.. The real separation then becomes organizational: who can explain the reasoning behind the implementation. who can evolve it. and who can anticipate how it breaks in situations the model didn’t predict.
So what should teams do next?. Misryoum recommends treating cognitive debt as a first-class risk and building AI governance that maps to the quadrants—tightening oversight where a failure would harm customers or where the code represents your strategic advantage.. That means the bar for approval should shift from “the pipeline succeeded” to “someone on the team can defend what this does. explain the trade-offs. and apply that understanding to improve it.” In other words: not just owning the repo. but owning the mental model.
When this discipline is absent. automation can accelerate the very erosion that traditional software organizations have spent decades trying to avoid.. A system that runs today but can’t be diagnosed tomorrow doesn’t scale operational trust.. And a team that can’t extend its own architecture loses leverage in every future decision.. Misryoum’s bottom line: don’t automate your moat—match AI autonomy to risk and competitive stakes. and protect the understanding that makes the code truly yours.