Why I Use AI: People Decide, AI Handles the Repetition

The easiest answer to “Why use AI?” is speed. It can summarize documents, write code, and reduce repetitive work. All of that is true, but it does not fully explain why I keep using it.

I started my career as a developer. Now I build things and take them into the world myself. I wanted to find better ways to work without giving up the room I need for life. Feelings come and go, but the work still has to move forward. AI cannot live my life for me; it is a tool I am grateful to have as I build what I want to make.

I use AI to put better decisions into action and check that the result I wanted was actually produced. Speed matters less than choosing what to solve, deciding how much to delegate, and following through to see whether it worked.

In the AI era, judgment matters more

In the information age, having knowledge was a source of advantage. Now that AI can read widely and produce answers, it matters more to know where and how to apply that knowledge.

Knowing where to strike can matter more than swinging the hammer. AI can swing it faster, but if we pick the wrong place, it only helps us pile up the wrong results. AI does not eliminate cost either. There is the cost of using it, plus the time it takes to check and correct what it produces.

The first question is not “What can AI do?” It is closer to “If this problem went away, how much would I, or someone else, be willing to pay?”

Choose the problem before speeding up the work

AI can turn a vague request into a polished answer. That is also what makes vague requests risky. If the direction is wrong, the wrong result can grow even faster.

Before I delegate, I look at three things:

• How often does the task repeat?
• How costly would failure be?
• How much would the result affect me and other people?

I consider whether the task repeats often, whether the result goes straight into a live service, whether a mistake would be hard to undo, and whether the outcome affects only me or outside customers too. These questions help me decide both what AI can handle and what a person must decide.

“Automate the report” is too broad. “Summarize all 12 source documents from this week and reconcile the numbers” gives me a clear scope and a way to check the result. An experiment starts when I narrow the problem. That is why I choose a problem worth solving before looking for something AI can do.

Connect four things before handing over the work

We cannot expect a person to deliver a result without giving them the materials and authority they need. The same is true of AI. Before I hand over a task, I connect four parts of the work.

1. Context: Which source materials, rules, and good examples should it use?
2. Tools: Which files or services can it read, and where may it save the result?
3. Permission: May it only read, save a draft, or act after approval?
4. Result: What must exist before we can say the task is done?

Without those conditions, “just handle it” leaves quality to chance. But if I specify every step in advance, the workflow can break as soon as the situation changes. It is more useful to define which materials AI may use, which standards it must follow, how far it may go, and what counts as complete.

For example, I might ask for a draft of this week’s report. Use only this week’s sources. Tell me if you cannot read one. Put the ID, summary, amount, and source in a table, then list the totals and anything that needs review. Compare the IDs and amounts in the source and draft, and flag missing items, duplicates, or mismatched totals. Save the draft and its check sheet, but do not share them.

I also organize work context by project so that the source material and the result stay connected:

• 01_sources: materials in scope for this task
• 02_rules.md: requirements to follow
• 03_examples: examples of completed work
• 04_output: AI-generated drafts
• 05_review: how to check the result and what remains unverified

The exact setup can use folders and a terminal, or documents and a project workspace. What matters is making clear which sources and rules to use and what AI is allowed to do. I also set real tool permissions: for example, read-only access to the sources and write access only to the output folder.

People design the work, AI repeats it, and people decide when it is done

My workflow is simple:

People set the goal, scope, and completion criteria. AI reads, transforms, and drafts. At the inspection step, AI compares the full set and flags omissions, errors, and uncertainty. If it finds a difference, I work with AI to correct it and run the same check again. At the end, I review important exceptions and evidence, then decide whether the work is complete.

Before execution, we discuss the facts and constraints, consider options and risks, and let the person with authority set the scope, priority, and next steps. AI can gather evidence and compare options, but it does not have approval authority or the final say. We record recurring decisions in a spec and make the verification steps reusable.

This does not mean a person has to reread every line AI produced. It means deciding where human judgment is essential and making the remaining checks repeatable. In software, that might mean tests and browser checks. In other work, a spreadsheet formula or checklist may be enough to start.

“Done” from an AI is not evidence that the work is done. We need an output that meets the original criteria and evidence we can inspect. If the only thing that changed is the explanation, the work is not complete. Changing only the wording to present a problem as a new feature is the same kind of mistake. Without a clear task and spec, a bug can be dressed up as a feature.

A roadmap sets priority and order; a spec defines the scope and completion criteria. In the AI era, choosing the right direction and carrying work through to a real result remain human responsibilities.

My mornings start differently now

I used to spend each morning rebuilding the picture of where work stood. I checked the previous daily note, Jira tickets, local Git changes, and reviews and changes on GitHub. Only after gathering all of that could I decide what to work on first.

Now I delegate the repeated work of gathering and comparing that information. AI reads the allowed sources (previous daily notes, local Git, Jira, and GitHub) and drafts a checklist for today along with a list of items outside today’s scope. I check whether the priorities make sense, add context that is missing, and question why an item is included or excluded. Only then do I save the daily note.

A short request does not magically understand the work. Behind it are the sources to read, the steps to follow, the completion criteria, and the rules for saving the result. My reusable skills begin with the skill- prefix. In this case, skill-sprint holds the procedure and criteria; daily uses them to prepare today’s work.

Before it runs, I verify which sources it may read and which date it should use. The result is not automatically published or sent as a message. I review the priority and context before deciding whether to save it. Those boundaries keep automation from obscuring who is responsible for the work.

I think this workflow can apply to other kinds of work too. For any task, I would connect three things:

1. Input: Where is the source material? Start with one place, such as email, a document, or a spreadsheet.
2. Judgment: What criteria should guide the work, and what must a person check?
3. Delivery: Who needs the result, in what format, and through which channel? What permissions apply?

The practical question is: “How do I take this material, apply these criteria, and deliver the result here?”

AI compounds when the next task does not start from scratch

More useful than one good request is keeping what the work taught me. I record which sources I needed, what I missed, and which check caught the error. The next time, I reuse what still applies and update what has changed.

AI does not automatically learn my work. I have to preserve what I tried, checked, and revised in a form I can use again. I think of those reusable assets in four parts:

• Tools: how to connect and run them
• Know-how: requests that worked and ways to catch mistakes
• Knowledge: work rules and examples of good results
• Experience: outcomes I have actually tried and verified

Instead of explaining, searching, and repeating the same trial and error every time, I can start from what I already learned and focus on what is new. That is the compounding value I want from AI: each reuse updates the tools, knowledge, and experience I can bring to the next task.

Build a work environment that fits how I work

Paying for AI is only the start. I need to delegate real work, check the results, organize the materials and standards I use, and connect the everyday tools I need: documents, email, spreadsheets, and more. The important thing is to make the environment fit my work, not just to pay for a tool.

In a talk, I suggested investing 10% of one’s salary in using AI. That was my personal suggestion, not a rule for everyone. I did not mean that people should buy expensive tools all at once. I meant choosing one recurring task, trying AI on it, and being willing to spend the time and money that task actually needs.

The way I think about using AI comes down to this:

People own judgment and responsibility. AI handles repetition. Systems make verification repeatable.

The process starts by noticing a problem, deciding what to delegate, connecting the right tools, checking the result, and keeping what we learn. Using AI well does not mean giving up human judgment. It means spending less time on repetition so we can choose better problems and carry our decisions through to real outcomes.

I hope AI helps us do better work and leaves a little more room in our lives. If you are still deciding what to hand over to AI, start with one recurring problem in your own work. Connect its inputs, decisions, and delivery, then check one small result all the way through.