Using AI with old discipline.
How I use AI assistants day to day, the rules I follow, and a practical way for a team to start. No hype: what helps, what to watch, and how to find out for yourself.
Four everyday uses.
Read unfamiliar code
I ask for a map first (what calls what, where the seams are), then check every claim against the code before I rely on it.
Draft plans and records
First drafts of plans, decision records and runbooks. I edit them hard; the thinking and the sign-off stay mine.
Walk QA checklists
I run a change against a checklist and have the assistant look for what I did not think of, then I verify each finding.
Build with a pair
This whole site (code, deploy scripts, documentation) was written with an AI coding assistant. I review every change, and each one is a commit that says why.
Guardrails I follow.
- Treat its output like a pull request from a new teammate: read it, test it, own it.
- Tests before trust. If it cannot be tested, it is a suggestion, not a change.
- Keep diffs small so a human can actually review them.
- Never paste secrets, credentials or proprietary code into a tool that has not been approved for it.
- Check facts, links and API names. Confident answers can be wrong.
- Say when AI helped: commits carry a co-author line, and write-ups say how they were made.
What works for me.
- Ask for a map before a change, then verify it.
- Give constraints, and say what must not change.
- Ask for alternatives with tradeoffs, not one answer.
- Ask it to list what it could not verify.
- Have it write the test first, then the code.
Where it helps, and where to be careful.
Where it tends to help
- Getting oriented in a large codebase
- First drafts of documentation, plans and tests
- Summarizing logs, incidents and long threads
- Translating between formats and languages
- Explaining unfamiliar errors and tools
- Walking a checklist against a change
Where to be careful
- Security-sensitive code and anything with real credentials
- Business-logic decisions that need context only people have
- Data you are not allowed to share with a third party
- Large generated diffs nobody can review
- Licensing and provenance of generated code
- Over-trusting a fluent answer
Try it the way you would try any change.
- Pick one workload. Choose a task with a clear before-and-after, such as reading legacy code for an upgrade.
- Write the guardrails. What data is allowed, who reviews, what must be tested, and where AI use is recorded.
- Trial for 30 days. Measure against a baseline: time, defects caught, review effort. Keep notes on misses, not only wins.
- Review honestly. What did it catch, what did it get wrong, and what did it cost in review time?
- Ship, park or stop. Decide, write the decision down, and share what worked so the next team starts ahead.
Five questions.
- What data will this tool see, and are we allowed to share it?
- Who reviews its output, and how do we know they did?
- How will we measure whether it helped?
- What happens when it is confidently wrong?
- What does it cost, in money and in review time?
See the AI pair-review checklist concept → · The research question behind it →