· Development · 4 min read
I'm Auditing How I Work With AI
I use AI throughout product development, but volume does not prove value, so I am measuring where it helps, where I intervene, and where work gets repeated.
I’m Auditing How I Work With AI
AI touches most parts of my work now. I use it to explore a codebase, trace a production failure, sketch an interface, write tests, challenge a plan, and prepare a release.
I can remember the impressive moments. A difficult bug gets traced across several services. A rough idea becomes something I can open in a browser. A repetitive change lands across dozens of files.
Memory gives those moments too much weight. It forgets the vague prompts, repeated corrections, unnecessary rewrites, and sessions where I would have finished sooner by making the change myself.
I want a more useful answer than “AI makes me faster.” I am auditing how I work with it.
The Question
The audit has one job:
Which parts of my AI-assisted workflow create useful progress, and which parts create output that I have to repair?
I do not plan to measure generated lines of code or prompt volume. More output can produce more review work. A long session may solve a difficult problem, while a short session may send the project in the wrong direction.
The unit that interests me is a completed piece of work with evidence behind it.
The Audit Record
I will record a small set of facts after each selected work session:
| Field | Question |
|---|---|
| Work type | Was I investigating, deciding, implementing, testing, or documenting? |
| Starting condition | Did I provide a clear problem, relevant context, and acceptance criteria? |
| AI contribution | Did the AI explore, propose, implement, review, or run checks? |
| My intervention | Did I redirect the work, correct an assumption, change the design, or stop it? |
| Evidence | Which test, screenshot, log, diff, or working behavior supported the result? |
| Rework | Did someone have to revisit the change after the session? |
| Outcome | Did the work ship, produce a decision, expose a problem, or get discarded? |
This record should take less than two minutes to complete. If the audit adds too much ceremony, I will stop doing it before I learn anything.
Privacy Comes Before Analysis
My work includes client code, private product decisions, credentials, and conversations that were never meant for publication. The audit does not need raw prompts or model responses.
I will keep the analysis at the level of task type, intervention, evidence, and outcome. I can learn that a session required three redirects without retaining the words inside those redirects. I can record that a production log exposed the cause without copying the log into a report.
Any example I publish will use my own work, approved material, or an anonymized description that preserves the lesson without exposing the project.
The Patterns I Expect to Find
I have a few hypotheses going in.
Clear acceptance criteria will reduce rework
AI can execute a precise task with surprising reach. It also executes vague tasks with the same confidence. I expect sessions with a named behavior and a verification method to need fewer corrections.
Investigation will produce more value than first-draft code
A senior developer can often write the code. Finding the right file, reconstructing a failure path, or comparing several approaches takes more time. I expect AI to create more leverage during exploration than during implementation.
Fast output will increase review pressure
An agent can edit more code than I can inspect in the same period. I expect some fast sessions to lose their advantage once I include review and correction time. I explore that problem in When AI Gets Faster, Verification Becomes the Bottleneck.
Product and risk decisions will stay with me
AI can present options and surface consequences. I still have to decide which user problem deserves attention, which trade-off fits the business, and whether the evidence supports release. What We Still Do Manually When Building With AI explains that boundary.
The Result I Want
The audit should change how I work. A report that confirms my preferences and then disappears into a folder has no value.
I expect to leave with a short set of operating rules:
- Tasks that I should delegate sooner.
- Tasks that need a stronger brief before an agent touches them.
- Verification steps that catch the most common failures.
- Situations where AI adds review cost without enough benefit.
I also want to find one habit to stop. It may be starting implementation before I can describe the expected behavior. It may be continuing a long session after the context has become noisy. The evidence can make that choice for me.
Publishing the Findings
I will publish the method, the aggregate findings, the surprises, and the changes I make afterward. I will keep private material private and label the limits of the sample.
The audit may show that AI helps less than I assume in some parts of the work. That answer would save time. A useful experiment does not owe me a flattering result.

