Unlazy: make coding agents prove the work is done

Why it matters

A coding agent's completion message can create a surprisingly expensive handoff. You start using the feature, discover a missing requirement, and then have to investigate which other claims were premature. For someone maintaining integrations or internal software, that investigation can erase much of the time saved during implementation.

Unlazy introduces a useful discipline: define completion conditions and attach evidence to them. My interest is in the acceptance process it encourages. The video's claim that agent laziness has been solved is broader than its demonstration can establish. A command can execute successfully while checking the wrong behavior, and a polished checklist can still leave out an essential requirement.

I would judge this approach by how much uncertainty remains when the work reaches review. More agents and longer execution times are inputs. Fewer omissions and less human investigation are the outcomes worth measuring.

Key points

• 01:04 The channel introduces Unlazy as a way to connect completion claims with recorded evidence. This makes individual requirements inspectable instead of leaving the reviewer dependent on an agent's closing summary.
• 02:37 The video separates premature completion from silent scope reduction. That distinction matters: all implemented features might pass their tests while a difficult, originally requested feature never makes it into the test plan.
• 05:49 Tree depth determines how the task is decomposed. In the version described, depths of three or less use solo mode, while four and above introduce orchestration. Depth changes the work structure; it does not establish correctness.
• 07:24 Completion conditions connect an outcome, a command, an expected response, and captured evidence. The command's meaning is crucial. A success message proves little unless producing it requires the relevant behavior to work.
• 08:28 The coordinator rechecks returned work and records explicitly abandoned requirements. That provides a more useful handoff because unresolved work remains visible rather than disappearing behind a confident completion message.
• 10:34 The team reports a three-to-four-hour run that had produced only a login page and identifies sequential dispatch as the bottleneck. This describes one configuration, without a controlled comparison that would predict results elsewhere.
• 11:38 Their modified workflow assigns file responsibilities before running agents concurrently. The reported outcome is a first application version after roughly two hours with ten simultaneous agents. The transferable lesson is to establish dependencies and ownership before increasing concurrency.

How to apply

Unlazy: define observable completion first

Start with a small feature that includes an entire working path. I would use a contact importer for an internal application: parse a CSV, validate its contents, save valid contacts, and explain rejected rows. Requesting only an import screen would leave too much room for an attractive interface with incomplete behavior underneath.

Write down the required outcomes before implementation. Decide whether duplicates should be ignored, updated, or rejected. Decide whether one invalid row should stop the entire import. Those are product decisions that tests need to encode explicitly.

Build fixtures with synthetic data and known answers. For this exercise, I would use the following acceptance cases:

| Proposed scenario | Required outcome | Useful evidence | |---|---|---| | Twelve valid rows, including two duplicates | Ten unique contacts stored | Read persisted records and compare their fields | | The same file submitted again | No additional duplicates | Compare record counts and contents before and after | | A separate file containing an invalid phone number | Follow the agreed error policy | Identify the correct row and inspect the final import state | | Accented names and international phone prefixes | Preserve values according to the contract | Read the values back after saving |

The table gives the reviewer an observable definition of success. It also exposes decisions that a generic request such as “build CSV import” leaves unresolved.

Establish that a check can actually fail

Inspect what each proposed verification reads. Searching an API response for “import complete” does not establish that records reached storage. Also check that the command exercises the current implementation rather than reading an earlier report.

Next, introduce a controlled defect in a disposable working copy. Temporarily disable persistence, for example, and confirm that the relevant check fails. Restore the implementation and confirm that it passes again. This helps identify checks whose result is disconnected from the feature they supposedly verify.

Use the project's gate format reference when translating these acceptance cases into the ledger required by your installed version.

Check the source version before applying the video's patch

At the time of this draft, the README already describes parallel orchestration. It identifies the current source as targeting 2.1.0 without presenting it as a tagged release. Check the official repository before modifying the skill to add concurrency, and record the exact commit used in your experiment.

Install it for the selected project using the matching README. Combining current code with instructions from an older demonstration makes the experiment harder to interpret and repeat.

Agree on interfaces before dispatching parallel work

In the importer example, parsing and error presentation could proceed separately once their shared data format is settled. Integration depends on that agreement. Assigning both tasks immediately would merely move unresolved design decisions into separate conversations.

The project's parallelism documentation explains that declared file ownership coordinates cooperating processes; it does not enforce write isolation. I would begin with a few independent tasks and inspect the integrated result after each round. Increase concurrency when the task structure supports it.

Measure the effort required to approve the result

Compare runs with and without the skill from the same starting code and acceptance criteria. Record elapsed time, reported usage, satisfied requirements, and human review minutes. Repeat the comparison enough to avoid drawing a conclusion from one unusually good or bad run.

Keep a separate list of missing requirements. Otherwise, a workflow that quietly drops the hardest feature may appear faster than one that attempts the whole job.

The repository provides a validation protocol and acknowledges limitations in its historical comparisons. My adoption criterion would be practical: fewer omissions and less investigation at an acceptable cost. Final approval would still depend on integrated behavior and the product decisions that require human judgment.