AI can be applied to almost every kind of knowledge work. That does not mean it should be.
For a while, I approached AI from the opposite direction. I kept finding more places to use it: meeting notes, research, writing, code review, and code generation. The question was usually, “Can AI help with this?”
The answer was almost always yes. But that was the wrong question.
I now ask what happens when the output is wrong.
A meeting summary can be approximate
A meeting may produce an hour of transcript and several pages of notes. AI can compress that material into the decisions, themes, and action items I care about. It might miss a detail or describe something imperfectly, but the original transcript still exists. I can check an important point, and my own notes can ground the summary.
The summary does not need to be a perfect substitute for the meeting. It only needs to make the meeting easier to navigate. Mistakes are usually cheap to detect and correct, and they do not become the foundation of a system I must maintain later.
Production code is different
Production code can look correct while hiding a subtle bug. A missing edge case, an unsafe database migration, or a security mistake may not appear until much later.
If I let AI generate code I do not understand, I become dependent on the same AI to diagnose and repair it. The first version may arrive quickly, but the cost has not disappeared. It has moved into review, debugging, and maintenance.
This creates false confidence. Tests may pass and the application may mostly work. Yet “mostly” is not enough when a small error can compound across a production system.
That does not mean AI should never generate production code. It means the change must remain small enough for me to understand, verify, and maintain myself. AI can accelerate work without taking ownership of the result. I still own it.
My rule
I use AI when one of two conditions is true:
- An approximate result is useful, and mistakes are cheap to find or tolerate.
- The result needs to be correct, but it is small enough for me to fully understand, verify, and maintain.
If neither condition holds, AI is probably hiding work rather than removing it.
This also changes how I think about capacity. Before accepting a task, I estimate how long it would take without AI. If I do not have that time, I should be careful about taking on the work just because AI might make it faster. It can reduce the time needed for a task, but it does not give me unlimited capacity.
A checklist before using AI
Before delegating a task to AI, I ask:
- If the output is wrong, how much does it matter?
- Can I cheaply compare the result with the original source or another reliable check?
- If correctness matters, is the output small enough for me to understand and maintain?
- If the AI cannot finish or repair the work, can I take over?
- Would I still accept this task if I had to complete it without AI?
The last question is the most important. If the answer is no, AI may be encouraging me to accept work I cannot responsibly own.
The useful boundary is not between tasks AI can and cannot perform. That boundary keeps moving. The useful boundary is between mistakes I can tolerate and work I must be able to own.