You Can’t Prompt Your Way to Intuition

• April 18, 2025

We don’t talk enough about the feeling of learning something deeply - the slow, sometimes frustrating and painful process that forges real intuition.

As software engineers, we know this feeling intimately. The slow burn of mastering a new concept or language. The pressure and anxiety of resolving your first production issue. The endless hours spent debugging a complex system that just won’t work - until, at last, it does. And how that struggle itself is the point: it’s what transforms a beginner coder into a software engineer with real intuition.

And yet, in the age of AI, that friction is exactly what we’re designing away.

GitHub Copilot, ChatGPT, Cursor, Windsurf - they’re extraordinary tools. They’ve changed the way we work. They accelerate us. They enable us to solve problems we previously would’ve struggled with. They’re becoming the new normal.

But they also flatten the terrain. And when the terrain is too smooth, we stop noticing what we’re stepping over.

The Need for Speed

As a society, we’ve become obsessed with speed. In a world of endless notifications, instant messages, and constant demands for more, we’ve normalised a state of perpetual acceleration.

This obsession with speed is especially prevalent in software delivery. In the tech industry, the race to ship new features is relentless. If you’re not moving fast, you risk falling behind. Companies compete to launch first, to capture attention, to prove they can outpace the rest. That urgency flows straight to the engineer’s desk. We work at a breakneck pace, juggling Slack alerts about pull requests, dashboards updating in real time, CI/CD pipelines demanding ever-faster iterations. We’re always looking for ways to do more, faster - to shortcut the things that can be shortcut, to automate the parts that can be automated.

This relentless drive for speed and efficiency has shaped every aspect of how we build software. For decades, we’ve chased new ways to get more done: frameworks, libraries, automation scripts, cloud deployments, microservice architectures, new methodologies - each one promising to help us move faster. Now, AI is the latest - and most powerful - shortcut yet. Everywhere you look, people are posting about how much faster they can build software with AI: how many lines of code they’ve refactored in a fraction of the time, how much boilerplate they’re avoiding with a single prompt, how quickly they’re spinning up entire new businesses in a weekend. And yes, that velocity is valuable. Those productivity gains are real - and it’s changing the landscape.

The Myth of the Shortcut

One of the changes we’re seeing is that a new generation of engineers is moving at a pace that would have been unimaginable just a few years ago. Steve Yegge’s Revenge of the Junior Developer captures this shift: junior developers, empowered by AI, are moving faster than ever - sometimes outpacing their more experienced peers. He explains how junior engineers are ‘vibing’. They get it. Essentially, AI coding assistants can act as powerful exoskeletons for anyone willing to adapt, enabling them to do work that previously required much more experience.

Shortcuts have their place. They open doors and accelerate growth. But speed doesn’t build engineering intuition.

There’s something disorienting about how good these tools are at helping you sound like an expert. They give you the answers - but they don’t teach you how to notice the problem in the first place. And they certainly don’t teach you how to trust your instincts.

That’s the real danger of shortcuts: they make you feel powerful and productive, but can lull you into a false sense of security. Without the intuition and habits forged by experience - knowing when to be wary, when to back up, when to double-check - you’re at risk of costly mistakes. These lessons aren’t learned by skipping to the answer; they’re earned by wrestling with real problems.

Cautionary tales like the one below are popping up everywhere - not necessarily because people lack technical skill, but because they haven’t yet built the judgement to anticipate, prevent, or recover from disaster.

It’s not gatekeeping to say that some things still take time. It’s just how humans learn.

Santiago Valdarrama’s blog post “Coding is over. Now what?” points out that as AI commoditises coding, the most valuable skills become things like identifying the right problem, framing it well, and designing elegant, maintainable solutions. But what’s often glossed over is the uncomfortable reality that these aren’t skills you can simply acquire overnight or skip straight to. No one seems to be talking about how the next generation of engineers is supposed to leapfrog past the years of debugging sessions, architectural missteps, and system rewrites that forge true intuition. How do you even know what an elegant, maintainable solution looks like if you’ve never had to live with the consequences of a brittle one? These abilities are forged in the messy middle, through friction and deliberate practice - not by shortcutting your way to the answer.

