AI & Shifting Right
An interesting biproduct of using AI to build apps is that when costs are obscured we can slide down the slippery slope of requirements shifting-right. We experiment more (which is great) but there's more waste if we stop weighing the cost & benefits.
Before:
"I don't like that all the buttons are flat buttons with no glowing effect when the user hovers over the button. Can we change that?"
"We can... but we have a lot of buttons and different kinds of buttons. Even if we make a pattern to repeat over and over, we have to go through the entire app and make sure all the buttons adopt this pattern. It'll take about 3 weeks, and we'll have to prioritize against the major feature we've been focused on..."
"Well... let's hold off for now and do it as part of a full facelift..."
After:
"Claude, make the buttons green."
"Actually, instead of buttons - what if they were little icons. Draw out some icons for each of the buttons and have them animate on hover."
"Actually, I don't like the animated icons. Let's go back to buttons, but give them a glossy-glass effect. That's really hip right now."
"Hmmm, ok no revert back to green - but let the user also pick from other color themes."
"Ok - no buttons at all. Let's just make them all commands that the user can execute from the keyboard..."
"Ok, back to green."
"No, not that green. It's too gray and sad - like fingerprints on an abandoned rail. I want a green that feels more like... pollen landing on a mouse's nose."
"That doesn't feel like Spring at all. Just go with #00FF00."
While it's great to experiment and iterate, you're also at risk of poisoning the context window and increasing hallucinations if you're too frenetic. Keep with the well-defined requirements (following Good-Enough principles), experiment and iterate with low-cost prototype mocks, validate the impact, and then before moving forward set up clear guardrails and checkpoints.