AI as a Tool: Why Using LLMs Takes Skill
AI can automate work without replacing human judgment. Learn why LLMs are tools, where they fail, and how to use them with skill and oversight.
AI Is a Tool. Using It Well Takes Skill.
An LLM can draft an answer, explain a block of code, or summarize a long document in seconds. That kind of automation is genuinely useful - but it also raises a question you can't really dodge: are you using a tool, or are you handing work to a system you don't understand?
This distinction matters, because the label changes what people assume. If everything software produces is "automation" rather than "tool use," then terms like "tool" stop being helpful for everyday instruments like spreadsheets or compilers. On the other hand, if calling something a "tool" implies it's always controllable and trustworthy, then you end up excluding plenty of tools people use every day - tools that still require judgment.
A better way to frame it is that automation and tool use can both be true. An LLM can do work automatically while still acting as an instrument you steer. The real question isn't whether the system generates an answer on its own. It's whether you can set a goal, check the result, fix mistakes, and decide what happens next. This article lays out that distinction, the skills involved, and a practical way to use LLMs without confusing convenience with understanding.
The tool-versus-automation debate misses the practical question
In his October 11, 2026 essay, AI Is Not a Tool, Rich Hickey argues that LLMs are automation, not tools, because they can't be wielded the way a human can wield an instrument. His underlying worry is real: when you hand off too much work, you lose the effort that builds judgment and understanding.
But that doesn't settle what an LLM is. A tool doesn't have to be perfectly predictable, dead simple, or safe in every situation. Those are the things we evaluate when we choose and use tools. They shouldn't be a hidden checklist for what "counts" as a tool.
A saw is a tool, but it doesn't magically guarantee a straight cut. A chisel is a tool, but owning one doesn't make someone a sculptor. In both cases, the person using it has to understand the job, control the instrument, notice when things go wrong, and adjust. Software works the same way.
Automation is often part of a tool
Lots of tools do some work without a person micromanaging every internal step. A compiler turns source code into a program. A spreadsheet recalculates formulas when a value changes. No one manually runs every internal operation, but the user still chooses inputs, inspects outputs, and decides what comes next.
LLMs add a different kind of automation: they generate text, code, or other outputs based on an instruction and context. That doesn't make them identical to compilers or spreadsheets. Their outputs are less deterministic, and the range of tasks they can touch is wider. That's exactly why you shouldn't treat them as a black box. Still, it doesn't automatically mean they can't be used as an instrument.
The more useful question is operational: what control does the user have, and what judgment do they still need to provide? An LLM can fit into a tool-assisted workflow when a person sets the goal, checks the response against evidence, and stays responsible for what they do with it. If you accept an answer without review, the process starts to look like delegation you haven't examined. So the distinction is about how people use the system - not just what the software is called.
Unpredictability is a limitation, not a full definition
LLMs can produce confident mistakes, misunderstand instructions, or vary their answers to similar prompts. That makes them harder to control than many narrowly designed tools - and it raises the importance of evaluation and feedback.
A reliable calculator and a generative model shouldn't earn the same level of trust for the same job. Basic calculations are often easy to verify directly; complex explanations might require domain knowledge, sources, or tests. That's a reason to pick the right tool and verification method. It's not a reason to pretend that "unexpected output" automatically means "never use as an instrument."
Using an LLM well is a skill
Using an LLM well isn't only about prompt writing. You can polish an instruction, but you can't replace understanding the task or judging whether the output makes sense. Skill shows up throughout the interaction: framing the problem, supplying the right context, asking good questions, evaluating what you get back, and correcting course.
One of my colleagues used to say, "AI is a mirror." The idea is simple: the system tends to reflect the quality of the thinking you bring to it. A careful user will test assumptions or ask for an alternative explanation. A rushed user may treat the first fluent response as proof. The model matters, but your habits shape what happens next.
Ask questions that you can actually evaluate
A broad request like "make this better" gives an LLM lots of room to guess what "better" means. That can work for early exploration, but it's a weak instruction when accuracy matters. Make the goal specific, and define the constraints you can check.
For instance, a developer digging through unfamiliar code might ask the model to:
- Explain what a particular function seems to do.
- Identify assumptions behind that interpretation.
- Point to the relevant lines or symbols in the code you provided.
- Suggest a possible change and explain the risks.
- Propose tests that would help confirm whether the change works.
Those prompts don't guarantee a correct answer. They do make the output easier to inspect. They also keep the point of the interaction visible: understanding the code and deciding whether a change is justified, not just collecting plausible text.
Expertise makes the instrument more valuable
If you know the domain, you're more likely to spot a missing condition, a bad assumption, or an answer that sounds convincing but doesn't fit. That's not a reason to avoid AI - it's what makes supervised use realistic.
There's also a practical asymmetry. LLMs are tempting when you don't have the knowledge to do the task yourself. And that's exactly when verification is hardest. For a low-stakes first draft, the trade-off may be acceptable. For a security decision, a production migration, or legal advice, it's not enough that the output reads smoothly. You need an independent way to validate it - or a qualified person to check it.
How much review you need depends on impact. A typo in an internal draft costs little. An incorrect command against a production database can cost a lot. The higher the cost of being wrong, the less you should lean on fluency as "evidence."
Use AI to extend your thinking, not to replace it
The worry about summaries replacing actual reading is legitimate. If your goal is deep understanding, skipping the original paper can erase the work that builds your understanding - caveats, argument structure, and the evidence behind conclusions included.
But summarization isn't the only way to use an LLM around reading. You can read the paper first, then ask the model to challenge your interpretation, explain a term you don't understand, or suggest a counterargument you should investigate. You can compare its response to the text and decide whether it actually surfaced something useful.
The same idea applies to writing, research, and programming. The tool can help you move through the work, but what matters is what mental effort you keep and what you hand off. The question isn't whether AI showed up. It's whether the process still leaves you with enough understanding to make a sound decision.
A practical feedback loop for LLM work
In real projects, the safest approach to a system that can fail isn't pretending it never will. It's making failure visible before it causes damage. Treat an LLM interaction like a feedback loop, with human judgment where it counts.
1. Define the job and what an error would cost
Say what you need the model to do and how the output will be used. "Explain this code so I can investigate a bug" is not the same task as "rewrite this code and deploy the result." The second option carries more operational risk.
Before you start, ask what a wrong answer would cost. Would it mislead a customer? Expose sensitive information? Break a service? Create a compliance problem? That determines how much evidence and review you need.
2. Give the model bounded, relevant context
Provide what the model needs for the task, without assuming that more context is automatically better. Irrelevant material can muddy the issue, and sensitive data may not belong in the system at all. Follow your organization's data-handling rules, especially for customer records, credentials, confidential business information, and regulated data.
Be explicit about constraints: the language or framework, the format you want, what the model should not assume, and what it should ask you to clarify. A bounded task is easier to evaluate than an open-ended request to "solve everything."
3. Treat the first response like a hypothesis
An LLM response is something to examine, not a verdict. Look for unsupported claims, missing edge cases, contradictions, and details you can't check. If the model cites a source, verify it. If it proposes code, read it instead of assuming the explanation matches what the code actually does.
Ask follow-up questions when they help test the answer - not just when they produce more text. For example: "What assumption would make this recommendation wrong?" or "Which part of the input supports that conclusion?" A good response should survive some scrutiny. If it won't, don't inflate your confidence just because the model sounds certain.
4. Verify with a method that fits the task
Different outputs need different checks. Code can be reviewed, run in a safe environment, and tested. Factual claims can be checked against primary sources. Calculations can be recomputed. Writing can be checked against the brief and intended audience.
For consequential changes, separate verification from the model's own explanation. Asking the same system to confirm itself can reveal problems, but it isn't independent validation. Where possible, use a test, a source, a reviewer, or a process that could catch the model's mistake without relying on the same reasoning that produced the output.
5. Keep responsibility with a person
The model can propose. A person - or a responsible team - decides whether to accept the proposal and what happens next. That doesn't mean someone must manually perform every operation. It means responsibility is explicit, and the workflow includes checks before an automated output affects real users, money, data, or infrastructure.
A simple rule helps: automate reversible, low-impact steps more readily; add review and safeguards as impact and irreversibility increase. It's not a universal formula, but it forces the right conversation about control instead of treating all AI use as either harmless or forbidden.
Where delegation becomes risky
Calling an LLM a tool shouldn't be used to brush off real concerns. Models can fail to follow instructions, generate harmful or inaccurate content, and behave unpredictably in a given context. If they're connected to external systems, a bad output can cause trouble beyond a misleading paragraph.
Even the way we talk about these failures matters. Phrases like "go rogue," "escape containment," or "conspire" can imply motives that we haven't actually established. It's more useful to describe the engineering problem: the system produced an unexpected result, had access to an action that mattered, and the safeguards didn't prevent harm.
Separate surprising output from intent
Software can behave in ways its designers didn't anticipate. That's a real reliability and safety issue. But calling an unexpected output a conspiracy adds an implication of intent that you don't need to understand or address the failure.
Teams respond better when the language is precise. Ask what the system was allowed to access, what instructions and inputs it received, how the output was checked, and what limited its ability to act. These questions point to concrete design and operational changes. When people use anthropomorphic shorthand, it can blur the issue and make the system sound like an independent actor instead of software operating within a specific setup.
Identify when you're delegating too much
Even if you're using an LLM as a tool, you can still delegate too far. If you can't explain what the output is for, can't spot a serious error, and don't have a plan to check the result, then you're not really exercising control. That might be fine for a disposable, low-stakes task. It's a poor approach when you need accountability.
Use these questions as a quick check:
- Can I state the task and what a successful result looks like?
- Do I have a way to identify a serious error?
- Is the output reversible or safe to test before using it?
- Does the system have access to data or actions it doesn't need?
- Who is accountable for the final decision?
If the answers are fuzzy, reduce the system's access, narrow the task, or add human review before you rely on the result. The goal isn't to ban automation. It's to make the boundary between assistance and unreviewed delegation obvious.
Conclusion: judge the use, not the label
LLMs aren't dependable in the same way a basic calculator is, and their broad capabilities make them harder to supervise than many conventional tools. That deserves careful attention. But automation doesn't automatically cancel tool use, and imperfect reliability doesn't automatically make an instrument unusable.
The real distinction is between using an instrument with skill and delegating work without enough understanding or oversight. Define the task, assess what it costs to be wrong, provide relevant context, test the output, and keep responsibility for decisions clear. Then adjust how much you review based on the consequences.
If you're introducing LLMs into your workflow, start with one bounded task and decide in advance how you'll verify the result. That gives you a better basis for judgment than arguing about labels alone. For more context, read the original article.