What ties all these higher-order skills together is a kind of engineering intuition - a sense for what matters, what will work, and what might go wrong in different contexts. But intuition isn’t something you can prompt for or download; it’s earned by moving through the gradual stages of real skill acquisition.

The Dreyfus Model: Why Intuition Can’t Be Prompted

The Dreyfus Model is one of the best tools I’ve found to help make sense of this journey, both for myself and for others I’ve coached. If you’ve never heard of it or how it can be applied to sofware engineering careers, this article provides a good overview.

The model describes five stages, each reflecting a shift in how we use recollection, recognition, decision-making, and awareness.

1. Novice – You follow rules and instructions exactly as given; your recollection and recognition are limited to what you’ve been explicitly taught; you make decisions by following step-by-step guidance; your awareness is focused tightly on the immediate task - bigger-picture context isn’t relevant (and wouldn’t help much even if someone tried to give it to you).
2. Advanced Beginner – You start to recognise recurring patterns and situations; your recollection of similar experiences begins to inform your actions; you still depend on rules but with some flexibility; your awareness starts to expand, but you’re still mostly focused on the task at hand, with only glimpses of the broader context.
3. Competent – You can plan, troubleshoot, and prioritise; your recognition of patterns is stronger; you draw on a growing bank of experiences; your decision-making involves conscious choice and analysis; your awareness now includes both immediate tasks and the bigger picture. At this stage, you begin to adapt rules to fit the situation and can finally make use of wider context.
4. Proficient – You see the big picture and adapt flexibly; your recollection is automatic for most situations; your recognition is rapid and intuitive; your decisions are guided by experience but still involve reflection; your awareness includes anticipating outcomes and adjusting in real time. You often know when to break the rules and why.
5. Expert – You operate from deep intuition; your recognition and recollection are seamless and often unconscious; you make decisions fluidly, often without deliberate analysis; your awareness is holistic, allowing for creative and adaptive responses. At this level, you’re often the one creating new rules, patterns, or heuristics for others to follow.

The crucial thing is that you can’t simply skip these stages - no matter how powerful the AI or how quickly you pick up new syntax. Intuition is built by moving through each phase, not by bypassing the messy middle. There’s a reason it’s often said that reaching true expertise in any field takes years, not weeks - sometimes a decade or more.

That’s what I love about the Dreyfus Model: it normalises friction. The path to expertise is supposed to be bumpy. That’s not a flaw - it’s a feature, backed by decades of research on skill acquisition and deliberate practice.

Ericsson et al. (1993) established that expertise isn’t simply a function of experience, but of deliberate practice - focused, effortful work aimed at improving specific aspects of performance. Further studies, including Becker et al. (2023), have explored how these principles apply to programming specifically, showing that enduring mastery requires more than repetition - it requires reflection and productive struggle. This aligns with recent educational research by Bull and Kharrufa (2024), who argue that effective learning with AI must integrate human reflection and effort - not bypass it.

This finding is reinforced by an MIT study, as described in Esther Shein’s paper The Impact of AI on Computer Science Education. In the study, students were split into three groups and given a Fortran task - a language none of them knew. One group used ChatGPT, another used Meta’s Code Llama, and a third used only Google. While the ChatGPT group solved the task the fastest, they failed to retain what they had learned and performed poorly in follow-up assessments. The Code Llama group performed slightly better, but the Google group - who had to break the problem down into smaller parts - retained the most and performed best. As the study put it: “Working hard and struggling is actually an important way of learning.” The results underscore this central claim: that real understanding comes not from being handed solutions, but from working through the friction to reach them.

This matters now more than ever, because AI tools give us fluent syntax and confident answers - but they don’t give us the pattern recognition or judgement that only comes from working through the mess.

