# Don't let AI borrow your brain > The danger of AI isn't that it makes engineers less productive. It's that it quietly removes the exercise that kept them sharp in the first place. By Matthew D. Webb · 2026-03-30 · 7 min read Canonical: https://mdwebb.io/articles/dont-let-ai-borrow-your-brain/ AI involvement: Used to draft and revise this article, images included. --- I use AI every day. It writes the boilerplate I can't be bothered to type, reviews ideas I haven't finished having, explains APIs I've never met, and every so often points me at a solution I'd have taken the long way round to find on my own. I wouldn't give it up, and I'm not going to pretend otherwise. I also wouldn't train for a marathon on an electric scooter. The scooter isn't the problem. It is wonderfully effective at covering ground, which is rather the point. The problem is that it removes the work the training was supposed to be doing, and the same trap runs straight through how engineers are starting to lean on AI. Most of them are busy worrying about being replaced by it. Far fewer are worrying about needing it. I think the second problem turns up a good while before the first, and it does so a lot more quietly. ## The gym problem Nobody ever got stronger watching a forklift shift weights around a warehouse. The value was never in the weights moving from A to B; it was in your muscles doing the moving. Software has always worked the same way, even if we don't usually say it out loud. The engineer who has built authentication three times understands it in a way the engineer who has only read about it never quite will. The one who has sat through a distributed-systems outage at three in the morning, watching a dashboard lie to them, develops instincts you cannot download from a summary. The struggle was never incidental to that. The struggle was the training. What AI changes is that, for the first time, an engineer can routinely skip large stretches of the struggle and still arrive at something that ships. That is simultaneously the most useful thing about it and the most quietly corrosive. ## We become what we practise Spend ten years solving production incidents and you become genuinely good at solving production incidents. Spend ten years designing systems and you get good at designing systems. Spend ten years prompting an assistant to solve problems on your behalf and the honest question is: good at what, exactly? People bristle at that question because it sounds anti-AI. It isn't. It's anti-outsourcing the wrong things, which is a very different complaint, and one worth taking seriously precisely because the tool is so good. ## The calculator lesson The usual rebuttal is the calculator. We all learned long division and mental arithmetic, and almost nobody does either by hand any more, and society has carried on perfectly well. True. But that worked out fine because rapid manual arithmetic stopped being the job. The calculator replaced a skill we no longer needed to keep. Engineering doesn't get to make that trade. The underlying skill is still the job. An engineer who can't reason about concurrency because the model writes the concurrency code is still the one holding the pager when it deadlocks in production. An engineer who can't evaluate a design because the model generated it is still the one explaining to the room why it fell over. The accountability never went anywhere. Only the effort did, and accountability without the understanding to back it is just exposure with a job title. ## The new failure mode The old way to be a weak engineer was simple enough: you lacked experience, and it showed, and everyone including you knew roughly where you stood. The new failure mode is stranger and harder to spot. Engineers can now accumulate years without accumulating the understanding those years used to guarantee. They will have shipped systems, written code, delivered features, and sat in the standups, and on paper they will look seasoned. But if a good chunk of the actual thinking was handed off along the way, the experience and the understanding have quietly come apart. The danger was never incompetence; incompetence announces itself. The danger is a confident, well-reviewed sense of competence with nothing much underneath it. ## What not to outsource There are a handful of things I deliberately keep my hands on. Architecture. Debugging. Performance work. Weighing trade-offs. Root-cause analysis. Not because the model is bad at them, because it often isn't, but because those are the activities that build judgement, and judgement is the one thing I'm not willing to deskill. This is the part chess taught me, if it taught me anything useful. You can be shown the best move in a position, and it does almost nothing for you. The strength comes from calculating the line yourself, being wrong, seeing why, and carrying that home. Hand judgement off entirely and you keep the answers while losing the only thing that lets you tell a good one from a confident one. So I take the first draft. I take the alternative angles, the challenges to my own thinking, the option I hadn't considered. What I won't take is the machine having done all the thinking before I've arrived. ## The running analogy I spend a fair amount of my life running, so let me put it where I actually feel it. If someone sold me shoes that quietly completed half of every training session for me, I'd be faster next week and slower next year, and I wouldn't even notice the swap happening until a race went badly. Training stress is what produces the adaptation. Remove enough of the stress and the adaptation simply stops arriving. Engineering is no different. The debugging session that refuses to make sense, the architecture call that eats two days, the incident that won't resolve into a tidy story - those aren't obstacles in the way of the learning. They are the learning. Skip them often enough and you've skipped the bit that was making you better. ## The engineers who will thrive The engineers who get the most out of AI won't be the ones who hand it everything. They'll be the ones who hand it the right things. Use it to remove repetition, not reasoning. To speed up implementation, not to replace understanding. To widen the set of options, not to make the choice for you. The strongest people I work with already treat it as a power tool rather than a stand-in for expertise, and the distinction matters. A chainsaw makes a carpenter dramatically more productive. It does not, on its own, teach anyone woodworking, and nobody sane confuses owning one with knowing the craft. ## Keeping sharp My rule for this is embarrassingly simple. If I can't explain why a solution works, I don't really own it, and it doesn't much matter whether it came off my own keyboard or out of a model. Ownership is the explanation, not the authorship. So keep a few areas where you still do the hard part yourself. Debugging, system design, performance, whatever it is that actually constitutes your edge. Those are the muscles worth protecting, because the real risk here was never that AI gets smarter than you. It's that you slowly stop exercising the parts of yourself that made you worth hiring, and feel more productive the entire way down. This is the same shape I keep running into elsewhere: AI accelerates the implementation and leaves the judgement exactly where it found it, which is also why [interviewing engineers in the age of AI](/articles/interviewing-engineers-in-the-age-of-ai/) has quietly become an exercise in measuring judgement rather than recall, and why AI adoption on the ground turns out to be far less about the model than about who's still doing the thinking. ## Further reading - [Nicholas Carr, "Is Google Making Us Stupid?"](https://www.theatlantic.com/magazine/archive/2008/07/is-google-making-us-stupid/306868/): from a tool a couple of revolutions ago, but the underlying worry (that a convenience can reshape the cognition it was meant to serve) reads as more relevant now, not less. - [The "automation paradox" and complacency in cockpit automation](https://en.wikipedia.org/wiki/Automation_complacency): aviation worked this out the hard way decades ago. Hand the routine flying to the autopilot and the crew's manual skills quietly erode, right up until the moment the system hands control back and expects them to be sharp. Software is rediscovering the same lesson with prettier tooling. - [Anders Ericsson on deliberate practice](https://en.wikipedia.org/wiki/Practice_(learning_method)#Deliberate_practice): the research behind the idea that effortful, uncomfortable practice is what actually builds expertise. Worth reading precisely because AI is so good at removing the effortful, uncomfortable part.