An LLM Can Get You to 50% Fast. Reaching 100% Is the Real Work

The first result arrives in minutes. The code has sensible names. The article has headings. The analysis has a confident recommendation. The diagram looks complete.

Then the real work begins.

The code handles the happy path but not retries. The article repeats an unsupported claim. The analysis assumes access to data that nobody has. The diagram connects two systems in the wrong direction. What looked 90% complete was closer to a convincing sketch.

An LLM often makes the first half of a goal feel easy because it can produce structure, language, and familiar patterns quickly. The second half is harder because completion depends on context, judgment, verification, integration, and accountability. Better results come from defining “done” before generation, working in verifiable slices, exposing assumptions, and requiring evidence at every quality gate.

The 50% split in this article is a metaphor, not a universal productivity measurement. Some well-defined tasks can be almost completely automated; others become slower when review and correction exceed the saved creation time. “100%” does not mean eternal perfection. It means the result meets the acceptance standard agreed for this task.

Current evaluation guidance points in the same practical direction. OpenAI recommends task-specific evaluation, continuous testing, detailed logs, and human calibration instead of “vibe-based” approval. Anthropic describes evaluator-optimizer loops as useful when the criteria are clear and improvement can be measured. Its agent-evaluation guidance also treats concision, file discipline, and over-engineering as behaviors worth testing—not cosmetic preferences. OpenAI evaluation best practices; Anthropic agent evaluation guidance; Anthropic agent workflow patterns.

Why the first half feels so fast

LLMs are strong at producing things that resemble familiar examples:

• a reasonable outline from a short brief;
• boilerplate code and common transformations;
• a plausible explanation of a known topic;
• test cases for an obvious happy path;
• a first-pass diagram from written steps;
• several options when the search space is broad.

These outputs create visible progress. A blank page becomes a structured artifact, and that change feels large. It often is valuable: the model has reduced startup cost and given the human something concrete to inspect.

But visible completeness and actual completeness are different measures.

flowchart LR
    accTitle: From a goal to a dependable result with an LLM
    accDescr: A goal and prompt quickly produce a plausible first draft. Reaching an accepted result requires context, explicit decisions, edge cases, integration, verification, and human accountability.

    goal["Goal"] --> context["Prompt and available context"]
    context --> draft["Plausible first draft"]

    subgraph first_half["Fast, visible progress"]
        draft
    end

    draft --> decisions["Resolve ambiguous decisions"]
    decisions --> edges["Handle boundaries and failures"]
    edges --> integrate["Fit the real environment"]
    integrate --> verify["Test claims and behavior"]
    verify --> owner["Human accepts responsibility"]
    owner --> result["Accepted result"]

    subgraph second_half["Slower, evidence-driven progress"]
        decisions
        edges
        integrate
        verify
        owner
    end

The first draft benefits from statistical familiarity. The finished result depends on local truth: your users, system, policy, data, constraints, and definition of acceptable risk. The model may not know those facts unless you provide them, and it cannot take responsibility for decisions you never made.

The last 50% is not polishing

Treating the remaining work as cosmetic cleanup leads to weak results. The last mile often contains the parts that determine whether the artifact is useful at all.

An output can be grammatically correct, syntactically valid, and still be wrong for the job. This is why asking the model to “make it production ready” rarely closes the gap. The phrase does not supply the missing definition of production, the actual system evidence, or permission to make business decisions.

Define 100% before asking for output

The most effective improvement is also the simplest: write the acceptance conditions before generating the artifact.

For a small task, answer five questions:

1. Outcome: What should become possible when this is finished?
2. Boundary: What is included, and what is explicitly excluded?
3. Constraints: Which rules, interfaces, sources, formats, and policies must be respected?
4. Evidence: What test or observation will demonstrate success?
5. Owner: Who can accept the result and its remaining risk?

Compare these two requests:

Write a webhook receiver for order updates.

Implement the order-update webhook described in SPEC-12.

Done means:
- requests with a valid signature are accepted;
- invalid or missing signatures are rejected;
- replayed event IDs do not apply an update twice;
- an unknown order returns the specified response without creating data;
- logs contain the event ID but no customer payload;
- unit and integration tests cover each rule;
- no unrelated files change.

Before editing, identify missing information and cite the files that establish
the current routing, storage, and logging conventions.

The second prompt does not guarantee success. It makes success inspectable. It also gives the model permission to stop and identify a missing decision instead of inventing one.

