akdarrah 0:posts* 1:archive 2:about
adam@akdarrah~/posts$cat ai-made-me-use-more-feature-flags-not-fewer.md

AI made me use more feature flags, not fewer

3 min #ai#process
contents · notes

# contents

Looking back over this week's work, one thing stood out: I need to use feature flags much more than I have been.

The old reason for flags

On a traditional project, the flag let you split a feature into pieces and ship each one on its own. You'd ship the backend behind a flag. Then the frontend work would come in over a few weeks: building it, iterating on it, showing it to people and changing it based on their feedback, all with the flag still off. Only when the whole thing was ready would you turn it on.

The flag existed because the work took a long time, and you didn't want a half-built feature sitting on a branch for all of it.

AI shortened the timeline, but the reason stayed

With AI, those weeks can turn into days. So I'd started treating flags as overhead from a slower era. If I can build the whole feature this week, why not ship it all at once?

This week changed my mind. The flag was never only about how long the work took. It's what lets me ship each piece the moment it's done, without worrying that a half-finished feature will break something for a real customer. And with AI, I'm shipping pieces faster than ever, so I need that protection more, not less.

The flag also gives me two things I'd underrated:

  • One end-to-end QA pass at the end. Each piece can ship and be tested on its own. Then, once they're all in, I can test the whole feature from start to finish before anyone sees it.
  • Time for the mobile app to catch up. The code is in production but not turned on, so the mobile app can be updated against the real thing before the feature is live.

A how-to video is a QA test

The other thing I learned this week is that making a step-by-step instructional video for a feature is a very good way to QA it.

I'd built a feature piece by piece, and I'd QA'd each piece on its own. Every piece passed. Then we went to record the end-to-end video, walking through the feature the way a customer would, and found a bug, which we then fixed.

None of the individual QA passes could have caught it. The bug only showed up when the pieces were used together, in order, the way a real person would use them. A how-to video forces exactly that: you can't skip a step or start halfway through, because the viewer needs to see every step.

You don't have to record it yourself, either. Having the AI walk through the feature end to end, as if it were recording the video, catches the same kind of bug.

What I'm doing differently

The two ideas fit together. Ship every piece behind a flag as soon as it's ready. When the last piece is in, record the how-to video (or have the AI walk through it) while the flag is still off. Fix what that turns up. Then flip the flag.

share
view .md
↑↓ move↵ open` shellesc close
akdarrah0:posts1:archive2:about3:shell* esc close
adam@akdarrah~$help
  ls [posts|tags]   list things      cat <slug>   open a post
  grep <word>       search           art [scene]  draw something
  tree              the old bonsai   subscribe <email>