Using AI Without Losing Understanding

Think, form the question, use the tool, understand the answer, verify. AI as reviewer and debugging partner, the dependency check, and what you still own.

Good Tool Use

Problem → Think → Form Question → Use Tool → Understand Answer → Apply → Verify. The tool is in the middle of the sequence, not at the start of it — because a question you have not formed produces an answer you cannot judge.

Q · You have an AI assistant open next to the editor and a problem you do not understand. What is the sequence that uses the tool well, and how do you tell it apart from the one that only looks like it?
AI as Reviewer

Your design → AI critiques → you decide → you implement. The assistant is strongest as a second reader of something you made, because then its output is a list of objections you can judge, not a design you have to adopt.

Q · You have a design for a piece of the system and an assistant that will happily produce one of its own. How do you use it to make your design better without ending up with its design instead?
AI as Debugging Partner

Before the assistant can help with a bug, you must bring four things: expected behaviour, actual behaviour, evidence, and a hypothesis. Bring fewer and it guesses; bring all four and it investigates with you.

Q · Something is broken and you want the assistant's help. What do you have to bring to the conversation for its help to be investigation rather than guessing, and how do you know the difference?
The AI Dependency Check
▶ lab

Four questions about any code the assistant helped with: could you explain it without the tool, recreate its core idea, describe its failure modes, and debug it yourself? Where the answer is no, go one layer deeper — that layer is yours now, whether you understand it or not.

Q · Code the assistant wrote is in your system and it works. How do you find out whether you understand it well enough to own it, and what do you do about the parts you do not?
If You Are Nothing Without the LLM

"If you are nothing without the LLM, you should not have it." Read constructively: the tool should amplify an engineering ability that exists, not stand in for the understanding required to own the result. The strongest opposing view — that fluency with the tool is itself the new skill — is stated and taken seriously.

Q · What does it mean to be "nothing without the LLM", how would you tell whether it describes you on a given piece of work, and what does the sentence actually ask you to do?
What You Still Own

The assistant can produce code, architecture, SQL, tests and explanations. You still own requirements, correctness, trade-offs, security, failure handling and understanding — the things that need to know what the system is for, and the things that are yours when the output is wrong.

Q · The assistant can produce almost every artefact in the project. What is left that is yours, why is it yours rather than a gap in the tool, and how do you make sure it gets done?
The Engineering Notebook
▶ lab

Current goal, assumptions, unknowns, decisions, experiments, findings, next step. A notebook in your own words is where independent reasoning is built — and where you can see, at a glance, whether the tool has been doing yours.

Q · How do you keep your own reasoning about a problem in one place so that it accumulates, survives a day off, and can be checked against what the assistant produced?