There's a moment in every developer's journey with AI-assisted coding where something clicks. Not the first time you generate a function or autocomplete a tricky syntax pattern—that's just convenience. The real shift happens when you stop treating the tool like a search engine and start treating it like a colleague who's actually read your codebase.
Most developers never make that transition. They stay in the shallow end, firing off precise queries and getting useful-but-generic answers that could have come from any Stack Overflow thread. Meanwhile, a smaller group has figured out something different: the ceiling isn't set by the tool. It's set by the questions you're willing to ask and the complexity you're willing to bring into the conversation.
The default mental model for AI tools is what you might call the vending machine approach. Put in a precise query, get a useful answer out. And for small, contained problems—how do I format this date string, what's the syntax for this API call—it works perfectly well.
But this model breaks down exactly where AI assistance could be most valuable: in the messy, ambiguous, context-heavy problems that actually define senior engineering work. The gnarly refactor of a sprawling codebase that grew organically over years. The architectural decision where nobody quite remembers why certain choices were made. The moment when you need to understand the blast radius of changing an abstraction, not just how to change it.
Extended thinking capabilities exist precisely for these moments. But to use them well, you have to abandon the vending machine model entirely. Instead of crafting the perfect narrow query, you're briefing a colleague. Here's the codebase. Here's what we're trying to accomplish. Here's what's keeping me up at night about it. The question shifts from "how do I do X" to "help me think through X."
This feels uncomfortable at first. There's an instinct to keep questions narrow, a worry about confusing the AI or wasting the context window. But that caution is exactly what keeps you from accessing the tool's real capabilities. Once you start front-loading the messy reality of your project—the weird constraints, the historical baggage, the competing priorities—the responses stop sounding like documentation excerpts and start sounding like someone who actually understands your situation.
When developers successfully make this shift, something unexpected happens to their daily work. The obvious assumption is that offloading mechanical overhead—tracking which module does what, holding the system map in your head just to navigate it—translates directly into more code per hour. Sometimes it does. But the more interesting change is where that freed-up cognitive space actually goes.
Developers who lean into extended context well find themselves spending more time on the why. They question assumptions more readily. They catch design issues earlier. They think about user experience in places they would have just shipped and dealt with consequences later. The focus moves upstream, and even relatively mundane tasks start feeling more architectural.
There's also a shift in how developers relate to uncertainty. Before, an ambiguous requirement or a fuzzy technical boundary would often get papered over—pick something, ship it, hope for the best. But when you have a thinking partner that can help you sit with ambiguity and map it out, slowing down stops feeling so expensive. You get comfortable surfacing those questions early.
This matters more than it might seem, because that's honestly where a lot of technical debt comes from: decisions made in a hurry because the cost of slowing down felt prohibitive. Having a collaborator who can help you think through implications in real-time changes that calculus entirely.
Individual workflow changes are valuable, but the effects compound dramatically at the team level in ways that aren't obvious at first.
The most immediate change is a leveling effect. A developer who's been on the codebase for two months can suddenly participate meaningfully in conversations that used to require years of institutional knowledge. That changes who gets a seat at the table in architectural discussions, and it changes faster than traditional mentorship could.
But the more durable shift is what happens to knowledge itself. In most teams, the most important understanding lives in someone's head—the senior dev who knows why the authentication flow is structured the way it is, the one person who remembers the production incident behind that weird workaround. That knowledge is fragile. It walks out the door when people leave.
When teams start using extended context well, there's natural pressure to make implicit knowledge explicit. You need to put the why in the context window, which means you need to actually write it down. It almost accidentally creates better documentation culture.
There's a risk here too, though. Teams where a few people really understand how to collaborate with AI effectively can pull ahead, and that gap widens faster than anyone expects. The skill transfers less automatically than you might hope. Teams that don't intentionally share practices around AI collaboration just trade one knowledge silo for another.
The instinct when trying to spread a new skill is to formalize it—write a training doc, schedule a lunch-and-learn, create a best practices wiki page. These have their place, but they miss what actually makes AI collaboration skills transfer.
The highest-value move is getting people to work alongside someone who's already doing this well. Not watching a demo, but sitting in on a real working session where someone is briefing context, pushing into ambiguity, having the back-and-forth. The communication intuition—knowing when to provide more context, when to ask a broader question, when to challenge an assumption—doesn't come from a slide deck. It comes from seeing it in action.
The second piece is normalizing sharing the process, not just the output. Developers naturally share clever prompts and useful code snippets. But what's actually contagious is when someone explains how they were thinking about framing a problem and why they set up the context the way they did. Prompts are situational. The underlying approach transfers.
And perhaps most underrated: lower the stakes for experimentation. Many developers hold back because they're not sure they're using the tool correctly, and that hesitation kills skill-building. Teams that create low-pressure space to explore—a side project, an exploration sprint, even just explicit permission to experiment during normal work—see people find their groove much faster than teams where developers feel they need to have it figured out before they start.
The developers who get the most from AI assistance aren't necessarily the most technically brilliant. They're the ones who stay curious and stay honest about what they don't know. That's a very human skill, and it turns out it translates beautifully to working with AI.
The barrier isn't having the fanciest setup or knowing some secret prompting technique. It's about showing up to the collaboration genuinely—bringing the full messy context of your actual problem instead of a sanitized version you think the tool wants to see. The more honest and complete a picture you give, the more useful the thinking you get back.
That's actually hopeful, because it means any developer on any team can start practicing today. Not by learning new syntax or memorizing prompt patterns, but by asking better questions and being willing to engage with complexity instead of routing around it.
If you want to hear these ideas explored in conversation, check out the "Claude Code Conversations with Claudine" radio show. Available on all major podcast sites.
Enjoy this article?
Listen to the Claude Code Conversations radio show or join the community.
