How to Keep Your Coding Skills When AI Writes the Code

0:00Have you ever looked at code AI helped you write and thought: It works. But could I explain it to somebody else? I have. I'm Joseph Richard. I'm a software developer. Mostly Java, for about 30 years. And I noticed I was spending more time approving code than working through the decisions behind it. So here's what I did to stay sharp. I gave Claude a whole user story for a play button feature. I figured I understood the change well enough to test it.

0:31Then I click play and nothing happened. When I asked myself where the click was supposed to start playing back, I realized I couldn't trace it through the code. I rolled the change back, gave Claude one piece of the story at a time. That way I could follow and test each change before moving on.

0:48That's the distinction I want to talk about. Getting a change finished and understanding that the change can feel like the same thing, right up until somebody asks why it works. The appeal's obvious. It can take you from a blank page to something. Explore an API, and do the repetitive code. All of that is useful. But there's a trade I think we need to watch. You can't keep accepting decisions without working them through first. With AI, I get less practice making those decisions.

1:19That gap is comprehension debt. The distance between what the system does and what I can actually explain about it. Doesn't mean AI automatically makes you a worse developer. It gives us a useful question to ask, though. What parts of the work are helping us learn?

1:35And what parts are we just waving through? Take a hypothetical web service. It calls a payment provider. You ask AI to add retries when the call times out. The generated code even looks tidy. It even logs. But the important question is what a timeout actually tells. Did the payment fail? Or did it succeed and the response just never reached you? Retrying without accounting for that could charge someone twice. This is where I think we need to slow down. Before generating the implementation, write down what must stay true.

2:09One payment request cannot become two charges. Then work through how the provider handles repeated requests. Now you have something meaningful to review against. That also changes how I feel about which work to hand over. The useful boundary is risk. A repetitive mapper might be a reasonable thing for AI to draft, but payment behavior access rules or an unfamiliar algorithm? Those need much closer attention. Configuration and tests, they carry serious consequences as well. So file being boilerplate doesn't settle the question. I don't need to type every line.

2:45I do need to understand the decisions that could hurt someone, lose data, or make the system behave incorrectly. The size of the change matters. A 900-line patch makes it easy to miss something. With that retry example, I'd look at one behavior at a time.

3:01What happens after a timeout, how a repeated request is identified, and what the tests actually show. Small patch, review it, test it, then continue. Done that way, you have a better chance of following the reasoning. The check I find most useful is simple.

3:18Close the AI conversation, explain the change in your own words. Keep the code open, it's not a test. Where does the input come from and where does it go? Why does the change fit the system? What assumptions does it depend on? And what happens if the dependency fails? For a payment example, can you explain what happens if the provider accepts the payment, but your service never gets the response? If you can't explain it, pause the approval, trace it, test it, or work through it with someone who can. A fluent explanation from AI can help you investigate. You still need to validate the explanation against what the code has and what the system actually does. This is a good place for doing real work without AI. Pick a bug in your own codebase.

4:05Trace the execution, use the debugger, write the fix, and decide which test it needs. You don't have to turn every ticket into an exercise. Just leave some room to practice your skills. I'd be interested to hear which skills you found you still practice naturally. Which ones you now have to make time for.

4:24For a team, the same question gets bigger. Who else understands this change? A short note about the decision and an occasional walkthrough can help. Ask the owner to explain why the change works, which assumptions matter, where they'd start debugging it. Keep the conversation curious. If someone can't explain a section yet, you found a place to investigate together. That's a much more useful outcome than making people feel they have to hide how much help they used. So that's where I land. Have a plan, pay attention to risk, keep changes small enough to understand, explain the behavior, and do some hands-on practice every week. After 30 years, I'll keep the reasoning. What I care about is understanding the system I'm responsible for. AI can type. What's your experience with AI? Has it made you a better developer or worse? What skills have you noticed yourself practicing less?

5:18If you've got a specific example, share it in the comments. I'd like to hear what your actual day-to-day is like. And subscribe to Code, Create & Care for more conversations about building software and businesses with AI.