Working Effectively with AI

Part One of this series argued that important AI-assisted work can benefit from independent redundancy. Part Two argued that users must choose the right kind of AI before judging what AI can do.

Now assume both conditions have been satisfied.

You selected a capable model. You gave important work an independent review path. The result is still poor.

At that point, a harder question deserves to be asked:

What if the AI is not the problem? What if the user is?

That is not an insult to the user. It is a systems question. If the human defines the objective, supplies the context, chooses the sequence of work, approves intermediate results, and decides what counts as finished, then the human is not outside the AI workflow. The human is one of its components.

The User Is Part of the System

We often speak about AI performance as though the model operates in isolation. In practical work, it rarely does.

The user decides what the problem is. The user decides what information to provide. The user decides what must not change. The user decides whether the first result is acceptable, whether a correction is needed, and whether the work should continue.

Every one of those decisions can improve the result. Every one can also damage it.

The model can fail. The software can fail. The data can fail. The assumptions can fail. And the user can fail too.

Recognizing that is not anti-human. It is basic quality control.

A Better Model Cannot Rescue a Bad Process

There is a tendency to treat AI like a vending machine: insert one prompt, receive a finished product, and blame the machine if the output is wrong.

That approach may work for a simple request. It becomes fragile when the task includes dozens of requirements, dependencies, exceptions, files, languages, technical constraints, and acceptance criteria.

A stronger model may tolerate a bad process for longer. It may infer more of what the user meant. It may recover from ambiguity more gracefully. But no model should be expected to compensate indefinitely for an objective that has never been made clear.

A better tool can increase capability. It does not remove the need to manage the work.

Prompt Engineering Is Not Magic

The phrase “prompt engineering” can create the impression that somewhere there is a perfect sentence that unlocks perfect results.

For complex work, that is usually the wrong mental model.

A useful prompt matters. Clear language matters. Good examples matter. But the larger skill is managing the interaction over time.

What is the objective? What context matters? Which constraints are absolute? Which preferences are optional? What should happen first? What should be checked before the next step? What evidence would prove that the task is complete?

A short instruction at the right moment in a disciplined workflow can be more effective than a sophisticated paragraph containing twenty requirements.

Define the Objective Before the Instruction

Users often know what they want when they see it but have not defined what success actually means.

That distinction matters.

“Improve this website” is not an acceptance criterion. “Change only the three specified images and leave every other file unchanged” is much closer to one. “Make the translation better” is vague. “Preserve the meaning, technical terminology, tone, names, and hierarchy while producing natural professional French and Arabic” gives the work boundaries.

The objective should identify both what must change and what must remain protected.

In engineering terms, the AI needs a target state and constraints.

Break the Work Before the Work Breaks

One of the simplest ways to improve AI-assisted work is to stop asking for everything at once.

Complex work should often be divided into controlled stages: establish the baseline, define one category of change, execute it, inspect it, verify that unrelated elements remain intact, and then continue.

This is not a special rule invented for AI. It is standard troubleshooting discipline.

If ten unrelated changes are made in one step and the system breaks, locating the cause becomes difficult. If one controlled change is made and verified, the failure surface is smaller.

AI makes this discipline more valuable because the system interprets instructions. Every additional requirement increases the opportunity for a misunderstanding to propagate into later work.

Preserve a Known-Good Baseline

Before modifying a working system, know what “working” means and preserve a version that proves it.

A known-good baseline provides more than a backup. It provides evidence.

When a new result is wrong, the user can compare it against the last approved state instead of reconstructing from memory what should have remained unchanged.

This is especially important in AI-assisted deployment work, where a visible page may look correct while shared components, routes, styles, assets, or configuration have changed elsewhere.

The baseline turns “I think something changed” into “this file changed and it was not authorized.”

Verify Each Step Before Continuing

A common failure pattern is to accept an intermediate result because it looks close enough, then build five additional steps on top of it.

By the time the original error is discovered, later work depends on it.

Verification should therefore happen while correction is still cheap.

If the AI edits a file, inspect the file. If it changes a route, test the route. If it translates a page, compare meaning and structure. If it generates code, run the relevant checks. If it claims that only one area changed, compare the delivered artifact with the baseline.

Do not let a persuasive explanation substitute for evidence.

Stop Building on a Bad Result

