Process and results

How AI Work on Real Tasks Is Structured

Every meaningful step is first written down along with the reason it was chosen, then independently checked — before it turns into code, a build, or a promise to a client. Below are concrete cases: what the situation was, what was done, and what came out of it.

How the pieces of this approach connect — from a task to a result.

flowchart TD
    TZ["Task
(original wording — not edited;
a new version = a new file)"] --> Q["Question
(what's unclear and what the answer changes)"] Q -->|investigates| S["Findings
(answer to the question)"] Q -->|resolves| D["Decision
(proposed →
accepted only by a human)"] Q -->|tests in practice| E["Experiment
(success/failure criterion
set BEFORE, not after)"] S -.->|"fact useful
beyond this task"| K["Knowledge
(one topic — one file)"] D -.->|"fact useful
beyond this task"| K E -.->|"fact useful
beyond this task"| K S -->|"external source"| IST["Source
(original — not edited)"] S --> D E --> D D -->|"final text/code"| ART["Result
(what was produced, announced in advance)"] CRIT(["independent review"]) -.->|"required before handoff"| TZ CRIT -.->|"required before handoff"| D

Catching an error while it's still cheap

The fastest and most common cases — minutes between the moment an error appears and the moment it's found and fixed, before a human ever sees the decision.

Telegram bot architecture

An unverified name in the options evaluation

The decision text explicitly stated that no unverified model name would make it into the final evaluation. In practice, one cell of the options table contained a specific name that no one had checked.

BeforeThe claim about data cleanliness didn't match the content of that same table.
AfterThe mismatch was found, the numbers were recalculated from scratch (32 and 14 turned into 65 and 68 — exactly what the independent check produced), and the choice of option itself didn't change.

Time between the decision landing on the table and the mismatch being found and closed: 15 min.

Third-party repository audit

An error caught twice in a row — the second one was new

The first count of undocumented projects turned out to be wrong. While fixing it, a different, new error crept in — in the exact spot that had just been corrected.

BeforeThe first check returned a number that didn't match the actual count.
AfterThe fix was applied, but it brought a new inaccuracy along with it; a second check caught exactly that, 13 min after the first, and within a few minutes everything was corrected and stated plainly: "after the definition changed, the derived number wasn't recalculated."

When a fabrication is found — the rule gets fixed, not hidden

Sometimes the check catches not arithmetic but substance: a claim that was never actually in the source.

Quote verification for a geo-promotion article

A fabricated quote — and a rule that stopped recurring after it

Of three quotes presented as verbatim, one turned out to be entirely invented: it mentioned Russia, yet the word "Russia" never appeared on the source page — confirmed by a direct full-text search. Two more turned out to be paraphrases presented as quotes, with no quotation marks in the original.

BeforeVerbatim accuracy wasn't checked character by character — "sounds like a quote" was taken for "is a quote."
AfterThe rule "verbatim means verbatim, character by character" was added to the working instructions within minutes. On the next run of the same task, all five quotes became exactly verbatim, and one claim that had previously been presented as direct was reclassified by the system itself as "confirmed indirectly," with the exact method of verification noted.

Stabilizing a build: three passes in one day

An automated build targeting several platforms at once is its own source of surprises, resolved by repeating the same cycle: try, find the cause, fix.

Board-game build for three platforms

From an unnoticed failure to three green platforms, then five

BeforeThe first build pass ran, but its outcome wasn't checked.
AfterThe second pass found the exact cause of the failure (the build tool wasn't recognizing the repository) and fixed it — all three platforms went green. The third pass added one more operating system and again came back green, with exact timing per platform (just over a minute on one, close to two minutes on another, close to three and a half on the third).

Three passes in one day — and the build has stayed stable across all platforms ever since.


From an empty folder to a game you can install on your phone

The longest and most eventful path — board games bundled into a single mobile app. From the first folder created to a publicly downloadable build, the same cycle played out: a decision written down, an independent check, a fix, the result recorded — just repeated many times over on the same task as it grew.

4h10min from an empty folder to the first live, confirmed run: the game opened, a move registered, the opponent's reply came back, no rendering errors
5 board games in one mobile app — gomoku, dots, go, reversi, pyramid — with 3D rendering
618+ automated checks green before the build was published

A build is more than just "a green check in CI"

The Android build is published and downloadable via a direct link. Before considering it ready, the build file was unpacked by hand to confirm the exact fix the build existed for (correct handling of on-screen touches) was actually inside — not just trusting the green check, but looking at the contents. Each of the five games was run live before publication, in both color themes, through every input method — touch, mouse wheel, right-click, keyboard shortcuts, two-finger gestures.

Specific issues found before a player ever saw them

The check itself slips up sometimes too — and that's stated plainly as well

A multi-stage automated build once stalled on the last step, which looked like an infrastructure failure. On closer inspection, the cause wasn't infrastructure at all, but how the task itself had been worded at the previous step — recorded plainly as a wording error, not someone else's failure. Another time, a verification step took a previous step's own claim at face value ("no database connection") instead of checking it independently; a manual review found the real cause (a missing authorization header and a request to a model that didn't exist) — and that, too, was stated outright: "the claim was inaccurate and wasn't re-checked," with no softening.

The same habit holds even where it wasn't formally required

Content generation for the game picked and switched the language model and prompt wording directly, bypassing the usual step-by-step breakdown — but even here, the model choice was recorded along with the reason, not made silently. When the very first real run caught an actual flaw in the prompt wording (fields had been swapped, and the translation rate came out at 1 of 17 instead of the expected roughly 7 of 11), the fix brought the result up to 14 of 16 — above the original target — and the difference was stated plainly in its own words: "the model translates more readily than expected," not written off as an error.


What people running AI-driven projects get out of this

Three concrete improvements, each grown out of a real case, not general reasoning.

It's visible who actually made the decision — a human or the AI itself

When a human steps back into work already in progress with a new instruction mid-stream, that instruction is now recorded in their own words at the moment it's given — not reconstructed afterward from whatever the outcome happened to be. For the same reason this matters to larger teams: in surveys of engineering and portfolio leaders, the ability to tell AI work apart from human work remains out of reach for more than half of teams without a mature practice around AI agents — and improves sharply for those who already have one.

Review happens before a decision moves forward, not after

A decision about a time limit for an AI opponent in one of the games was made unilaterally in conversation, skipping the usual check — it turned out to be incomplete and cost roughly an hour of wasted compute time. The same gap later turned up in three decisions about the workflow itself, which had been written and applied directly in conversation, bypassing the very check they described; once they were actually run through a proper review, all three needed rework, one of them with a flaw that would have made the mechanism unworkable for nearly everyone it was meant for. Now any description of a new workflow or set of instructions goes through review before it's put into use, not after.

A finding doesn't stay buried inside a single task

During two parallel tasks, a whole set of real, technically confirmed small issues surfaced: one kind of CSS comment silently breaks the parser; a browser screenshot tool holds a minimum height regardless of the width requested; pixel-based measurement nearly got fooled by font anti-aliasing on some boilerplate text — caught only by a second, independent check done a different way. Almost all of these would have stayed buried inside notes for one specific task — now every confirmed finding gets its own short write-up, so the next task doesn't have to rediscover the same thing from scratch.


What this is called and where it meets people

A pitch tested by restating it in plain words, and three channels where the right audience already is.

"Every important decision is first written down with its options and the reason it was chosen, and then a separate pair of eyes — also AI, but a different one — looks for a mistake in it before it turns into code or a contract. Because of this, the project's history always shows what was proposed, what was rejected, and why — not just what came out in the end."

Developer communities

Dedicated online communities built around AI-agent development range from hundreds of thousands to over a million members — exactly the people working with these tools daily, not a random venue.

Industry events

Juried industry conferences that bring together founders and engineering leaders already adopting agents — a more expensive channel to enter, but one that reaches decision-makers directly.

Partner network

The existing network of consultancies and integrators around the Claude platform — an already-vetted pool of firms with clients ready to pay for AI-agent adoption, with no need to build an audience from zero.

Partnership economics

For a partner who simply refers a client — 10-15% of the first contract's value as a one-time payment. For a partner who implements or provides ongoing support themselves — 20-25% of the support fee, for as long as it continues. The range is built on industry benchmarks for consulting and SaaS partner programs, discounted for the fact that ongoing support is live human work, not a product with zero marginal cost to serve.