Office Hours — What's the best workflow for developers who want to stay sharp and maintain their coding skills when LLMs can generate better code faster?
A daily developer question about AI/LLMs, answered with a direct, opinionated take.
What’s the best workflow for developers who want to stay sharp and maintain their coding skills when LLMs can generate better code faster?
This is the right question, and the honest answer is: the workflow has to change, not because you should avoid LLMs, but because what “staying sharp” means has fundamentally shifted.
The Real Problem Isn’t That LLMs Write Better Code
They do, on average, in narrow domains. But “better” is context-dependent. Claude Opus 5 or GPT-6 Astra will write more polished boilerplate than you in 10 seconds. They’ll also confidently generate plausible-looking code that passes a quick read but fails under load, breaks on edge cases, or introduces subtle security holes. The gap between “looks right” and “is actually right” is where your skills matter most.
The developers losing their edge aren’t the ones using LLMs. They’re the ones using LLMs as a replacement for thinking.
Deliberate Practice Still Requires Hard Problems
The cognitive science is clear: skill retention requires struggle. If you’re only writing code that LLMs generate for you, you’re not struggling. You’re validating. That’s not the same thing.
The workflow that works is to use LLMs for the parts you’ve already mastered and save the hard parts for yourself. This sounds counterintuitive, but it’s the inverse of how most people use AI tools.
Example: You’re building a new feature that requires careful state management in a React component. An LLM will generate a working component in seconds. That’s the wrong place to use it. Instead:
- Write the state logic yourself, knowing what edge cases matter for your domain.
- Use an LLM to generate the UI layer once you’ve locked down the state contract.
- Ask the LLM to optimize performance or accessibility—then actually understand why the optimization works before shipping it.
The hard part isn’t writing code. It’s knowing whether the code is correct for your specific problem. That requires reading it, tracing through it, breaking it intentionally, and fixing it. If an LLM did the writing, you still need to do all of that.
Build a Verification Habit
This is the concrete practice that keeps you sharp: treat every AI-generated code block as untrusted until you’ve verified it. Not just syntax, not just “it compiles.” Trace the execution path. Check the failure modes. Run it against your mental model of what could go wrong.
When you do this consistently, two things happen. First, you’ll find bugs the LLM missed (they happen regularly, despite the hype). Second, you’ll start asking better questions of the LLM before it generates code, which shortens the verify-debug loop.
A team at Databricks benchmarked this: developers using Claude with aggressive verification caught 3x more issues than teams that blindly accepted outputs. The verification time still beat writing from scratch, and the skill retention was measurable.
Specialize in the Irreducible Human Parts
LLMs are great at code synthesis given clear specs. They’re mediocre at:
- Defining what “correct” means for an ambiguous problem
- Reasoning about performance at the system level (not just local optimization)
- Recognizing when a solution is overengineered for the constraints
- Judging architectural tradeoffs without a clear metric
- Handling novel failure modes in production
- Debugging interactions between multiple systems
If you want to stay sharp, own those problems. Push back on LLMs when they’re writing code for tasks you don’t fully understand yet. Force yourself to do the spec-writing, the design sketching, the “why does this even need to exist” analysis.
Cursor’s agent architecture (planning with frontier models, execution with cheaper ones) is worth studying here. The planning phase—deciding what code needs to exist—is where the human still sits in the loop on hard problems. The execution phase is where LLMs are dominant. That’s the right division of labor.
Maintain a Habit of Doing Small Things From Scratch
Once a month, write a small utility or service without touching an LLM. Pick something just inside your comfort zone, where you remember the shape of the problem but aren’t 100% certain of the details. This forces you to navigate ambiguity, make design choices, and recover from mistakes on your own.
This isn’t about being a purist. It’s about maintaining the neurological pathways that atrophy when you only review code. The best developers using AI tools treat these small projects as deliberate practice, the same way musicians practice scales.
Understand the Model You’re Using
If you’re using Claude Opus 5, Gemini 3.8 Flash, or GPT-6 Astra, spend time understanding what they’re actually good at. Read the model cards. Test their boundaries. Notice when they confidently fail. This isn’t trivia—it’s calibration. The developers who stay sharp are the ones who know exactly when to trust the LLM and when to override it.
GitHub Copilot’s multi-model support (you can now choose between GPT-5.6 Sol, Claude Opus 5, Gemini 3.5 Flash) is a useful forcing function here. Try the same task with different models and notice the differences. That’s how you build intuition about what each one does well.
Watch for Skill Leakage in Specific Domains
Certain coding tasks deteriorate faster than others when LLMs take over. Debugging is the big one. If you never manually trace through a broken system because you just ask the LLM to fix it, your debugging skills will evaporate. Performance optimization is another. System design stays sharp longer because it’s harder for LLMs to do well.
Be intentional about which skills you’re protecting. If you work in backend systems, make sure you’re still doing manual profiling and capacity planning. If you’re in frontend, don’t let the LLM handle all the CSS and layout—you’ll lose the visual intuition.
The Uncomfortable Truth
The workflow that actually works is harder than just letting the LLM do everything. You have to:
- Use the LLM strategically, not reflexively
- Verify everything it generates, even when it looks right
- Do the hard conceptual work yourself
- Build new habits around what you delegate
But that’s the only path to staying sharp. The developers who panic about LLMs aren’t the ones using them intentionally. They’re the ones who thought skill was just about typing fast.
Bottom line: Use LLMs to eliminate tedious code you’ve already mastered, then spend the time you saved on the hard problems that LLMs still can’t fully own—system design, verification, and architectural judgment. Deliberately practice debugging, performance analysis, and spec-writing without AI assistance. The developers staying sharp are treating AI as a way to shift their effort, not as a replacement for thinking.
Question via Hacker News