The Paradox of Agentic AI in Software Engineering

Navigating Cognitive Debt, Analysis Paralysis, and the Shift to Spec-Driven Development

The integration of agentic artificial intelligence into the discipline of software engineering was initially heralded as the ultimate panacea for the industry's most persistent and costly bottlenecks. Chief among the promises made by early adopters and platform vendors was the total eradication of analysis paralysis, the exponential acceleration of code generation workflows, and the liberation of human developers from the tedious, boilerplate structuring that has historically stifled creative architectural design. The prevailing hypothesis suggested that by offloading the mechanical act of writing syntax to large language models, human engineers would be free to operate entirely at the strategic level, thereby compressing project timelines and drastically elevating the quality of software outputs.

However, as agentic AI deployment matures beyond isolated, experimental applications and begins to dominate enterprise-level development environments, a profound and highly complex paradox has emerged. Empirical studies and widespread industry observation indicate that while artificial intelligence drastically reduces the barrier to entry and the marginal cost of producing structural code, it frequently induces a net slowdown in overall project completion times and significantly increases the cognitive load placed on human operators. The transition from linear, manual coding to an AI-augmented, supervisory workflow has fundamentally altered the socio-technical dynamics of software engineering. It has successfully resolved traditional forms of procrastination and architectural indecision, yet simultaneously introduced catastrophic vulnerabilities in the form of cognitive debt, intent debt, and new, technologically sophisticated avenues for task avoidance.

This comprehensive analysis investigates the multifaceted, deeply nuanced impact of agentic AI on modern software development. It explicitly explores how AI tools successfully function as architectural sounding boards to remove initial decision-making blockers—allowing developers to empirically compare competing architectures rather than relying solely on abstract cognitive deliberation. Furthermore, the analysis evaluates the systemic risks that emerge when developers become trapped in "vibe coding" dead loops and liminal states of oversight-driven exhaustion, leading to mature projects where no single human comprehends the underlying design. Finally, the podcast investigates the necessary emergence of Spec-Driven Development (SDD) as a foundational architectural anchor. By shifting the primary development artifact from human-written code to executable, machine-readable specifications, SDD offers a robust paradigm capable of grounding agentic teams, mitigating the triple debt crisis, and structurally preventing the catastrophic failures that occur when human comprehension is outpaced by machine generation.

