By Zaahid Allie, Data Analytics Consultant at Insight Consulting.
Part 3 of 3: Knowing the tool, and how to put it into practice.
Across the first two posts in this series, I named the problem (cognitive dystrophy, not just atrophy) and gave you a framework for it (the car: hand over the 80%, keep the 20% on purpose). This final post is about the tool itself, what it hides from you, and what to actually do about all of it.
Knowing the tool
AI is exceptionally good at following instructions and much weaker at judgement about what the instructions should be. It is far more reliable at execution than at judgement, and it does not know the difference.
Two failure modes follow from that. The first is familiar: it is confidently wrong. Not hesitantly, not obviously. Fluent, well-structured, correctly formatted, and wrong, with no tone of uncertainty to warn you and no ability to tell you when it is out of its depth.
The second is underrated: it is confidently overcomplicated. Often the failure is not an error at all; it is elaboration. Extra abstraction, handling for cases you do not have, two hundred lines for a twenty-line problem, a measure with nested variables where a plain sum would do.
That second failure closes the loop with everything in this series. You cannot tell that something is overcomplicated unless you could have produced the simple version yourself. Elaborate solutions read as sophisticated to someone who has lost the ability to write the plain one. This is dystrophy with a concrete, billable consequence.
What this looks like in practice
I should be specific about myself here, because it is the only evidence in this series I can vouch for personally.
My goal is to have AI do as much as possible. What that actually costs is hours iterating on processes, not on tasks. My work building tools to connect AI to our Qlik environment is the clearest example: testing what was possible, finding out a QVF file could be read at all, then building the route from that discovery to something reliable. I have moved from troubleshooting the code myself to working out how to give AI the directions to troubleshoot the code.
That is an equivalent exchange, and both sides of it are real. My hands-on Qlik scripting has declined compared to two years ago. In its place is a better understanding of how to integrate AI into a workflow. I did not lose the cognitive bandwidth. I shifted it into an area AI struggles with and people excel at: judgement and decision making.
The fair question is: how would I know if I had gone too far? The test I would give anyone is this. It is not whether I could still produce it. It is whether I could still judge it. I am slower at hand-writing a script than I was, but I can still tell when what comes back is wrong, bloated, or solving a problem I do not have. The day I cannot tell the difference between a good script and an impressively long one is the day it has gone too far.
You don’t know what you don’t know
You ask AI to build you an application. You give it the aesthetics, the functionality, the features you want. You get a working app. You iterate, because seeing it working gives you new ideas. A couple of hours later you have a genuinely good working application that would have taken weeks before.
That sounds great, and it is; that is the entire premise of vibe coding, giving people without a software background the ability to create digital products. It is also the biggest point of contention for people on both sides of that debate.
Vibe coding is not production code. Vibe coding is making an idea tangible. It is prototyping at speed and iteration at speed, and it is superb at that.
What it is not is a route for someone with no experience or prior research to move that code straight into production. The AI built to spec. It made it look and work better than you expected. And there are things it did not implement, because you did not ask: security, authorisation and access control, hosting, whether the stack is scalable and maintainable, whether it has been stress tested for edge cases, whether the stack makes sense for the use case at all. None of these came up, because you were describing features rather than threats, because it worked when you used it, and because “works” felt like the finish line.
The AI did its job. Its task was to build you an app, and it built you an app. The gap is not a defect in the tool, and it is not carelessness by the user. It is structural: you cannot ask for what you do not know exists.
AI does not fill the gaps in what you know. It hides them, by producing something that works.
This is not only a developer problem; it is the same shape in every role. A business intelligence model loads and produces numbers, and nobody asked what happens when a dimension goes missing, a date is null, or volume grows tenfold. An AI-drafted client email is professional and well-structured and commits to a date nobody had cleared. An AI-drafted report is coherent and well-argued, and its framing quietly excluded the option that mattered. The output is good; the risk lives entirely in what was not asked for, and the better the output looks, the less likely anyone is to go looking.
Where agentic AI raises the stakes
The shift now underway is from AI that helps you do the work to AI that does the work and hands it to you. You supply a goal rather than a question, your thinking sits outside the work rather than inside it, you see only the decisions it chose to show you, and what you have to catch is no longer a wrong answer but a wrong plan carried out competently.
Handing work over raises the amount of checking required, because more decisions get made without you and small errors compound before you see anything. It simultaneously lowers your ability to check, because you no longer do the work that built the judgement checking depends on. The two lines cross. Reviewing is a different skill from doing: you can get good at reviewing while getting worse at the work, and the review will feel perfectly competent right up until it needs to catch the thing only the underlying skill would have caught.
Nobody here is the safe case
The instinct is that the heaviest AI users are most at risk. That is only half right.
Heavy users face atrophy: fast and competent, with the skills underneath quietly eroding while confidence rises. Light or new users face automation bias: they have the least sense of how these tools fail, so they are least equipped to catch a confident wrong answer and most likely to read fluent output as authoritative. Newer staff face dystrophy: handed the fast version before they ever built the slow one, so there is nothing underneath to catch anything.
Which suggests the cheapest useful thing any team can do about this. How these tools fail is teachable, and most teams do not teach it. Heavy users should show light users real examples of AI being confidently wrong and confidently overcomplicated. Not to scare anyone off it; you cannot develop a nose for a bad answer if you have only ever been shown good ones.
How to put it into practice:
- Draw your 80/20 deliberately, and write it down. Decide what you are keeping and why, before the decision gets made for you by convenience.
- Answer first, then ask. Spend sixty seconds on your own rough answer, outline, or estimate before you prompt. Without a prior view, you have nothing to be surprised by.
- Ask what you did not ask for. “What would a specialist in this area say I have missed? What did you not do because I did not ask?” AI is far better at answering that than people expect, and almost nobody asks it.
- Apply the ownership test. If your name is on it, you must be able to explain every meaningful decision in your own words, and name the thing that would make it wrong. If you cannot do both, it is not yours, and it does not go out.
- Schedule the exercise, because it does not happen by default. Could you defend this live, with nothing open in front of you and someone pushing back?
- Draw the prototype-to-production line explicitly. Anything AI-built is a prototype until someone competent has reviewed security, access, hosting, stack fit, maintainability, and failure modes. Not because the AI did it badly. Because nobody asked.
One last thing
This series was researched and drafted with AI, in exactly the pattern it describes. AI did the research and the drafting. I decided the framing, the argument, and what belonged in it. A couple of the ideas came from AI suggesting something relevant to the topic, and neither would have survived without someone qualified to decide they were right. It is a cohesive relationship, not a handover: both sides contribute the thing the other is bad at.
The car is not the problem. It never was. The problem is thinking that because the car is driving, you are not.
This is Part 3 of a three-part series on cognitive dystrophy and agentic AI. Part 1 covered the four mechanisms behind skill loss; Part 2 covered the car framework and how to draw your own 80/20 line.
This article first appeared in Insight Edge, our newsletter on LinkedIn.