Viktor.comAn AI coworker that actually does the work
Promoted
Open source feature flags. Every flag is a markdown file that lives with the code it controls: what it does, why it exists, and what you decided, reviewed in a PR like any other change. Your coding agent installs Dif in one command, no account, and reads the context file so it knows what's live and what was already tried. A/B tests wait in the same files until you have traffic. Send events to your own analytics, or let Dif Cloud read the results and write the decision into the file.
I like the RR based approach here because every flag change gets context. Could dif.sh also show a simple history of why a flag changed over time?
dif.sh
@hamza_afzal_butt right now it's the default git conflict behavior. We have found with the .md files that non-technical folks are able to handle those conflicts easily though.
I really like the idea of keeping the flag and the reasoning behind it in the same file. That kind of context usually disappears after a few weeks.
dif.sh
@thomas_bennett Agreed. A lot of flag/experiment tools handle the analysis, but usually they don't keep the actual story of what works, what has been tried, etc.
The idea of treating featuree flags as part of the codebase Is unique
dif.sh
@tolulope_orija TY! ... and with it you unlock a cleaner workflow for teams, better learning management, easier self-hosting, and increasingly important, it allows coding agents to seamlessly interact with it.
dif.sh
To everybody that made our product hunt launch a success! We are proud to have been voted "Product of the day"! We appreciate the enthusiasm and excitement around dif.sh. As always, please continue to share your feedback. We have so many more ideas in the pipeline and can't wait to show you!
You asked for the critical version. Flags in git means flipping one takes a commit, a review and a deploy, and the reason teams pay for a flag service is the kill switch at 2am without any of that. For agent facing flags it's a fine trade, for a gradual rollout or an incident it isn't. Markdown also won't fix dead flags, since nothing gets reviewed when nothing changes and the flag nobody has touched in four months is still branching in prod.
dif.sh
@asadmalik901 Thanks for the input. Yeah there are definitely trade offs. We've found it's worth the improved every day performance (no api calls / extra hops) in not having the kill switch but it depends on the organization.
For dead flags, I actually think dif helps with this tremendously. The cli helps to find everything running and used with an agent it can find these pretty quickly.
Dial
Congrats on the launch. The "flags reviewed in a PR" part is the real hook for me - most flag tools bolt on a dashboard that nobody checks, and this just stays in the same review flow. Curious about one thing though: if two agents are working in parallel branches and both touch the same markdown flag file, does dif help resolve that conflict at all or is it just a normal git merge conflict at that point?
dif.sh
@galdayan Right now it's just a normal git merge. That's a good idea to add though, we'll note it!