I can debug my own code, but I often turn to an LLM when I face something new or get stuck starting a feature. I usually understand the explanation afterward, but I worry I'm not learning how to solve problems myself.
How can I build those skills while still using the tools, especially when there's pressure to deliver quickly?
Give yourself some thinking time before asking for an implementation. Write down the inputs, the expected output, and one small example. Then sketch the steps in comments or pseudocode. It doesn't need to be clever or even correct yet. An imperfect starting point is easier to work with than an empty file.
If you're still stuck, ask for a hint or an explanation of the part you don't understand rather than the whole solution. Try implementing it, then check the result against the requirements and tests. Reading an explanation is useful, but making the decisions yourself is different practice.
Practice without the assistant sometimes. Pick a small module or side project and build it using documentation, search, and your own notes. If you get stuck, look things up, but try not to outsource the whole implementation.
That gives you a chance to exercise the parts that can get skipped at work, including figuring out where to start and how to use a library.
Using a tool isn't cheating, but an LLM isn't the same kind of tool as a compiler either. It can make design choices for you and sound convincing when those choices are wrong.
If it generates code, don't stop at being able to explain the lines. Check whether it meets the requirements, handles the cases you care about, and fits the existing codebase. Watch for duplicated functionality too. Generated code can solve the immediate task while making the next change harder.
3rd.drawer.open:
Asking it to explain a library call is fine too. Check the relevant documentation when the behavior matters, since the explanation can be wrong.
Don't measure progress only by how much code you type unaided. Learn the application's domain, how its pieces connect, and why the team made particular choices. Reviewing changes and investigating bugs are useful ways to build that understanding.
Keep searchable notes on library usage, architecture, and the bits of project knowledge that aren't documented elsewhere. You'll have something to consult next time instead of asking the same question from scratch.
Answers are reviewed before publication.
soda.pop.quiz:
A time limit can help when work is moving fast. Even a short attempt gives you a more specific question to ask.