Using AI without losing the learning.

My best workflow starts before I ask AI anything. I read the problem, predict the architecture or solution, and work on it myself for 15 to 25 minutes. That struggle period gives me a model to test and makes the gaps specific.

Ask for leverage, not ownership

AI is especially useful for boilerplate, documentation, repetitive refactoring, test generation, codebase search, debugging hypotheses, and type definitions. When I am stuck, I can ask for a hint, critique, or missing test case instead of asking it to replace the entire reasoning process.

I then implement or adapt the logic, run the tests, and explain the solution back in my own words. If I cannot explain why the change works, I have not finished learning it.

The work I cannot delegate

I remain responsible for architecture, business logic, correctness, security, testing, and reviewing every change. These are the parts where system context and consequences matter most. They also take real time, so they need to be included in the estimate before coding begins.

A lesson from production work

During earlier work, I sometimes optimized for completing the task and did not extract enough knowledge from the system. AI can make that failure mode worse because the output arrives quickly and looks convincing. Reverse engineering the existing architecture, understanding the constraints, and testing failure paths are slower—but that is where much of the durable learning happens.

The goal is not to avoid AI. It is to use it deliberately while keeping judgment, verification, and understanding on my side of the keyboard.