Shahryar Ahmad

We got some pointed feedback on our site a while back vague messaging, screenshots that looked like mockups, trial terms nobody could actually find. It was uncomfortable to read, and it also turned out to be dead right. We spent a week tearing the whole thing apart and rebuilding it instead of just patching the parts people complained about.

That decision is what I'm actually curious about. A handful of comments pushed us into a full rebuild rather than a few tweaks. In hindsight it was the right call, but at the time it wasn't obvious it easily could've been one loud opinion instead of a real signal.

For other makers here: how do you tell the difference? Do you wait for a pattern across multiple people before you act, or does one sufficiently specific critique carry enough weight on its own? Curious whether people use any actual method for this or if it's mostly instinct built up over time.

Think about what an agent session actually risks. It edits files in a working tree. If that tree was clean when it started, the entire session's damage is one diff you can read and one reset you can throw away. Branches cost almost nothing, so every task can live on its own one, and merging stays a human decision made after reading the evidence.

Underneath that sits the layer most people only meet in a crisis: the reflog. Every commit, reset, rebase, and branch move leaves an entry, kept for 90 days by default even when nothing points at it anymore. For a month or three, almost nothing an agent does to your history with everyday commands is actually gone.

We once had to defeat this on purpose: a clean-room experiment required one commit to be truly unfindable. Deleting it took five deliberate steps remove the remote, delete branches and tags, expire the reflog, garbage-collect, verify. Five steps to lose one commit. That's the strongest endorsement of a safety net we know how to write.

A products fetch in my iOS app came back empty. No error, no crash, nothing unusual in the logs. The purchase button simply sat there greyed out, because an empty list is a perfectly valid response and every check I had passed on it. App Review found that one and I had not.

The pattern is a call that fails without failing. An empty result, a stale cached value, a permission that was denied months ago and now returns nothing instead of an error. The user is stuck and the code is behaving exactly as written, which is why an agent cannot help much either. Ask it to reproduce the failure and it writes a test that agrees with the current behaviour.