Require a new usable feature in every improvement cycle

An improvement loop can spend its time improving the loop. It adds logging, reorganizes helper functions and writes another configuration file, all while the person waits for a feature in the application they asked it to build. The work may be competent and still miss the requested object.

In March, I specified what an agent-driven product-improvement loop should be improving. I wanted a repeated agent task to add useful, user-facing behavior to the application, check the progress record for novelty and finish the necessary interface, state and tests. I also asked what would happen over 250 iterations. The record preserves that proposed experiment and my intention to try it; it does not establish 250 completed iterations.

The difficulty is giving the worker enough freedom to select useful work without allowing a vague instruction such as “improve something” to become permission for whatever change is easiest to complete.

Compare the current application with the progress record

A reading-list application provides a useful hypothetical test of that requirement. Its progress record says that title search already exists. The worker opens the application and confirms that search can find an item but cannot filter unread items. A useful candidate might add an unread filter that works together with title search.

The existing record helps avoid repeating a completed feature, but the running application remains important evidence. The record could be stale or mistaken. A worker should verify what a person can currently do before treating a description as proof that the behavior exists.

The candidate needs a clear user action. A person selects “unread,” searches for a title and opens the matching item. The filter should survive the expected navigation behavior, and the empty state should explain when no item matches. The task should include any storage or state changes needed for that action to work coherently.

When the worker proposes the unread filter, have it identify the existing screen where the action will begin and the saved item that demonstrates the change, then compare that proposal with the last accepted feature record. This small inspection can reveal that filtering already exists behind another control, in which case the more useful task may concern discoverability or an incomplete interaction, provided the revised choice still satisfies the authorized improvement scope.

Prefer completion of an actual workflow to more visible controls

A filter that resets unexpectedly may be less useful than repairing the existing search. The worker should explain the choice with reference to the application’s purpose and observed condition. “New” is a necessary constraint in this experiment, but novelty alone does not establish value.

Likewise, a new control is not automatically a complete feature. The reader needs to see its effect, recover from an empty result and continue the task. A button that opens an unfinished panel creates another dependency instead of resolving the selected problem.

The acceptance checks should exercise the whole action. Add several saved items with different read states, combine the filter with a query and confirm that changing an item’s state updates the result correctly. Use the ordinary interface rather than a direct internal call that bypasses the controls under review.

Record what changed in terms the next worker can verify

After acceptance, add a progress entry that names the behavior, the problem it addresses and the files or modules changed. Include the tested version and the checks that support the completed status. Record any limitations that affect how a later task can build on the feature.

A useful entry distinguishes the unread filter from title search without relying on a new marketing name. The next worker should be able to find the behavior in the application and determine whether a proposed task would repeat it.

Do not let the novelty condition prohibit necessary maintenance. If a defect blocks the next feature, the worker should identify that dependency and seek the appropriate change in scope. The rule governs the primary improvement being selected; it does not make broken foundations safe to ignore.

Close the cycle after the combined search and unread filter works with the saved fixtures and the progress entry records its exact behavior. The following cycle can then inspect the application and select a different unfinished action, using the record as evidence to check rather than as an instruction to keep adding controls.

Source notes

Drew Wiberg, user-facing product-improvement loop requirements, 18 March 2026. Contemporary author records; 250 iterations were contemplated, not documented as completed.

Worked examples and review procedures in this article are instructional applications, not additional historical project results.