I Barely Give AI Detailed Instructions. “Win More” and “Do Less Work” Somehow Turned Into an Automated Verification System

Looking back at how I use AI, I noticed something odd: I almost never give it a detailed procedure.

TL;DR

Looking back at how I use AI, I noticed something odd: I almost never give it a detailed procedure.

My instructions are usually closer to “I want to win,” “reduce my workload,” “don’t stop halfway,” and “verify that it actually worked.”

That is not exactly a 200-page requirements document.

But if the system really has to satisfy those goals, the AI starts decomposing the problem on its own: define success, create acceptance criteria, decide how to verify the result, and add guardrails where failures happen.

The workflow gradually becomes less “a human checks every output” and more AI builds it, AI checks it, external evidence confirms it, and only exceptions get reported to the human.

When I read OpenAI’s 2026 description of Harness Engineering, the pattern was surprisingly similar.

Humans steer. Agents execute.

This works beautifully in personal projects. Inside a company, though, politics arrives with a chair and a meeting invite.

A personal project is a zero-politics dictatorship.

Bring the same idea into a company and parliament opens immediately.


The starting point is only two goals: win more and do less work

The top-level objectives are almost embarrassingly simple.

For a card game: win more.

For automation: reduce human effort.

A simulator can become technically elaborate, run thousands of matches, add search algorithms, and generate sophisticated analysis.

The final question is still: did the win rate improve?

An article pipeline can add localization, QA, queues, hashes, retries, and deployment checks.

The final question is still: did the amount of human work go down?

The implementation can get complicated without making the objective complicated.

That is exactly why the implementation can be delegated so aggressively.


I do not specify every step. I ask AI to derive the target state

Humans do not need to invent every acceptance criterion from scratch.

A goal such as “take the newest article all the way to a correct live deployment without manual intervention” is already enough to generate useful questions:

  • What counts as the newest version?
  • What does “correct” mean?
  • Does each translation still correspond to the current source text?
  • Is one successful item enough to declare a 50-item batch complete?
  • Does a Git commit count as published?
  • Should the live site itself be checked?

The human can hold the goal and invariants, while AI expands them into detailed checks.

Of course, AI can also invent bad criteria.

That is why the next layer matters.


I use AI heavily, but “the AI said it finished” is not evidence

From the outside, this can look like reckless delegation.

The work goes to AI.

The verification also goes to AI.

Ideally, the human does not even read the logs.

The desired workflow is:

Do the work → run checks automatically → report “all good” briefly → if something is wrong, report the cause and proposed fix.

The important part is that the agent’s own claim is not the completion criterion.

Instead of “done,” look for observable evidence: item counts, test results, hashes, actual files in the repository, real URLs, or the HTML served by the live site.

Asking the same model in the same context to “check your own work” can repeat the same misunderstanding twice.

A stronger design separates generation, verification, and external evidence.

The human does not need to inspect everything.

But “trust me, I checked” is not enough either.

In plain language:

“I don’t want to look at it. You check it. Bring receipts.”


Every stumbling block is a place where human labor still survives

If the real goal is to reduce work, tiny manual steps become impossible to ignore.

Click this button every time.

Handle this one exception manually.

Read the logs when it fails.

Check the production site after deployment.

Most workflows eventually say, “Fine, that part can stay manual.”

But if the objective is less human work, that manual island is simply unfinished design.

If a workflow requires a human to try hard every time, the workflow is not finished yet.

A failure then stops being only an incident.

It becomes information about where automation still ends.

If a batch stops after one item, the fix is not merely “run the other 49.”

The better question is: why was one item allowed to count as a successful completion?

If an old translation is accepted as current, fixing that one translation is not enough.

The system should be changed so stale translations cannot pass as current next time.

Each failure can become a new rule, test, or guardrail.

That is how human work gradually disappears.


A manager who says “I don’t understand” is still better than a review process that rewrites reality

A Zenn article published in August 2026 described an AI-enabled team whose output became difficult for management to review as the team’s way of working changed faster than shared understanding.

One symbolic response was essentially: “I don’t fully understand it yet, but I think what you are saying is correct.”

That is weak as a review.

But there is a more dangerous failure mode.

A reviewer does not understand, then protects authority by changing facts or criteria after the result appears.

