# How to Keep Your Developer Instincts When AI Writes the Code > Source: > Published: 2026-05-20 00:00:00+00:00 # How to Keep Your Developer Instincts When AI Writes the Code *Shipping fast with AI but don't fully trust the code? I help developers 1:1 turn AI-built apps into something they understand and own. How it works →* The promise was less friction. The cost, it turns out, is instinct, a high price to pay. The answer: add deliberate practice to your routine, and keep the struggle. In Lars Faye's [Agentic Coding is a Trap](https://larsfaye.com/articles/agentic-coding-is-a-trap) I read: You won't get the next wave of seniors if we're all abdicating the friction of writing, problem-solving, and debugging. And this is what Addy Osmani says, in [a LinkedIn post on AI productivity vs. growth](https://www.linkedin.com/feed/update/urn:li:activity:7458225258727112704/): Surface correctness is not systemic correctness. To resist surrender, we have to build friction and calibration into our workflows. That word, *friction*, is the one I keep coming back to. It's the part most AI tooling (vendors) tries to remove with bizarre promises like: Ship with 0 friction. No, that's a lie. Friction is inherent to shipping increasingly complex software. And it's also what keeps us engineers sharp, and what starting engineers need to get to a certain level, developing the intuition, experience and judgment to make an effective (and responsible) use of the new tools. ## Three kinds of friction Let's split friction into three types: **Friction worth deleting.** Boilerplate, config syntax, format conversions, dependency lookups, the Nth CRUD app. Agents are good at this, and grinding through well-known patterns does not make you sharper. Mostly safe to hand off, as long as you review the output and have good test coverage. This is only a tiny fraction of real software to build though. **Friction worth keeping.** Sitting with a design decision until you can defend it in one sentence. Debugging the race condition in the cloud ([nice example by Adam Johnson](https://adamj.eu/tech/2026/04/20/django-python-3.14-incremental-gc/)). Reading the AI's diff and pushing back on why this approach over the other two. This is where instinct gets built. If you outsource this part, you will lose the muscle. **Friction worth seeking out.** Going one level below your daily stack or abstraction. Writing by hand the thing you would normally prompt. Reading the source of a library you depend on, end-to-end. These are all forms of *deliberate practice* (related book I want to read with new eyes again: [Peak](https://www.amazon.com/Peak-Secrets-New-Science-Expertise/dp/0544456238)). Coding with agents makes it cheap (and tentative) to skip the hard parts. Because the code arrives instantly and the dopamine loop pushes us toward building faster, we default entirely to *System 1* thinking: fast, instinctive, and effortless. The agent becomes an externalized version of this automatic brain, churning out solutions before we've even processed the problem. But as [Daniel Kahneman argued](https://en.wikipedia.org/wiki/Thinking,_Fast_and_Slow), that's not how real thinking works! We need space, time, and the deliberate slowing down of *System 2* to build the intuition and judgment that will allow us to use these tools effectively in the long run. ## A deliberate practice routine for AI-era developers A few things I do on purpose, inspired by Osmani's post. - **Form the expectation before prompting.** Decide what the answer should roughly look like. If the output does not match, you have a real choice to make, not a default to accept. Osmani calls the alternative the*borrowed-confidence effect*: what you borrow, you pay back later, often in lost instinct.TDD is the same discipline applied earlier: write the test first and let it define what "correct" means before any code is written. [Ryan Austin does this deliberately](/blog/ai-coding-tools-fundamentals-case-study/)— nearly all his prompts begin with "Using a TDD approach..." and end with a request to review the tests before any code is written. - **Read the diff like a junior wrote it.**"Seems right" is not a review. Every AI diff gets a deliberate pass: boundaries first, tests second, the easy interior last. - **Ask the model to argue against itself.** Once it proposes an approach, ask for the strongest case against it. The output stops being a recommendation and starts being a tradeoff. I also use different models to review each other's work. Then I write the decision in plain English in the PR. If I cannot write it confidently, I do not own the design yet.You can push this even earlier, before writing any code, with [Matt Pocock's grill-me skill](https://github.com/mattpocock/skills/blob/main/skills/productivity/grill-me/SKILL.md):*"Interview me relentlessly about every aspect of this plan until we reach a shared understanding."*Related article:[Vibe Coding is Easy, Owning the Architecture Isn't](/blog/vibe-coding-owning-architecture/). - **One thing a week solo at the keyboard.** A two-hour block, no agents. I can search for snippets, but I have to make them work manually. Usually project-based, but[Bite exercises](https://rustplatform.com)are good too for this. Block the time if you have to. Learn something outside your regular stack.Picking up Rust was not only good for deliberate practice, [it also challenged my Python habits](/blog/rust-made-me-a-better-python-developer/). Another one on the list:[Functional Programming in Scala](https://www.amazon.com/Functional-Programming-Second-Michael-Pilquist/dp/1617299588). None of these are about using less AI. I still use agents in some shape or form every day. The goal is amplification, where the agent is the second engineer (or sparring partner) in the room, but not the one that replaces your thinking. ## The junior version is the same routine, earlier The harder case Faye raises is onboarding. Developers who started in 2025 never had the pre-agentic scarcity that built our instincts. They are not lazy. They never had the friction to push against in the first place. Matt Perry [expressed this well on LinkedIn](https://www.linkedin.com/feed/update/urn:li:activity:7462404192310185984/) as well, and it concerns me too: How does a junior engineer in 2026 build the depth of judgement previous generations developed through years of repetition, mistakes and exposure, when the apprentice-level work is increasingly being absorbed by AI? In my coaching, the answer is the same routine, applied earlier and more strictly. Slower pace. Fewer prompts. Write the test before the code. Read and understand AI line by line. Question it. The agent is allowed in, but not to build the whole solution; that will backfire for quality and learning. I had a wonderful chat this week with somebody who finished [our Rust cohort](https://scriptertorust.com). The deliberate learning and 'explain only' AI mode meant he actually learned it well in just six weeks. Shipping apps matters. Building the instincts to keep doing it reliably matters more. ## Keep the struggle The insidious thing is that agent autopilot feels productive. You are shipping code and building more things. The problem is you are not building the muscle to keep doing it when the autopilot fails, which it will. I included these two quotes in [my last newsletter](https://buttondown.com/belderbos/archive/keeping-up-might-be-the-worst-strategy/). The first is from Clean Code, the second from another developer that is currently going through mentioned Rust cohort: Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail. You must see them stumble and retrace their steps. You must see them agonize over decisions and see the price they pay for making those decisions the wrong way. (Clean Code, 2nd ed.) Going through the Rust cohort feels a lot like learning to program again but this time on a new, higher level. I challenge my old (easy, verbose) ways and instead look a lot more for the idiomatic, Rustacean way. When I work with my code, I find myself advancing extremely slowly because I discover so much more along the way. Yes, I am learning programming (again). Don't be tempted to speed up. Keep the struggle, and that requires slowness. It's how we became good engineers in the first place, and it's how you stay relevant when the tools change faster than the skills. The agent age has not made the craft obsolete. It has widened the gap between developers who just want to produce code and developers who want to keep the craft underneath it. I use agents every day, although not without mixed feelings. The balance only holds if we **deliberately add friction back**, both for ourselves and for the next generation of engineers. Shipping fast with AI is the easy part. Knowing what to keep, rewrite, and trust is the hard part. I work with developers 1:1 to audit AI-built codebases, trace the real control flow, and make them something you can explain and own, without leaning on a chatbot. [How 1:1 coaching works →](/coaching/#own-project)