Launched this week
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.
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!
One command, no account is probably the strongest part for me. Makes it way easier for coding agents to actually finish setup without hitting a signup wall.
dif.sh
@victor_coleman Yeah, we think it's the best option for agents that are setting up the first flags or a/b tests in a codebase. From there it's easy to extend it with dif cloud or a custom analysis provider.
Bababot
I have used separate tools for A/B tests before so keeping the experiment inside the repo feels interesting.
dif.sh
@adams_parker In the past we worked in the same way. Working with dif has been such a nice change.
This feels nicely aligned with how coding agents actually work. No separate dashboard or account to set things up is a pretty refreshing approach.
dif.sh
@johnnie_kuvalis Yeah, compared to MCPs which are pretty hit or miss, dif works much better with agents.
The PR review flow is what caught my attention here. Treating feature flag changes like normal code changes should make the whole process feel much more familiar.
dif.sh
@leo_henry6 I think it catches issues more often than one person setting everything up in a dashboard!
I like the idea of keeping feature flags right inside the repo. Having the reason and decision in the same markdown file makes changes much easier to understand later.