A learning loop still needs someone to own the gate

Read Tyler Folkman's product-loop walkthrough for the review boundary, not the promise of a workflow that improves itself. It is useful for product leads turning recurring research or prototyping into an agent task—and for engineers who will have to maintain the result.

The Product Growth interview transcript describes work that gathers inputs, produces an artifact, checks it and uses feedback to revise the process. Crucially, Folkman also describes Git rollback and a pull request for a human to review before changes reach the main branch. This is not a proposal to remove every human gate.

Keep the test outside the suggestion

My rule is simple: permission to suggest a better workflow must not include permission to lower its acceptance standard. A cleaner skill file can still produce worse decisions. Reviewing the diff is necessary; comparing behaviour is the part I would insist on next.

As a proposed exercise, pick a recurring task with five saved examples. Run the current skill, keep its outputs, then let the learning step propose a revision. Review that change against the same examples before accepting it. If the revision also changes the examples or success criteria, inspect those changes separately. Otherwise the candidate and its examiner have moved together.

That is a narrow extension of versioning the eval history: the next version should carry evidence of what improved and what regressed. A persuasive explanation of the change is not that evidence.

Read the method, not a performance guarantee

I reviewed the written transcript, not a running deployment of Folkman's system. The exercise above is my suggested acceptance test, not a benchmark I executed against his workflow. His discussion is valuable as an operating method; it does not establish that self-revision reliably improves your particular task.

Let the loop propose the improvement. Keep a separate owner for the standard it must pass.