For a fuller way to connect intent, requirements, design, and proof, use the specification-driven design guide.

Use a seven-gate workflow

1. Ground the task in source material

Give the model the smallest authoritative context that can support the task. That might include an accepted specification, relevant code, a schema, a policy, a source article, or a recorded decision.

Label the status of each input:

• authoritative: use as the current rule;
• example: imitate its form, not necessarily its facts;
• proposal: evaluate rather than assume;
• outdated: use only to understand history;
• unknown: ask before deciding.

More context is not automatically better. A large uncurated dump can hide the rule that matters or mix current and obsolete material. Curate evidence before optimizing the prompt.

2. Ask for assumptions and questions first

Before generation, ask the model to separate:

• facts directly supported by the supplied material;
• reasonable but unconfirmed assumptions;
• missing information that could change the result;
• decisions that require an accountable owner.

This step makes uncertainty visible while correction is cheap. Do not reward the model for filling every blank. A clearly stated unknown is more useful than a plausible invention.

3. Work in the smallest verifiable slice

Large one-shot requests combine too many failure modes. Divide work by observable behavior rather than by arbitrary file count or document length.

For the webhook example, useful slices are:

1. route and validate one documented event;
2. verify signatures and rejection behavior;
3. make processing idempotent;
4. add failure-safe logging;
5. exercise the complete flow with an integration test.

Finish the evidence for one slice before expanding the next. This limits rework and makes it easier to identify which assumption caused a failure.

4. Require artifacts, not reassurance

“Done,” “tested,” and “looks correct” are summaries. Ask for inspectable evidence:

• exact files or records used as sources;
• changed files and a concise diff summary;
• commands run and their exit results;
• test cases tied to acceptance criteria;
• unresolved questions and residual risk;
• links or citations for externally verifiable claims.

The evidence should be reproducible by someone other than the model. A statement that tests pass is weaker than the recorded command and output. A citation is useful only if the linked source actually supports the nearby claim.

5. Review semantics, not only form

Linters, parsers, type checkers, and grammar tools catch important defects. They do not prove meaning.

A Mermaid diagram can render with a reversed arrow. A query can run against the wrong population. A test can pass while asserting the implementation's mistake. A fluent article can misrepresent its source.

Run two separate reviews:

1. Form review: Does it parse, build, render, and follow the required format?
2. Meaning review: Does each important claim, relationship, behavior, and conclusion match the accepted evidence?

The AI-generated architecture diagram review demonstrates this distinction with Mermaid: syntax validation and factual validation answer different questions.

6. Attack the happy path

Once the main path works, deliberately look for conditions the first draft probably missed:

• empty, missing, maximum, and malformed inputs;
• permission differences and information exposure;
• retries, duplicates, ordering, and concurrency;
• partial failure and recovery;
• stale data and incompatible versions;
• cancellation, rollback, and irreversible actions;
• mobile, keyboard, localization, and accessibility behavior;
• disagreement between two authoritative sources.

Ask the model to propose edge cases, but let the specification and domain owner decide which ones matter. Generated risk lists can be a useful search aid; they are not proof that the review is complete.

7. Close with an independent acceptance pass

The same context that produced an error can also make a self-review overlook it. Use a fresh pass with a different role and a narrow question:

Review this result against acceptance criteria AC-01 through AC-08.

For each criterion, return:
- pass, fail, or not proven;
- the exact evidence;
- any conflicting evidence;
- the smallest next action.

Do not rewrite the result and do not infer a pass from appearance.

For consequential work, independent means more than a second prompt. It can mean a different person, a separate test system, a primary source, a security review, or observation in the real delivery environment.

Use different models as roles, not as a vote for truth

A second model can be useful because it enters with a fresh context and may have different strengths. It is not automatically independent, correct, or more skeptical. Give each model a distinct job:

Different models are most valuable when the review perspectives are intentionally different. Asking three models “Is this good?” often produces three polished opinions. Asking one to trace requirements, another to challenge failure behavior, and a third to find unsupported additions produces findings you can compare.

Use this review protocol:

1. Freeze the rubric before showing reviewers the candidate.
2. Hide the generator's identity and self-justification where practical.
3. Give each reviewer the original requirements, accepted sources, candidate, and one review dimension.
4. Require evidence for every finding and allow “not proven.”
5. For pairwise comparison, reverse candidate order and investigate a changed verdict.
6. Send model disagreement, high-impact failures, and policy decisions to a human.
7. Periodically compare model verdicts with a small set of human-reviewed examples.

