Why the Best AI Users Don't Fix the Output Themselves
From ChatGPT to Claude Cowork to vibe coding, the new work skill is delegating to AI and owning the result. Setting goals, conditions and checks up front often beats editing the output.
"Left alone, AI wraps up an accounting close in no time. Let a human step in, and it can wreck the job."
That is a little irritating to hear. Does it mean we are dumber than the machine? No. Think of buying a self-driving sports car and then yanking the wheel because the passenger feels nervous. If nobody has settled who is driving, and when to step in, you lose both speed and safety.
A specific comparison that circulated, in which AI alone scored a perfect 20 while collaboration with accountants ran 15 times slower, could not be traced to the original study. The underlying concern is real, though. In Mercor's APEX-Accounting evaluation, which compared 12 junior CPAs with a top AI model, the AI performed better on clearly defined tasks within a limited scope. That is not an assessment of accountants as a whole, or of the full complexity of real-world practice.
In 2026, the top AI is no longer just a chatbot that answers questions. It is starting to work as an agent: reading material, making a plan, running tools and checking its own work. Claude models show strengths in long documents and coding, OpenAI models in reasoning and tool use, and Gemini models in multimodal material. None of this makes them "fully autonomous employees" that remember tens of thousands of pages or finish multi-day jobs without error. Context limits, file access, run time and verification ability vary by product, pricing plan and work environment.
The real change is not the model name. It is how people hand off work.
1. Three habits that make things worse when people step in
First: teaching the AI the order of thinking, step by step
In the past, answers improved when you broke tasks into small pieces: "Step 1 like this, step 2 like that." Steps that must be followed, such as calculation procedures or statutory processes, still need to be specified. But for work with many valid approaches, such as planning and analysis, imposing an arbitrary human thinking order can block a better path.
Often it is more useful to say "here is the final goal, here are the conditions that must hold, here are the checks it must pass" than "think in this order."
Second: rationing the source material
If there are 100 pages of original material and a person boils them down to 3, the AI has to reconstruct information that was already cut. Exception clauses in contracts, accounting footnotes and caveats in a competitor's presentation vanish along the way.
Where possible, supply the original, clearly sourced documents and explain each file's role. Dumping every large file in at once is not the answer either. Input limits can be exceeded and key details can get buried, so building a file list and index first and having the AI read relevant sources in stages is sometimes more accurate. For sensitive data, check access permissions first.
Third: editing intermediate output by hand
It is like a chef who is measuring ingredients and cooking, while someone beside them tastes and pours salt into every pot. When a person edits an Excel file or code that the AI is editing at the same time, version conflicts and consistency problems can arise.
Editing by hand is not itself a mistake. What matters is making clear who owns the edit, and re-verifying related formulas and tests afterward. Sentences and numbers that need human judgment can be changed freely. Just tell the AI what changed, so it does not mistake the edited file for the earlier state.
2. Stop wrestling with the output. Improve the work order.
This is where the way of working shifts. It moves from in-the-loop, where a person takes part in every step, to on-the-loop, where a person supervises the AI from outside and joins only at certain approval points. The bundle of rules, tools, tests and permissions that runs the work is often called a harness.
| Area | Approach that backfires | Better approach |
|---|---|---|
| Initial instructions | Coaching the order of thought and even sentence wording | Specify goal, scope, materials, prohibitions and completion criteria |
| Error handling | Repeating partial fixes: "change line 3 to 500" | Identify the cause and the rule that applies, then rerun the relevant part |
| Document review | Cross-checking hundreds of pages by feel, start to finish | Automate source checks, number verification and counterargument review; confirm the key points yourself |
| File work | Person and AI save the same file at the same time | Protect originals, write to separate output, split work logs from approval points |
| Vibe coding | Editing a few lines at random and guessing at the result | Fix based on specs, version control, automated tests and execution logs |
| Human role | Co-author of every intermediate step | Work designer, exception judge, final approver |
The point is not that people should review nothing. It is to redesign where human involvement creates the most value.
3. Putting it to work: a tool-by-tool manual
① ChatGPT and Claude on web and app: writing, research, planning
Start fresh instead of arguing endlessly. If you dislike a report the AI wrote and keep replying "no, not that," stale instructions and a bad draft tend to get mixed together. When a conversation gets tangled, use the option to edit your first request if the product offers one. Otherwise, open a new conversation and restate the goal and conditions cleanly. A new conversation is not always better. If important context has built up over a long time, summarize it and carry it over.
Hand the review to another AI for cross-checking. For example, paste a report written by Claude into ChatGPT and ask:
If two AIs trust the same bad source, both can be wrong. A good combination is AI cross-checking AI, with a person making the final check on sourced key claims and high-stakes conclusions.
② Claude Cowork: organizing files and documents on your computer
Isolate folders. Separate a materials folder holding the originals from a finished folder for new output. If you can distinguish read and write permissions, set the originals folder to read-only. Do not edit files the AI is working on, and have it save results under a different name. With any tool, first check the real file access scope and the execution approval settings.
Approve one, not 100 at once. Say: "Process just the first file and show me a sample result and a plan." After checking the sample, say: "Approved. Process the other 99 by the same standard, but stop and ask if you need to modify originals, send anything externally, or delete." You can have it skip error files and keep a list of exceptions. Whether the job actually runs to the end automatically depends on the run-time and approval policies of the tool you use.
③ Claude Code and Codex: building apps and websites without knowing how to code
Specs before source code. In Claude Code's CLAUDE.md, a separate SPEC.md, or the project instruction files used by Codex and similar tools, write the product goal, folder structure, coding rules, test commands and off-limits targets. Anthropic also describes CLAUDE.md as persistent project instructions. This does not mean "never edit the source code." If a developer changes code, tell the AI what changed and use version control to prevent conflicts.
Raw error logs, not guesses. When a login error appears, rather than asserting "I think the button variable is wrong," provide the error message, how to reproduce it, the expected behavior and the actual behavior. Remove API keys, personal data and access tokens before sharing.
Write automated tests first, then let the AI fix. "Define the success conditions for this feature, write automatable tests, then run them and fix the errors." This is close to TDD (test-driven development). But passing 100% of tests does not mean a "perfect product." A badly written test gives a green light to a broken program. Security, real user flows and accessibility need separate checks.
If three fixes fail, rethink the approach. If the same error repeats three times, consider returning to the last good commit rather than patching endlessly. Destructive commands such as git reset can erase uncommitted changes, so make a backup or a new branch first. Splitting the requirements into smaller units and trying again is usually better.
4. Three work orders you can copy and use
Swap only the bracketed parts for your own work. Instead of unrealistic commands such as "repeat forever" or "make it perfect," these include verification criteria and stop conditions.
Order ①: for office work, such as proposals, reports and data analysis
[needs verification]. Instead of abstract phrases like "innovative" or "diverse synergies," use numbers, evidence and action plans. Link each important claim to its source or link. [Self-verification] Before submitting, check yourself for logical leaps, numerical mismatches and missing counterarguments, and fix them. Do not hide items you could not verify; list them separately at the end of the final version. Submit three key points to confirm along with the main text.Order ②: for Claude Cowork, handling folders and bulk documents
[materials folder]. Do not modify or delete them. Save results as new files in [finished folder]. Keep a list of file names and whether each was processed successfully. [Step 1: sample approval] First process just one file in the [desired organizing or summarizing method], and show me a sample result and the overall processing plan. Do not process the remaining files until approval is given. [Step 2: batch processing] After approval, process the rest by the same standard. Do not fix ambiguous or corrupted files on your own; skip them and record them in exceptions_report.md. If you need to modify or delete originals, send anything externally, make payments or change permissions, get my approval again. [Completion criteria] Report a summary of the number processed, the number of successes and failures, the results folder and the main exceptions.Order ③: for vibe coding, autonomous coding and testing
[feature to implement]. [Plan] First, briefly present the files to change, dependencies, expected risks and the test method. Preserve existing working behavior and secure a recoverable state before changing anything. [Tests first] State the feature's completion conditions as testable sentences and write unit tests and any needed integration tests. Then implement the feature. [Autonomous fixing] Repeat test runs and error fixes at most [3 times]. Base each fix on the actual logs, and do not pass by deleting tests or weakening the verification criteria. If the same problem repeats, or if permissions, data deletion or security issues come up, stop immediately and report the cause and options. [Completion report] Submit separately the files changed, test results, unresolved risks and items you could not actually verify. Do not use the phrase "all perfect."5. The last piece: how will people earn a living?
First, human value shifts from hands-on labor to responsibility and judgment. Even if AI produces a draft financial statement in minutes, it does not automatically replace the accountant who is legally responsible or the company's final signature. A new premium may attach to the ability to leave verification evidence, judge exceptions, and explain to clients and regulators. That does not mean "just stamp it." A professional's signature carries a duty of real review.
Second, the AI roll-up is a strategy to change the whole way of working, not just to sell software. Investors buy existing accounting, legal or professional services firms, then embed AI inside the organization to automate repetitive work. The logic is that it is easier to change data, processes, training and pricing wholesale than to sell software to customers. In 2026, there have been cases of private equity firms seeking to raise company value around AI adoption, and AI-centered law firms are increasing.
However, the claim that operating margins "explode from the 10% range to 50-70%" is not a verified industry-wide figure. Once acquisition costs, regulation, liability for errors, customer acquisition costs and model fees are counted, profitability varies widely by company. It also helps to distinguish firms that merely cut costs with AI from firms that deliver more value to customers.
Third, individuals can work like a "one-person AI roll-up." No big acquisition is required. You can rebuild your own work as a small pipeline.
Set the goal → prepare originals and permissions → approve a sample → AI runs → automated verification → human review of key points → final approval.
The person here does not give up the work. They step away from repetitive tasks and spend time judging where a mistake would be fatal. The idea is to become someone who builds the structure that gets work done, rather than someone who types every keystroke from start to finish. That is probably where "doing the work of several people" in the AI era will come from.
What to track going forward
- Time to completion: Compare the time from first instruction to actual approval. Measuring only how fast the AI drafts exaggerates the benefit.
- Rework rate: Count the cases and hours a person had to fix after submission. If speed rises but rework grows, efficiency falls.
- Evidence-check rate: Confirm that important numbers and quotations link back to source material.
- Exception handling rate: See whether the AI reports what it does not know and stops at risky actions.
- Actual cost: Count subscription and API fees, review labor and error-correction costs together.
FAQ
Q. Is it wrong for a person to edit text the AI wrote?
- No. But when the AI uses the edited result again, make clear which version has changed.
- Take special care with simultaneous editing and version conflicts in shared files or code.
Q. If another AI reviews the work, is the fact-check done?
- No. Different models can cite the same wrong source.
- Check original sources separately for large numbers, legal matters, investment decisions and public statements.
Q. In vibe coding, is it fine to deploy once the tests pass?
- No. Also check test quality, user flows, privacy and security, and the real production environment.
- Put an approval step before hard-to-reverse actions such as deployment and data deletion.
Q. So should a person only step in at the start and the end?
- That may work for low-risk batch organizing tasks.
- Complex accounting judgments, external sends, fund transfers and sensitive data need mid-process approval and expert review.
Q. Can a "one-person AI company" really do the work of 100 people?
- A 100x productivity gain is not a universally proven figure. It is closer to a metaphor.
- A good start is to pick one task you repeat and compare time, errors and cost before and after.
Insight Times Editorial Desk
