Topic: Developer Experience

Flipster is our open source library for using OpenFeature safely in production. It came out of adopting trunk-based development, where feature flags stop being a nice to have and become the thing that lets a deploy and a release be two separate decisions.

It wraps the OpenFeature SDK behind an interface you can inject and test like any other dependency, and puts a circuit breaker in front of the provider. Defaults move out of the call sites and get declared once, in one place, so a degraded flag provider never becomes a production incident.

You finish a feature and you’re holding a hook, a helper, a type, and a stylesheet. Where do they go? For a while our answer was “it depends,” which is another way of saying nobody knew.

This is how we settled on one folder per feature, and how we stopped it from drifting back into a mess.

Three AI coding tools, three config files, all slowly disagreeing with each other and with the code. This is how we got down to one source of truth the robots and the humans both read.

Onboarding onto a large LMS codebase, I used Cursor not to write features faster, but to build a mental model: where legacy PHP meets newer REST layers, how events propagate, and where permission checks actually live.

This post walks through two real explorations (user impersonation across stacks and a permissions trace), with anonymized prompts, what the tool got right and wrong, and a small playbook you can reuse on your own brownfield project.

You bump a version, run install, and the project catches fire. That’s a React upgrade.

Half the bugs you find were already there — the rest is types, tests, and Claude Code keeping the investigation from eating you alive.

Most AI coding workflows assume you’re building something new from scratch. But what if you’re building something that spans multiple existing codebases, each with years of accumulated quirks?

This is how I stopped fighting context loss and built a system that actually works with existing codebases.