There is a debate raging in the AI world right now. Rich Hickey, the creator of Clojure, wrote a provocative essay titled “‘AI’ Is Not a Tool”, arguing that LLMs are automation rather than tools because they cannot be truly wielded. The response from the other side, “AI Is a Tool. Using It Well Takes Skill,” makes a different point: an LLM can be something a human wields, and doing it well takes skill, just like any other tool.

I think the second side is right, but the framing matters. Using AI tools effectively is not about memorizing prompt tricks or finding the magic words that unlock perfect outputs. It is about developing a set of practical skills that help you direct AI systems toward useful results while avoiding the pitfalls that waste your time and produce garbage.
I have been running AI tools daily for the past year, both for my own ICT work and for managing the tech division. Some days the tools feel like superpowers. Other days they feel like arguing with a confident intern who never read the documentation. The difference is not the model. It is the skill of the person directing it.
Skill 1: Structured Prompting Is the Baseline, Not the Ceiling
The most basic skill is learning to write prompts that give the AI enough context to do the job. This is not about being clever with words. It is about being clear about what you want.
A weak prompt looks like this: “Write a script to parse CSV files.” The AI will produce something generic that may or may not match your actual data format.
A strong prompt provides structure:
Write a Python script that:
1. Reads a CSV file with columns: date, amount, description, category
2. Filters rows where category is "Office Supplies"
3. Groups by month and sums the amount
4. Outputs a markdown table with columns: Month, Total
5. Uses only the standard library (csv, datetime, collections)
6. Handles missing values by skipping them with a warning
The difference is specificity. You told the AI the exact columns, the filter logic, the output format, the library constraints, and the error handling expectation. The AI does not have to guess. It can focus on writing good code instead of making assumptions.
Anthropic’s official prompt engineering guide recommends leading with direct action verbs, stating what you want the output to include, and giving the AI explicit permission to express uncertainty rather than guessing. These are not hacks. They are the baseline for clear communication with a system that cannot read your mind.
Skill 2: The Verification Loop
Here is the hard truth about AI tools: they are probabilistic, not deterministic. They will sometimes produce code that looks correct but has subtle bugs. They will sometimes hallucinate API endpoints that do not exist. They will sometimes give you confident answers to questions they know nothing about.
The skill that separates effective users from frustrated ones is the verification loop. Every time an AI produces something you intend to use, you verify it:
- Code: Does it compile? Do the tests pass? Are the imports and dependencies correct? I have caught AI-generated code that used deprecated APIs, invented function signatures, and introduced race conditions I would never have written.
- Factual claims: Did the AI cite a real paper, a real API version, a real configuration option? Check the primary source. I once asked an AI for the syntax of a Kubernetes resource and got a plausible-looking answer that was simply wrong.
- Logic: Does the reasoning hold up? AI is good at generating plausible-sounding arguments that fall apart under scrutiny. If the AI recommends a particular architecture, ask it to explain the trade-offs.
The verification loop is not a sign that AI tools are broken. It is a sign that you are using them correctly. As I discussed in my article on running local AI for daily tasks, the whole point of having AI assist you is to move faster, not to skip thinking.
Skill 3: Context Management Is a Discipline
AI models have a finite context window. Everything you put into a conversation competes for space. If you stuff the context with irrelevant information, the AI will start ignoring important details or losing track of what you asked for.
The skill here is managing what enters the context and when. A few practical habits:
- Start fresh conversations for new topics. Do not reuse a conversation about database optimization to then ask about frontend design. The old context will interfere.
- Give the AI the relevant files, not the whole project. If you are working on a specific module, paste that module’s code. Do not dump your entire repository into the prompt.
- Summarize and reset when conversations get long. When a conversation has gone through 20+ exchanges, the early context is probably being compressed or forgotten. Ask the AI to summarize the decisions made so far, then start a new conversation with that summary.
- Use structured context. Instead of a wall of text, organize what you give the AI with clear headings, bullet points, and separators. The AI processes structured information more reliably.
Managing the AI tools on your machine, like I covered in my guide on managing Copilot’s file access and privacy settings, is part of the same discipline. You are not just configuring software. You are controlling what information the AI has access to and when.
Skill 4: Knowing When Not to Use AI
One of the most important skills is knowing when to put the AI away. Not every problem benefits from AI assistance. Sometimes the traditional approach is faster, more reliable, and produces better results.
Here is a simple framework I use:
| Use AI when… | Do not use AI when… |
|---|---|
| The task involves natural language generation or transformation | The task requires exact, deterministic computation |
| You need a first draft you will edit and refine | The output must be 100% accurate on the first try |
| The problem is well-defined but tedious to solve manually | The problem requires real-time data the AI does not have |
| You can easily verify the output | Verification is impossible or too expensive relative to just doing it yourself |
As I wrote in my piece on Tony Fadell and the failure of AI gadgets, the first wave of AI products failed because they solved no real problem. The same principle applies to your own use of AI. If a task does not benefit from language modeling, do not force it into an AI workflow just because you can.
Skill 5: Building a Daily AI Workflow
The real skill is not any single prompt or technique. It is building a daily workflow where AI tools fit naturally into your existing processes.
Here is what my typical day looks like:
Morning: Code Review and Planning
I start by asking the AI to review code I wrote the previous day. I paste the diff and ask: “What are the potential bugs, security issues, and performance problems in this change?” The AI catches things I missed, and I verify each flag before acting on it.
Midday: Research and Documentation
When I need to evaluate a new technology or write documentation, I use the AI to generate a first draft. I then rewrite it in my own voice and verify every claim. The AI saves me time on the initial structure and research. I save myself from publishing garbage by doing the verification pass. The rise of AI agents, like Anthropic’s decision to cut internet access for its agents, shows how quickly this space is evolving.
Afternoon: Problem-Solving
When I hit a tricky bug or design problem, I describe it to the AI in detail, including what I have tried and what the constraints are. The AI often suggests approaches I would not have considered. I evaluate those suggestions critically, because some of them are wrong or inappropriate for my context.
This is not magic. It is a collaboration where I bring the domain knowledge, the context, and the judgment, and the AI brings speed, recall, and the ability to generate multiple options quickly.
The Real Skill: Being the Navigator
The most effective AI users I know share one trait: they treat AI as a tool they wield, not a magic box that produces answers. They direct it, question it, verify it, and know when to set it aside.
As the response to Hickey’s essay pointed out, the distinction that matters is not between tools and automation. It is between wielding an instrument with skill and delegating work without adequate understanding or oversight. That distinction applies to AI, and it gives us something more practical than debating definitions.
The developers who get the most value from AI are not the ones with the most sophisticated prompts. They are the ones who have built the habits of clear communication, critical verification, and disciplined context management. Those are skills. And like any skill, they improve with practice.