Another common mistake is continuing to repair a conversation that should have been abandoned several instructions ago.

The first result contains an error. A correction is added. The correction introduces another problem. Another instruction is added. Then an exception. Then a clarification. Then an instruction explaining which previous instruction no longer applies.

Eventually, the conversation becomes a stack of patches instead of a clean description of the desired result.

At that point, continuing can be worse than restarting.

Return to the last known-good state. Restate the current objective. Remove obsolete corrections and assumptions. Start again from a clean baseline.

Engineers revert broken code. Technicians return equipment to known-good configurations. AI workflows deserve the same discipline.

Restarting is not failure. Sometimes it is controlled recovery.

Review the Artifact, Not the Explanation

An AI can sincerely report that it changed only what was requested and still be wrong.

The explanation is generated by the same system that performed the work. It is not independent proof of the work.

For software, inspect the files, routes, configuration, tests, and diffs. For research, inspect the evidence. For calculations, recompute critical values. For documents, verify the facts, structure, and source material. For translations, compare meaning rather than merely fluency.

The closer the review gets to the real artifact, the more useful it becomes.

If You Cannot Recognize a Bad Answer, You Are Not Supervising

AI can produce polished output very quickly. That surface quality creates one of the biggest traps in AI-assisted work.

Incorrect code can look professional. Weak analysis can sound authoritative. A false assumption can be presented confidently. A fluent translation can still alter the meaning.

The user therefore needs enough understanding of the objective to recognize when the output is unacceptable.

This does not mean the user must know every detail better than the AI. It means the user must know what evidence to require, what constraints matter, when specialist review is needed, and which decisions cannot simply be delegated back to the model.

If the user has no way to distinguish a correct answer from a convincing wrong one, the system is no longer being supervised. It is being trusted.

Those are not the same thing.

Better Feedback Produces Better Corrections

“Wrong” is feedback, but it is weak feedback.

A useful correction identifies the defect, points to the expected state, and limits the scope of the repair.

Instead of “fix the website,” a stronger instruction might identify the exact page, exact element, exact approved baseline, and the rule that nothing else may change.

Instead of repeatedly rewriting an entire document because one paragraph is weak, isolate the paragraph and explain what is missing.

The purpose is not to speak to AI in a special language. The purpose is to reduce ambiguity.

The Same AI Can Look Brilliant or Terrible Depending on Who Uses It

Imagine two people using exactly the same model.

The first gives a vague instruction, accepts the first response, keeps adding corrections without checking intermediate work, and builds on increasingly unstable output. Eventually the project fails. The conclusion is that the AI is useless.

The second defines the objective, supplies relevant context, states what must remain unchanged, divides the work into stages, verifies each stage, compares important output against evidence, and restarts when the interaction becomes confused.

The same model can appear dramatically more capable.

The difference may not be the intelligence of the model. It may be the quality of the workflow.

That is why AI evaluation should not separate the tool from the way the tool is operated.

Human Judgment Is the Final Redundancy Layer

Part One introduced a second AI as an independent review layer. Part Two added deliberate tool selection. But neither removes the need for a final acceptance authority.

AI can review AI. Automated tests can verify some outputs. Models can challenge each other. Specialists can inspect high-risk areas.

At some point, however, a human still has to decide whether the delivered result serves the intended purpose and whether the available evidence is sufficient to accept it.

That human decision is the final redundancy layer.

Working Effectively With AI Means Taking Responsibility for the Interaction

Sometimes the model really is the problem.

Models misunderstand instructions. They make unsupported claims. They alter things they were told to preserve. They can confidently produce incorrect results. Those failures are real, and users should not pretend otherwise.

But serious AI use requires a second question whenever something goes wrong: What could I have done differently?

Was the objective clear? Was the right context provided? Was the task too large? Did I verify the previous step? Did I keep patching a broken conversation instead of restarting? Did I accept an answer because it looked convincing? Did I delegate a decision that required my own judgment?

Sometimes the answer will still be: the model failed.

Sometimes it will not.

Learning to tell the difference is part of working effectively with AI.

The advantage will not belong only to the person with access to the most powerful model. It will also belong to the person who knows how to define the work, supervise it, verify it, and take responsibility for the quality of the interaction.

Because sometimes the AI really is the problem.

And sometimes, the user might be the problem.