No clear standard exists beforehand, then after delivery comes “obviously you should have done it this way.”

Ask for guidance and hear “think for yourself.” Think for yourself and hear “don’t act without permission.”

At that point, improvement becomes impossible because the definition of correct keeps moving.

A manager who can admit “I cannot review this properly yet” is still repairable. Bring in specialist review, automate checks, require explicit evidence and unresolved questions.

Missing expertise can be supplemented.

Moving criteria break the quality-assurance mechanism itself.


Why ritualized QC felt so bad

The original idea of QC Circles is continuous improvement by small groups of frontline employees.

The Union of Japanese Scientists and Engineers (JUSE) describes QC Circles as groups that continuously control and improve the quality of their work, products, and services.

The problem is not QC itself.

The problem begins when the organization optimizes for looking like it did QC instead of actually improving the work.

Pick a theme.

Make charts.

Force the story into the official format.

Build the slide deck.

Present it.

Get judged.

Applause.

Done.

That is no longer continuous improvement. It is continuous-improvement cosplay.

The agent workflow is uglier but more honest:

Something fails.

Find the cause.

Identify how it can recur.

Change the completion rule or verification step.

Run it again.

Confirm the same failure can no longer pass as success.

No ceremony required.

But the next run needs less human labor.

Ironically, that is much closer to the original spirit of continuous improvement.


Then I discovered OpenAI’s Harness Engineering

In February 2026, OpenAI published “Harness engineering: leveraging Codex in an agent-first world.”

The team described building an internal product under a constraint of zero manually written lines of code and estimated that it took roughly one-tenth the time of writing the code by hand.

The more important point was not the speed number.

OpenAI said the engineering role shifted away from primarily writing code and toward designing environments, specifying intent, and building feedback loops that let agents work reliably.

It also described a model where important boundaries, correctness, and reproducibility are enforced centrally while agents retain freedom inside those boundaries.

That is very close to this style of working.

Do not micromanage the implementation.

Do define what must never be violated.

When a failure repeats, promote the lesson into documentation, tests, lint rules, or tooling.

You can arrive at this philosophy without starting from a philosophy.

Sometimes you just start from “I really do not want to inspect this manually again” and accidentally climb the same mountain.


Personal projects are zero-politics dictatorships. Companies open parliament

This model works beautifully on personal projects because the decision structure is absurdly clean.

Owner: me.

User: me.

Evaluator: me.

Definition of success: also me.

For a card game, ask whether it helps me win.

For automation, ask whether it reduces my intervention.

Everything collapses back into two questions:

Does it help me win?

Does it reduce my work?

A personal project is a zero-politics dictatorship.

The dictator happens to be lazy, so the AI bureaucracy keeps automating things.

Companies are different because objectives multiply.

Reduce labor, but do not change the operator’s workflow too much. Pass audits. Keep approval authority. Do not break the legacy system. Make accountability clear. Decide who gets credit if it works. Sometimes even ask what happens to the team if the task disappears.

Harvard Business Review argued in 2025 that many barriers to AI adoption are not technical at all, but problems of people, processes, and politics.

That is the real difference.

In a personal project, you decide the target state and let AI optimize toward it.

In a company, deciding the target state is itself a negotiation.

Not all of that politics is stupid. Human approval can be rational when accountability, safety, or auditability matters. But sometimes approval survives simply because somebody does not want to lose authority.

To an AI system, both cases look like the same requirement: “human approval required.”

Whether that requirement is genuinely necessary is still a human social question.


Final thought: maybe humans only need to hold the goal and reality

AI is reducing the need for humans to design every step, implement every step, and inspect every output personally.

Define the objective.

Let AI derive a target state and criteria.

Let AI implement it.

Let AI run verification.

Check against external evidence.

Turn failures into permanent rules.

Whenever human work remains, treat it as the next optimization target.

In that loop, humans need far less knowledge of every implementation detail.

But two things are still hard to delegate completely:

What are we actually trying to achieve?

Does that goal still match reality?

So the division of labor may keep moving toward this:

Human: choose the goal and look at reality.

AI: fill in everything between them.

For a personal project, that can feel wonderful.

Inside a company, parliament is still in session.

Politics remains undefeated.

Mendoi-chan

Written by

Mendoi-chan

She turns friction at work and in everyday life into clear structure and practical next steps.

About