blog main page

I recently shipped an undo/redo system for a client-side app, and it reminded me how deceptively deep this feature goes. What begins as “just keep two stacks” quickly becomes a set of product and engineering decisions: what counts as a single step, how to group multi-part changes, what belongs in history versus “session” UI state, and how to handle cancellations or partial failures without surprising users. In part 1 of this series, I share the mental model and history design rules that make undo/redo predictable and maintainable, plus a quick tour of common approaches (snapshots, commands, patches) and the cloning and boundary pitfalls that break most first attempts. Part 2 builds on that foundation with transactions and rollback.

For the first part of my career and well into my mid-career, I carried a quiet tension that followed me from project to project. When I built software from scratch and watched it grow into something stable, I started to see it as more than code. It felt like a legacy, so every change request that did not match my original vision and every new contributor who wanted to shape the work stirred up a protective fear that it could be damaged. In this blog post, I want to share what that experience looked like for me, how it sometimes led to frustration or emotional withdrawal, and what I learned over time to cope with those feelings so my projects could evolve without taking something away from me.

Part 1 was about the core failure mode in LLM-assisted refactoring: the code is rarely the bottleneck, the unspoken intent is. This follow-up is the hands-on playbook for fixing that. It walks through a repeatable workflow for surfacing ambiguity, forcing real decisions, recording them in a decision log, and turning them into a scenario matrix you can treat as acceptance tests before you touch implementation. Using the same bulk calendar edit example, it shows the exact prompt patterns and refinement rounds that keep the model in “pressure test the spec” mode, so the final refactor becomes mechanical, safe, and easy to verify.

Most of the time, LLM-assisted refactors do not fail because the model cannot code, but because we do not transfer intent clearly enough for the changes to be safe. In this post, I share a practical way to close that gap: treat the LLM like a requirements debugger and iteratively turn fuzzy “support bulk edit” style statements into explicit, testable rules. I use a familiar product scenario, bulk editing calendar events, to show why multi-select turns “obvious” behavior into ambiguity traps, and which lightweight artifacts (glossary, decision log, scenario matrix, stop criterion) make the work manageable. Part 1 focuses on the problem and the refinement process; Part 2 will walk through the workflow with concrete examples you can reuse.