This caution matters because research has found that LLM judges can change preferences when candidate order changes, and separate work has measured self-preference in model judgments. A different model family may diversify the review, but model plurality is not a substitute for evidence or human calibration. Position-bias study in IJCNLP 2025; self-preference study in EMNLP 2025.

Choose generator and reviewer models using the same representative task set. Do not assume the most expensive model is required for every role. A fast model may be sufficient for schema checks or clear classification, while ambiguous design and final review may justify a stronger model. OpenAI's current model-selection guidance recommends comparing the same inputs and keeping the lightest setting that meets the required quality bar.

flowchart LR
    accTitle: Multi-model review with human acceptance
    accDescr: A frozen specification guides a generator model. Deterministic checks run first, then separate model reviewers inspect requirements, risk, and bloat. Disagreement or high-impact findings go to a human owner before acceptance.

    spec["Frozen criteria and evidence"] --> generator["Generator model"]
    generator --> candidate["Candidate artifact"]
    candidate --> checks{"Deterministic checks"}
    checks -->|Fail| repair["Bounded correction"]
    repair --> candidate
    checks -->|Pass| requirement["Requirement reviewer"]
    checks -->|Pass| risk["Risk reviewer"]
    checks -->|Pass| bloat["Bloat reviewer"]
    requirement --> reconcile["Compare evidence and findings"]
    risk --> reconcile
    bloat --> reconcile
    reconcile --> decision{"Disagreement or high impact?"}
    decision -->|Yes| human["Human domain owner"]
    decision -->|No| human
    human -->|Revise| repair
    human -->|Accept| done["Accepted result"]

Keep a completion ledger

Long tasks fail when “almost done” replaces an exact record. Track the work outside the conversation in a small ledger that survives context resets, model changes, and handoffs.

Use a small controlled status set:

• Not started: no candidate exists.
• Candidate: work exists but has not passed its checks.
• Failed: evidence contradicts the criterion.
• Not proven: evidence is missing or inconclusive.
• Blocked: progress requires a decision, access, or external change.
• Verified: the named check passed for the recorded candidate.
• Human accepted: the accountable owner accepted the complete evidence and residual risk.

Never promote “candidate” to “verified” because the model says it finished. Record the model and version for reproducibility, but do not treat the model name as evidence. Link the exact artifact or revision so a later change cannot inherit stale verification.

Download the LLM task-completion review ledger. It includes the example rows and blanks for a real task.

Anthropic's long-running agent harness used a structured feature list, progress notes, version history, one-feature-at-a-time work, and end-to-end checks to counter premature declarations of completion. The implementation was specific to a coding experiment, but the operating principle generalizes: preserve state in an inspectable artifact, not only in the model's conversational memory.

Review in a fixed order—and keep going

Review fatigue creates a predictable failure: the first serious defect gets fixed, the artifact looks much better, and everyone stops. Prevent that by fixing the review sequence before work begins.

1. Coverage: Is every requirement represented?
2. Correctness: Does the behavior or claim match authoritative evidence?
3. Boundaries: Are failure, permission, retry, and recovery cases handled?
4. Integration: Does it work in the real environment without unrelated damage?
5. Economy: Can anything be removed without losing a requirement or necessary evidence?
6. Acceptance: Has the accountable human reviewed open risk and approved the exact candidate?

Complete every pass even if an earlier pass finds defects. Log the findings, correct a bounded set, then rerun the affected checks and a small regression set. Review both the latest diff and the complete artifact: the diff reveals what changed, while the whole exposes contradictions introduced across iterations.

Keep the discipline exact:

• do not weaken a requirement or edit a failing test merely to obtain a pass;
• version a legitimate requirement change and record who approved it;
• keep “not proven” open rather than translating it to “probably fine”;
• reopen evidence when its artifact, input data, model, or environment changes materially;
• stop after a predefined number of failed correction cycles and escalate the underlying decision;
• retain rejected findings with their disposition so they do not reappear as unresolved folklore.

OpenAI's evaluation guidance recommends scoped tests, continuous evaluation, development logs, and calibration of automated scoring with human feedback. Anthropic's evaluation guidance similarly advises reading evaluation transcripts because a reported failure may be an agent defect or a faulty grader. The point is not to create ceremony; it is to keep the review mechanism itself under review.

