Ten habits for working with AI.

Put AI between you and the work.

Question anything you do manually before assuming it has to stay manual.

• Before doing a task by hand, ask whether it needs to stay manual.
• Ask AI to explain unfamiliar code, draft a test or review a change.
• Start with a small piece of work whose result you can judge.
• Do it yourself when the setup or review would cost more than the help.

Considering AI does not mean granting access. Keep private data and secrets out of the experiment.

Define what finished looks like.

Illustrative brief for a small bug fix:

"Fix the empty-state crash. Add a regression test. Return a diff and the check results. Leave the API and dependencies alone."

Name the output, the checks and what must stay unchanged. Ask about missing decisions before work starts.

Keep access narrow and reversible.

Keep production access, publishing, deletes and unrelated dependency changes out of scope.

Use AI to vet your ideas.

"Talk through this design with me before we write code. What are the trade-offs? Where could it fail? What simpler option should we consider?"

Bring the constraints and push back on the answers. Check assumptions against the code and what your users need.

Treat AI as a coding partner, not an authority. You make the design decision.

Ask for work you can open after the chat.

Artifacts are durable outputs you can inspect, edit and hand off.

Documents, diagrams, prototypes, diffs, sample files, presentations and posts.

Revise the part that needs work.

Illustrative revision request:

"On the artifacts slide, define the term in plain English and add presentations and posts. Keep the other slides and navigation unchanged."

Name the file, section or behavior. Review the diff for changes outside that scope.

Check the result with evidence.

Ask what actually ran, what passed and what nobody checked.

A second agent can help review. Agreement between agents is not proof.

Count the review work.

• Record the task, the result and what you had to correct.
• Count the time spent briefing, inspecting, revising and checking.
• Keep the useful checks. Change or stop a workflow when its cost no longer makes sense.

A fast first draft can still leave you with more work. Judge quality and total effort before saving the procedure.

Save the procedures worth repeating.

Turn a useful workflow into instructions you can read and change.

• Write when to use it, the steps, required access and when to stop.
• Include the checks that tell you whether it worked.
• Read and adapt third-party instructions before letting them use tools.

Optional examples: Matt Pocock's skills for clarifying a plan or test-driven work. Source [23]

Ask for a plan before implementation.

Before AI changes code, ask it to lay out the work:

• A plan with the affected files and what will change in each.
• A test strategy, including the behavior that could break.
• Risks and open questions that need an answer.

Set a checkpoint: review the plan together before any code changes.

Own the release.

You decide what ships. You remain responsible for what happens afterward.

Name the owner before publishing. An AI-written change still needs someone to answer for it.

Try it on one real task.

Choose a development task or a communication artifact you already need.

• Write what finished looks like and what you will inspect.
• Make an editable first artifact. Open it and request one specific revision.
• Compare the result with the brief. Was the quality good enough, and was the total review effort worth it?

Audience view hides notes. Use Notes or open the speaker view. Notes are public.

Chuck Blake // chuckblake.com // Companion resources