Embrace the Seams

Some researchers are starting to recognise this risk and are exploring ways to design AI tools that don’t just hand you answers, but invite you into the process. Inman et al. (2025) at Google call this idea Seamful AI: instead of hiding uncertainty and ambiguity, these tools could surface the “seams” - the places where the answer isn’t clear-cut, or where multiple paths might be valid.

Why does this matter? Because it’s in those moments of ambiguity and uncertainty - when you have to pause, weigh options, and make a judgment call - that real learning happens. Exposing the seams doesn’t just make AI more transparent; it creates space for you to bring your own intuition and critical thinking to the table.

Most AI coding assistants, by contrast, erase those moments. They converge on a single, confident-sounding answer, making it harder to develop real judgment - or even to know that judgment is needed.

We can’t afford that. Not if we care about software quality. Not if we care about the next generation of engineers.

Rediscovering Friction

This doesn’t mean going back to writing everything from scratch. It means being intentional about when we slow down.

In a world where AI can generate endless code and abstractions pile up faster than ever, friction isn’t about slogging through every detail. It’s about choosing your moments. Sustainable, realistic friction is about:

• Getting curious when something surprises you - whether it’s a bug, an unexpected result, or a design you don’t quite trust.
• Taking time to understand the systems or components that matter most for your product, your users, or your own growth.
• Reflecting on failures and odd behaviours in production, and letting those drive deeper investigation.
• Setting aside space for “digging in” on the areas that spark your curiosity, rather than feeling obligated to master everything.
• Sharing what you learn with others - because teaching is one of the best ways to deepen your own understanding.

We won’t always have the time or energy to read every line, and that’s okay. But if we never slow down, never question, never get our hands dirty, we risk losing the intuition that makes us truly effective engineers. Friction, when chosen wisely, is what keeps our skills sharp and our judgement real.

I’ve experienced this firsthand. I still remember becoming obsessed with tracking down a memory leak in production many years ago. The easy fix was already in place - just restart the IIS worker processes every night - but that was a band-aid, not a solution. So I dug in, learning to use WinDbg (a seriously tricky tool to master), poring over cryptic commands and outputs, and chasing down the root cause. It took more time and frustration than I care to admit, but by the end, I didn’t just fix the bug - I’d become an expert on XML Serialisation (the culprit). That experience didn’t just give me an answer; it gave me a kind of intuition that’s hard to get any other way.

And yes, maybe today you could ask an AI assistant to help diagnose a memory leak like this. Intuition, though, isn’t just about getting the answer, it’s about knowing which questions to ask, recognising when something doesn’t add up, and having the confidence to dig deeper when a quick fix isn’t enough. AI can accelerate learning, and it may help us reach these moments of insight faster than before, but the path taken still matters. The fundamentals - curiosity, persistence, and the willingness to wrestle with problems - are what turn information into real knowledge and meaningful understanding.

The Missing Piece of the Conversation

The Dreyfus Model shows us that growth - in any domain, but especially as software engineers - is a journey: slow, sometimes frustrating, often messy. In the age of AI, the path may look different, but the fundamentals haven’t changed. Intuition still comes from the same place it always has: deliberate practice, reflection, and time spent wrestling with uncertainty.

And yet, there’s something quietly unsettling about the way we’re talking about AI right now.

We’re told the real value in our work lies in higher-level thinking - identifying the right problems, shaping elegant solutions, seeing the system. And that’s true. But what’s missing from the conversation is how we can develop those skills when AI is erasing the friction that used to help us build them.

If you’re leading a team, this matters even more. It’s not just about shipping faster or clearing blockers. It’s about creating the kind of environment where engineers can still build the instincts and judgment they’ll need later - even if the path to get there looks a little different now.

So use the tools. Embrace the speed. And every so often, slow down - just enough to feel the texture of the work again.

That hard-earned feeling of learning something deeply? It’s still there. And it still matters.