Kieran Klaassen describes how his role changed while building an AI email application: early work focused on correcting generated code, then shifted toward better plans, product decisions and reusable memory. Repeating the same guidance exposed a further bottleneck, and a growing instruction file became difficult to manage. His response was to preserve solutions and the reasoning behind decisions in repository documents that future agent tasks could retrieve.
Kieran Klaassen organizes the workflow around brainstorming, planning, implementation, review, polish and compounding what was learned. Human attention is concentrated at the beginning, where the problem and desired outcome are clarified, and at the end, where the result is judged against product and design standards. The middle should become reliable enough to run with limited intervention. He proposes spending roughly half the effort on delivering the feature and half on improving the system so the same mistakes do not recur.
Kieran Klaassen demonstrates ways to apply this approach beyond writing code. An ideation workflow organizes open issues and evaluates possible work against strategy and prior experiments; document review surfaces unanswered questions in a product brief; and brainstorming draws on personas and accumulated project knowledge. An implementation loop then plans, works, reviews, tests and opens a pull request with evidence of the changes. These examples show how shared context can support product decisions as well as execution.
Kieran Klaassen distinguishes final polish from basic quality assurance: the implementation should already work, leaving people to improve clarity, responsiveness and visual details. In one example, feedback about duplicate logo marks becomes a stored design rule for future tasks. The talk argues that documenting why decisions were made, including lessons from failures and postmortems, is more useful than merely restating the code. Its claims about productivity and token efficiency are based on the speaker's experience rather than a controlled benchmark, and its central test is whether completing one feature makes the next feature easier.
Watch on YouTube