1. Fundamentals of Software Architecture Chapter 19: Architecture Decisions | by mohammed sallam | Medium, https://medium.com/@mohamedsallam953/fundamentals-of-software-architecture-chapter-19-architecture-decisions-86638af4361b
2. How do I deal with analysis paralysis? - Software Engineering Stack Exchange, https://softwareengineering.stackexchange.com/questions/83117/how-do-i-deal-with-analysis-paralysis
3. Getting through Analysis Paralysis : r/SoftwareEngineering - Reddit, https://www.reddit.com/r/SoftwareEngineering/comments/nsao4d/getting_through_analysis_paralysis/
4. Do AI coding tools help with imposter syndrome or make it worse ..., https://stackoverflow.blog/2025/07/31/do-ai-coding-tools-help-with-imposter-syndrome-or-make-it-worse/
5. Talking to AI actually helps me with procrastination : r/Procrastinationism - Reddit, https://www.reddit.com/r/Procrastinationism/comments/1jezzrn/talking_to_ai_actually_helps_me_with/
6. AI Coding assistants has been a game changer : r ... - Reddit, https://www.reddit.com/r/ADHD_Programmers/comments/1s03hc4/ai_coding_assistants_has_been_a_game_changer/
7. The AI Procrastination Paradox: Why Smart Tools Are Creating Smarter Excuses | Medium, https://medium.com/@insightarpan/the-ai-procrastination-paradox-why-smart-tools-are-creating-smarter-excuses-ea9a1658f963
8. Vibe coding is procrastination in a productivity costume (and I'm ..., https://www.reddit.com/r/VibeCodingSaaS/comments/1s8q3bd/vibe_coding_is_procrastination_in_a_productivity/
9. Does anyone else get stuck in what feels like a “vibe coding dead ..., https://www.reddit.com/r/vibecoding/comments/1qwirtd/does_anyone_else_get_stuck_in_what_feels_like_a/
10. AI psychosis is real, and you probably have it - Vellum, https://www.vellum.ai/blog/ai-psychosis-is-real
11. The paradox of acceleration: Overcoming AI-induced decision ..., https://www.thoughtworks.com/en-us/insights/blog/generative-ai/paradox-acceleration-overcoming-ai-decision-fatigue-bottlenecks
12. Measuring the Impact of AI on Experienced Open-Source Developer Productivity - Reddit, https://www.reddit.com/r/programming/comments/1lwk6nj/measuring_the_impact_of_ai_on_experienced/
13. Cognitive debt: The hidden risk in AI-driven software development, https://getdx.com/blog/cognitive-debt-the-hidden-risk-in-ai-driven-software-development/
14. From Technical Debt to Cognitive and Intent Debt: Rethinking ... - arXiv, https://arxiv.org/abs/2603.22106
15. Spec-Driven Development with AI Agents: From Build to Runtime ..., https://medium.com/@dave-patten/spec-driven-development-with-ai-agents-from-build-to-runtime-diagnostics-415025fb1d62
16. The cognitive debt of offloading software development to AI | by Naveen Raju Mudhunuri | Medium, https://medium.com/@naveenfy/the-cognitive-debt-of-offloading-software-development-to-ai-c012963542d5
17. How to fight against analysis paralysis for high level design decisions - Taro, https://www.jointaro.com/question/B7npGM3BcAt7T7vszTvB/how-to-fight-against-analysis-paralysis-for-high-level-design-decisions/
18. Diving Into Spec-Driven Development With GitHub Spec Kit - Microsoft for Developers, https://developer.microsoft.com/blog/spec-driven-development-spec-kit
19. AI's Impact on Software Architecture | by Vipul Kumar - Medium, https://medium.com/@vipulkc/ais-impact-on-software-architecture-05cd40d01443
20. Spec-driven development with AI: Get started with a new open source toolkit - The GitHub Blog, https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

Transcript

SPEAKER_00 0:00

If you've been following Minecast for a while, this number might feel familiar. Developers expected AI to reduce their project completion time by 24%. We've cited it before on this show, and we're citing it again today, deliberately, because that number is still not being taken seriously enough. So here it is, one more time with fresh context. 24% faster. That was the promise. That was the number baked into the forecasts, the boardroom presentations, the breathless product launches. 24% faster. And yet, when researchers actually went and measured what happened with experienced developers on real projects using state-of-the-art models, they found the exact opposite. AI didn't cut completion time, it increased it by 19%. Let that land. The technology we were told would make us dramatically faster is empirically making experienced developers slower. That is not a hot take, that is the data. And that paradox is what we're going to spend the next 20 minutes pulling apart. Welcome to Mindcast. I'm Will. Regular listeners will know that we've been circling the question of what AI is actually doing to software teams, not the marketing version, but the lived empirical reality. We've touched on this territory before. Today we go further. New research came our way, proprietary, not publicly available, and it gave us enough to warrant coming back to this subject with more depth and more specificity than we've had before. And if you're new here, this is the show where we take the ideas actually reshaping how we work, how we build things, and how we think, and we examine them with honesty, with depth, and without the hype. Today's episode is one I've been genuinely excited to record, because it tackles something I think is almost entirely missing from the mainstream AI conversation. We are all living through this revolution right now. AI tools are everywhere, in the hands of developers, writers, analysts, managers. The promise is enormous, and some of it is real, but almost nobody is telling the full story about what's actually happening on the ground inside engineering teams when they go deep on agentic AI. The gap between the marketing and the empirical reality is striking, and the implications reach far beyond software. So today, we're pulling back the curtain. We're going to look at how AI genuinely solves one of software development's oldest, most stubborn problems, and then how it simultaneously creates brand new, more sophisticated ones. We're going to get into the cognitive science of why these new traps are so hard to see coming. We're going to unpack what researchers are calling the triple debt crisis, and we're going to land on a genuinely exciting solution, a methodology called spec-driven development that may be the most important idea in software engineering right now. Let's get into it. Alright, key insight number one. And I want to start here with something that is genuinely unambiguously good news, because this story has real upsides before we get into the complications. AI coding assistants have proven remarkably effective at solving one of the oldest, most frustrating problems in software engineering, the blank page, or more precisely, what practitioners call blank page syndrome. Picture this: a developer sits down to start a complex new project. They know roughly what needs to be built, they have the tools, they have the skills, and they just freeze. Because the problem is so large, so undefined, so full of branching implications that the brain goes into a kind of cognitive gridlock, every path forward looks like it might be the wrong one. This is analysis paralysis, and it has stalled more software projects than any technical failure ever has. For decades, the industry tried to fight it with methodologies, frameworks like the last responsible moment, the idea of making decisions only when you absolutely have to, not a second before. Good advice in principle, genuinely difficult to follow when you're staring into the void of an undefined system at 9 in the morning. Here's what AI changed. When you're facing that blank page, a generative AI tool gives you an immediate on-ramp. It acts as what researchers describe as a silent pair programmer. You describe the problem, and within seconds you have boilerplate code, a skeleton, a starting structure to react to. The psychological barrier doesn't just lower, it collapses. You've moved from frozen contemplation into active iteration. And for neurodivergent developers, particularly those managing ADHD, this is not a minor convenience. It's transformative. The research is striking here. For engineers where the activation energy to begin a complex, undefined task is the single greatest obstacle in their workflow, AI becomes an accountability coach. You can literally vocalize your block to the model, describe your indecision, the competing options, the overwhelm, and have it diagnose the root of your paralysis, break the challenge into microactions, and generate a rough working sketch to get you moving. Even if that first draft of code is structurally imperfect, it has already achieved its primary purpose. It has moved you from static to kinetic, from thinking about building to actually building. That shift matters enormously. So full credit where it's due, AI has genuinely solved this problem, and for a meaningful segment of the developer population, it has changed what's possible. But here is where this story gets complicated. Because while AI dismantles one form of procrastination and developer paralysis, it simultaneously gives birth to two entirely new, far more sophisticated ones. And this is where I think the mainstream AI narrative has almost completely dropped the ball. The first is what researchers are calling the optimization trap. And I want to ask you honestly, have you seen this? Have you done this? It looks like this. A developer needs to complete a critical feature, but instead of doing that, they spend three hours researching a new agentic framework that might make their prompts 5% more efficient, or they restructure their digital workspace, or they spend an afternoon fine-tuning an elaborate prompt template, building an automation system that ends up taking longer to construct than the actual feature it was supposed to help with. The core psychological driver here is well understood by behavioral researches. Our brains prefer tasks that feel productive, while letting us avoid the deep cognitive discomfort of genuinely hard, definitive work. AI doesn't eliminate this tendency, it supercharges it, because now the escape hatch is doing something that looks, sounds, and feels exactly like technical progress. It's task avoidance dressed in a productivity costume, and it's extremely hard to catch yourself doing it. The second new failure mode is the vibe coding dead loop. And this one is insidious because it feels incredible in the moment. Vib coding is when a developer starts a project with no strict architectural plan, purely in flow state, riding the momentum of continuous AI dialogue, building through feel rather than design. And in the early hours, it's exhilarating. The AI is generating hundreds of lines of code per minute. Progress is visible, constant, rapid. There's a genuine dopamine loop running. The brain is getting reward signals from every output. It creates the sensation of operating at superhuman speed. But here's what the research makes clear. When a bug hits, and it always eventually does, the entire thing unravels. Because the vibecoder doesn't have a mental map of what they've built. They don't truly understand the system. So they do the natural thing. They prompt the AI for a fix. It generates a variation, doesn't work. They prompt again, another variation, still broken. An hour passes. Then two, the developer is continuously busy, continuously prompting, continuously watching new code appear and getting absolutely nowhere. The research captures this perfectly. Time passes, but the human's understanding of the system does not improve. That is the vibe coding deadloop, endlessly active, completely stuck. And it is a fundamental breakdown in the engineering process disguised as productivity. This brings us to key insight too. And I want to flag this clearly. What we're about to get into is where conventional wisdom about AI productivity gets most seriously wrong. Let's talk about what actually happens to a human being when they adopt a fully agentic AI workflow at scale. The original promise was elegant. AI handles the mechanical, repetitive work, and the engineer is liberated for high-level strategic thinking, freed up, operating at altitude. Here's what the data actually shows. When you write code manually, your decision making is naturally paced by the act itself. The friction of typing syntax, finding the right method, structuring the logic provides inherent micropauses that function as built-in validation checkpoints. But when an AI agent is running, that natural rhythm disappears completely. You're suddenly forced to evaluate dozens, sometimes hundreds of lines of code every few seconds. And for every output, you're running a rapid mental checklist. Is this logic sound? Has the model hallucinated a library dependency that doesn't actually exist? Is there a subtle security flaw buried in this authentication flow? This is a continuous, relentless demand from micro decisions, and human cognitive capacity for that specific kind of load is finite in ways that are very easy to underestimate. The numbers from the empirical research are alarming. Workers managing agentic AI systems experience a 33% higher rate of decision fatigue compared to those working without AI oversight. As that fatigue accumulates and human judgment quality degrades under the load, organizations see an 11% increase in minor coding errors and a 39% surge in major architectural flaws. 39%? That is not noise in the data. That is a systemic failure pattern emerging inside what teams thought was a productivity revolution. And compounding all of this is something called the spectator effect. Here's the mechanism. When a developer is watching an AI agent generate code, the experience is passive enough that the brain thinks it's resting. You're not typing after all, your hands are still. But because you must remain intensely vigilant to catch errors, the brain simultaneously demands full cognitive engagement. You can't actually recover. You're trapped in a liminal loop, not actively working, not genuinely resting, just watching, evaluating, slowly depleting. The endpoint of this experience has a name that practitioners have coined, and I love it for how viscerally accurate it is: AI brain fry, a persistent mental fog, a physical buzzing sensation in the head, a complete inability to hold strategic focus. If you've spent a long day supervising AI-generated outputs and felt wrung out despite having typed almost nothing yourself, that's precisely what this describes. Now all of this feeds into what I think is the single most important conceptual framework in this entire episode: the triple debt model. Most people in the tech world are familiar with technical debt. That's when you write quick, messy code today that becomes a maintenance nightmare tomorrow. Bad structural choices accumulate in the code base and make the system increasingly brittle over time. It lives in the code. You can point to it. And here's a nuance worth noting. AI actually helps with this specific type of debt. Automated refactoring agents, AI-driven test suite generators, smart code review tools, these can systematically clean up a messy code base. So on technical debt, mark that as a genuine win for AI. But the triple debt model identifies two other forms of debt that AI doesn't just fail to address, it actively, aggressively accelerates them. And these are the ones that will actually destroy your software project from the inside. The first is cognitive debt. And this one doesn't live in the code at all, it lives in the minds of the people building and maintaining the system. Cognitive debt accumulates when the engineering team's shared understanding of how the system works erodes faster than it can be replenished. In an AI-augmented environment, code is generated significantly faster than any human can truly comprehend. Developers are accepting complex AI-generated architectures, approving walls of machine-generated logic without genuinely internalizing the mechanisms. What accumulates silently is a distributed fog of not knowing, spreading across the entire team. There's a concept here from the philosopher of programming Peter Nauer that the research draws on directly, and I think it's one of the most profound ideas in all of computer science. Naur argued that programming is fundamentally theory building. The software itself, the files, the compiled application, the running system, that's not the actual product. The real product is the shared theory of the system that lives inside the minds of the people who built it. The code is merely the outward representation of that collective internal understanding. And when you outsource the act of construction to an AI, you skip the struggle that builds the theory, you get the code without the comprehension. You bypass what learning theorists call desirable difficulties, the friction and grappling that are not merely obstacles to expertise, but the actual mechanism through which it is forged. The research calls this cognitive surrender. And here's what makes cognitive debt uniquely dangerous. It is completely invisible until a catastrophic tipping point. Unlike technical debt, which announces itself through failing builds and production outages, cognitive debt accumulates in total silence while artificially inflating the team's confidence. And then one day, the system has become a black box. Nobody trusts themselves to make even routine changes. Onboarding a new engineer becomes nearly impossible because the theory of the software has never been written down. When the failure comes, the root cause isn't a bug, it's that no human being actually owns the design. The third debt is intent debt, distinct from cognitive debt in a crucial way. Where cognitive debt is about not understanding how the system works, intent debt is about losing why it was built that way in the first place. Why was this database chosen over that one? Why does this authentication flow work like this? What were the business constraints three years ago that shaped this decision? In traditional development, the slow friction of manual coding enforced natural pauses, time for documentation, for design discussions, for rationale to be captured somewhere. AI eliminates that friction entirely. It accelerates production so aggressively that the reasoning behind critical decisions simply never gets written down. And it gets worse. Contemporary AI models are exceptional at processing under-specified prompts. You give an AI a vague one-sentence command and it fills in all the structural gaps with its own plausible assumptions. It generates something that looks right, that compiles cleanly, that passes basic tests. But those assumptions may completely miss actual human intent. They may violate security constraints that lived only in the product manager's head. And if you try to fix this retroactively by having AI generate documentation from the code base afterward, you've compounded the problem, because AI-generated retroactive documentation can only describe what the code does. It cannot tell you why it exists. Future engineers and future AI agents trying to extend the system are left completely in the dark. I want to zoom out now because the implications of what we've been discussing reach far beyond any single engineering team. Think about what it means at scale when entire mission-critical software systems become black boxes that no one understands. What happens to a hospital records platform or a financial risk engine or a logistics network when the team responsible for it has accumulated so much cognitive debt that they're afraid to touch it? When intent debt means nobody can safely extend it. This is not a hypothetical trajectory. This is the logical endpoint of unmanaged AI-augmented development, and the consequences are institutional, operational, and in some domains genuinely human. But I want to be fair here, because this technology also offers something genuinely extraordinary when it's applied within the right constraints. And that's what I'd call the empirical sandbox. Here's what I mean. Historically, when a software architect had to choose between two technical approaches, say writing a high-performance component in the programming language Rust versus Go, that decision triggered weeks of whiteboard debate, abstract arguments from intuition and past experience. The cost of actually building both options to test them in the real world was simply too high. So teams deliberated, disagreed, got stuck, and often stalled. AI changes this equation completely. You can now articulate your requirements, feed them to an agent, and have fully working implementations of both approaches generated in the time it used to take to schedule the meeting. You run them both in a live environment, you get actual latency data, real resource consumption metrics, genuine empirical evidence. The decision moves from the realm of abstract opinion to the realm of data. That is a genuinely profound shift in how engineering decisions can be made. And to prevent this empirical value from being immediately swallowed by intent debt, forward-thinking teams are using AI to auto-generate what are called architecture decision records, structured documents that permanently capture what was decided, why it was decided, what alternatives were considered, and the explicit reasoning behind the final choice? These records become the institutional memory of the system, the antidote to intend debt, and one of the most promising uses of AI in the engineering space precisely because they serve human understanding rather than replacing it. Now, let me broaden this beyond software, because the stakes here are universal. What happens to human expertise in any AI-augmented field when AI assumes the very tasks through which expertise is built? Think about a junior doctor who relies on AI diagnostics before developing clinical intuition. Think about an analyst who uses AI models without understanding the assumptions baked into them. The desirable difficulties, the struggle of mastering hard things, are not inefficiencies to be optimized away. They are the mechanism through which human judgment, human depth, and institutional knowledge are formed. The question of how we protect that depth in an AI-accelerated world is one of the defining challenges of this decade. And the answer is not to use less AI, the answer is to use it far more deliberately. Which leads us directly to the synthesis. So what does a disciplined, sustainable, human-preserving approach to AI-augmented development actually look like? The research converges on a methodology called spec-driven development, SDD, and I want to explain it in a way that makes intuitive sense whether or not you've ever written a line of code. Traditionally, a software specification was a human readable document describing what a system was supposed to do. Engineers would read it, roughly agree, and then largely improvise the implementation. Specs were suggestions, they got outdated fast, they were frequently ignored. SDD is a fundamental reimagining of that idea. In spec-driven development, the specification is not a document, it is a contract, a machine-enforced set of boundaries that actively constrains what an AI agent is permitted to generate. Think of it as giving the AI a constitution to operate within. The AI is powerful and fast, but it works within constitutional limits. It cannot invent outside the boundaries of the spec. It cannot fill underspecified gaps with its own assumptions. In an AI-augmented environment, ambiguity is not a minor inconvenience. Ambiguity is a hazard. When intent is unclear, an unconstrained AI agent will invent its own logic, fill the gaps with plausible sounding hallucinations, and silently accumulate both technical and intent debt at machine speed. Specs are no longer optional suggestions, they are the foundational operating boundaries of the system. In practice, SDD requires a comprehensive specification file, typically called spec.md, that must address six core elements before a single line of code is generated. First, outcomes, not vague feature titles, but precise, testable success states, not build user authentication, but a user can register with an email address, receive a verification link, and log in securely. Second, boundaries, explicit definitions of what is out of scope, preventing the AI from hallucinating extra features nobody asked for. Third, constraints and assumptions. The tech stack, performance baselines, API rate limits, all locked down. Fourth, pre-made decisions, the architectural choices human engineers have already finalized that the AI is explicitly forbidden to second guess. Fifth, task breakdown, the decomposition of the whole into sequential, discrete subtasks. And sixth, verification criteria, the objective rules automated systems will use to judge whether the AI's output actually meets the spec's intent. Six elements, all documented before generation begins. The spec externalizes and formalizes human intent. To keep quality honest and combat what the research calls the natural optimism bias of generative models, their tendency to assume everything is fine when it isn't, advanced SDD implementations deploy what's called an adversarial agent pattern. A coordinator agent reads the master spec and breaks it into delegated sub-specifications. Implementer agents generate the code, and then an independent verifier agent checks the work against the verification criteria, specifically optimized to find failures, not to approve. That adversarial pressure is what keeps the whole system honest and aligned with human intent. In human practice, developers using this approach run separate architect and implementer AI sessions. The architect session is tightly constrained. It can only ask one clarifying question at a time, and it outputs design proposals in bite-sized chunks of two to three hundred words, requiring explicit human approval before advancing. This forces active comprehension at every step. The developer can't rubber stamp a wall of generated text. They have to understand each piece before the process moves forward. The implementer session, meanwhile, is routinely wiped clean to prevent context bloat, the insidious buildup of accumulated AI conversation history that gradually degrades output quality. In this model, the human is no longer a coder, they're an engineering manager, the person who holds the theory, makes the strategic calls, and coordinates the machines. Now let me land this with three concrete takeaways, things you can carry from today's episode into your own work, whether you're a developer, a manager, or simply someone thinking carefully about AI in your professional life. Takeaway number one, be deeply suspicious of feeling productive. The optimization trap and the vibe-coding deadloop are dangerous precisely because they feel like work. The dopamine hits from rapid AI-generated output are neurologically real, but momentum without comprehension is not progress, it is velocity toward a cliff. Build in a regular, honest check-in with yourself. Do I actually understand what this system is doing? If the answer is no, that's a warning signal, not a prompt to generate harder. Takeaway number two, the invisible debts will kill you before the visible ones do. Technical debt fails loudly, cognitive debt and intent debt fail silently behind a facade of confidence until the damage is catastrophic. The antidote is proactive human-authored documentation of reasoning, not retroactive AI descriptions of what was built, but contemporaneous records of why decisions were made. Every significant architectural choice you make, write down the reasoning, not the what, the why. This is how you keep the theory alive and transferable. Takeaway number three, specify before you generate, always. Whether it's a full SDD specification file or simply a clear, explicit brief before any AI interaction in any professional context, the principle holds. An underspecified prompt is a blank check for the machine to fill your gaps with its own assumptions. The uniquely human value in an AI-augmented world is not the ability to generate quickly, it is the ability to specify precisely, to evaluate critically, and to hold the depth of understanding that keeps complex systems steerable and trustworthy, protect that capacity above everything else. Let me close with the image the research itself ends on, because I think it's the right one. AI is an extraordinarily powerful engine. It is fast, it is capable, and it is only going to become more so. But a powerful engine without a chassis is not a vehicle. It's a catastrophic release of uncontrolled energy. It doesn't build anything, it destroys things. Spec-driven development is the chassis. Human comprehension, human intent, and human rationale are the chassis, and the future of software engineering and the future of expertise in any AI-augmented field belongs not to the teams who generate the most code the fastest. It belongs to those who use AI to maintain the deepest, most resilient, most explicitly documented understanding of the systems they build. That understanding is not a byproduct of the work. It is the work. Don't surrender it. One important note before you go the research underpinning everything we discuss today comes from a proprietary analysis that is not publicly available, so you won't find a download link. But I've put together a curated reading list on cognitive debt, spec-driven development, the empirical productivity paradox, and architectural decision records in the show notes. Head there if you want to go deeper. And if today's episode shifted how you're thinking about AI and your work, please share it with someone who needs to hear it. Hit subscribe wherever you listen so you never miss an episode. I'm Will. This is Mind Kennedy. Stay sharp.