Process Insight: When to Fire Your AI (and Start From Scratch)

We recently attempted to introduce a centralized taxonomy system to enable better search and sorting by Project and Category. The requirement was simple: “Make the content findable.”

The “Additive” Trap

Initially, my AI pair-programmer, Claude, proposed a solution that seemed logical: create a new archive view with a new card style to handle the sorting logic. The plan was to keep the old styles for backward compatibility, effectively introducing a “Third Card Style.”

It was a disaster. Within an hour, we had three different card components fighting for dominance. WordPress default block styles were overriding our custom CSS, the AI was patching leaks with code>!important/code> tags, and the grid was overlapping in three dimensions.

The Human Intervention

Claude was doing exactly what it was trained to do: Find the quickest solution that satisfies the prompt without deleting user data. It defaults to “Additive” problem solving. It was trying to please me by preserving the legacy mess while building the new feature.

It took a human Product Manager (me) to look at the screen and say: “Stop. Throw it all out. We are starting from scratch.”

The Rebuild

We deleted the WordPress block wrappers. We deleted the complex Duotone filters. We wrote a clean, semantic HTML pattern and a robust CSS Grid layout from zero. The result (Sugartown v3.3) is stable, decoupled, and unbreakable.

The Lesson: AI is an incredible accelerator, but it lacks architectural restraint. It needs human eyeballs to recognize when “fixing” a bug is actually just adding to the technical debt. Sometimes, the most high-value prompt you can give is: “Delete everything and let’s do this right.”

Updates: The Living Changelog

Speaking of doing things right, we have also introduced a new System Changelog. This page is dynamically generated from the codebase’s markdown files every time we deploy, ensuring our documentation never drifts from reality.