Turn correction into a controlled loop

An effective LLM workflow is not “prompt until it looks right.” Each iteration should reduce a named gap and produce new evidence.

flowchart TD
    accTitle: Evidence-driven loop for finishing LLM-assisted work
    accDescr: Acceptance criteria guide a small task slice. The model produces a candidate, automated checks review its form, and human or source-based review checks meaning. Failures become one bounded correction, while passing evidence leads to acceptance.

    criteria["Acceptance criteria"] --> slice["Choose one verifiable slice"]
    slice --> candidate["Generate or revise candidate"]
    candidate --> form{"Form checks pass?"}
    form -->|No| correction["Name one failure and correct it"]
    form -->|Yes| meaning{"Meaning matches evidence?"}
    meaning -->|No| correction
    correction --> candidate
    meaning -->|Yes| integration["Check integration and side effects"]
    integration --> final{"Acceptance evidence complete?"}
    final -->|No| slice
    final -->|Yes| accept["Owner accepts result and residual risk"]

Avoid the loop where a vague criticism produces a full rewrite, which introduces new errors and makes comparison difficult. Prefer bounded instructions such as:

AC-04 is not proven because the duplicate-event test checks sequential retries only. Add one concurrent duplicate case without changing the public interface.

That correction has a target, a reason, and a stable boundary.

Finish with a de-bloating pass

Iteration tends to accumulate material. A model adds an abstraction to fix one case, more prose to explain a weak claim, or another configuration layer “for flexibility.” Later reviewers see a polished whole and hesitate to remove anything.

Bloat is not just word count. It includes:

• code paths, dependencies, configuration, or public interfaces that no requirement needs;
• repeated explanations that make the important qualification harder to find;
• speculative extensibility for users or cases outside the agreed scope;
• tests that duplicate implementation details without protecting behavior;
• comments that restate the code instead of explaining a decision;
• diagrams, headings, tables, or examples that do not help the intended reader decide or act.

Set an economy budget before generation where possible: allowed files, new dependencies, public interfaces, document length, diagram count, or migration scope. These are guardrails, not goals to game.

Then run a separate removal review. The reviewer must not redesign the artifact or add features. For each proposed deletion, it should answer:

Use a constrained prompt:

Perform a deletion-only review against AC-01 through AC-08.

Identify additions that do not contribute to a criterion, necessary evidence,
operability, or reader understanding. For each candidate, cite its location,
why it is unnecessary, what may break if removed, and the verification needed.

Do not rewrite, add features, or prefer brevity over correctness. Return
"nothing safely removable" when the evidence does not support a deletion.

Apply approved removals, then rerun the same acceptance checks. A smaller result is better only when it preserves the required behavior and evidence. Anthropic reports evaluating agent behavior for both concision and over-engineering; treating economy as an explicit quality dimension makes it reviewable instead of leaving it to taste.

Keep the human in the high-value part of the work

“Human in the loop” is too vague if nobody knows what the person must decide. Assign the human to the parts that require authority or judgment:

• choosing the outcome and acceptable trade-offs;
• confirming source quality and current policy;
• deciding what risk is acceptable;
• resolving conflicts between requirements;
• judging whether the result serves the intended audience;
• approving release, publication, or an external promise.

The human review should be an inspection, not a ceremonial approval. The reviewer should read the original criteria before the model's summary, open the evidence for failed and high-risk cases, inspect disagreements between reviewers, and exercise the result in its delivery environment where practical. They should record one of three outcomes: accept, reject with named gaps, or accept with explicit residual risk.

Model-written critiques can help a person search for flaws, but the human remains responsible for deciding whether a finding matters in context. Use expert attention where the consequence is largest: changed permissions, irreversible data operations, public claims, legal or policy interpretation, security boundaries, and promises to customers.

Let the LLM handle transformations where correctness can be checked cheaply: structuring notes, drafting test cases, applying repetitive changes, comparing two explicit inputs, or formatting a traceability table.

This division is more reliable than treating the model as either an infallible expert or a fancy autocomplete. It is a fast collaborator whose work still needs an acceptance system.

Measure the whole path, not time to first draft

If you measure only generation time, the LLM will appear to finish at the moment the difficult work begins.

Track at least:

• time to first usable candidate;
• human time spent framing and supplying context;
• review and testing effort;
• rework after rejection;
• elapsed time to acceptance;
• defects or factual corrections found later;
• whether the accepted result created the intended outcome.

The AI-assisted engineering effort guide provides a practical measurement model. It separates creation from review and rework so that a faster draft is not mistaken for a cheaper or better result.

Know when to stop prompting

More iterations do not always create more confidence. Stop and change the approach when:

• the model lacks an authoritative source needed for the answer;
• repeated corrections reintroduce previously fixed errors;
• the task requires access or tools the model does not have;
• reviewers disagree about the requirement rather than the output;
• the consequence of a wrong answer exceeds the available verification;
• a small manual solution is now cheaper than supervising another rewrite.

At that point, obtain the missing evidence, make the unresolved decision, narrow the task, or hand the work to the relevant specialist. Escalation is part of a successful workflow, not evidence that the tool failed.

A reusable prompt for better completion

Use this structure for software, analysis, documentation, or planning work:

GOAL
[Describe the outcome, not only the artifact.]

AUTHORITATIVE INPUTS
[List the files, records, policies, or sources that establish facts.]

SCOPE
Included: [...]
Excluded: [...]

ACCEPTANCE CRITERIA
AC-01: [...]
AC-02: [...]
AC-03: [...]

CONSTRAINTS
[Format, compatibility, security, privacy, style, or change limits.]

WORKING RULES
1. Separate supported facts, assumptions, and open questions.
2. Do not invent missing requirements or evidence.
3. Work on the smallest verifiable slice first.
4. Preserve unrelated content and behavior.
5. Report checks actually run and their results.
6. Mark every acceptance criterion pass, fail, or not proven.
7. Update the completion ledger after each bounded change.
8. Do not change criteria or tests without an approved requirement change.
9. Finish with a deletion-only review and rerun affected checks.

DELIVERABLE
[Name the artifact, evidence, ledger update, residual risk, and concise handoff.]

The template is not magic. Its value is that it changes the conversation from “produce something impressive” to “satisfy this inspectable agreement.”

The last-mile checklist

Before calling LLM-assisted work complete, ask:

• Is the desired outcome stated in observable terms?
• Are scope and non-goals explicit?
• Are authoritative inputs separated from examples and assumptions?
• Does the completion ledger point to the exact candidate under review?
• Does every mandatory requirement have evidence?
• Have boundary, failure, retry, permission, and recovery cases been considered?
• Did the result pass both form and meaning reviews?
• Were model-review findings calibrated or resolved by a human where needed?
• Was it checked in the real integration or publishing environment?
• Did a deletion-only pass remove unsupported additions without weakening the result?
• Are unresolved risks visible and owned?
• Can another person reproduce the important checks?
• Has an accountable person accepted the result?

If several answers are “no,” the work is not in its final 10%. It is still a draft, however polished it looks.

Use the speed without inheriting the illusion

The right lesson is not that LLMs only do half the work. Their leverage can be much larger or smaller depending on the task. The useful lesson is that speed to plausible output and speed to accepted outcome are different things.

Use the model aggressively for momentum: explore, structure, transform, draft, and propose. Then switch modes. Narrow the task, check the sources, test the behavior, inspect the edges, verify the integration, and put a named person behind the final decision.

That is how an impressive first 50% becomes a dependable result.

Research references

• Evaluation best practices — OpenAI: task-specific evals, continuous evaluation, logging, human calibration, and limitations of model graders.
• Model selection — OpenAI: comparing models and reasoning settings on representative tasks while balancing quality, latency, and cost.
• Building effective agents — Anthropic: prompt chaining, routing, parallel review, evaluator-optimizer loops, environmental feedback, and stopping conditions.
• Demystifying evals for AI agents — Anthropic: mixed grader types, transcript review, human calibration, regression testing, concision, and over-engineering checks.
• Effective harnesses for long-running agents — Anthropic: feature lists, progress records, incremental work, version history, and end-to-end verification across sessions.
• Harness design for long-running application development — Anthropic: planner, generator, and evaluator roles; structured handoffs; review contracts; and limits of self-evaluation.
• Judging the Judges: A Systematic Study of Position Bias in LLM-as-a-Judge — IJCNLP 2025: evidence that candidate order can influence model-based evaluation.
• Beyond the Surface: Measuring Self-Preference in LLM Judgments — EMNLP 2025: measurement of model self-preference and factors that affect it.