Building envibe, Part 3: The Polish

This is Part 3 of a 3-part series. Start with Part 1: The Idea or Part 2: The Build.

v0.2: DX Polish

The initial release worked, but the DX had rough edges. v0.2 focused on making the AI's experience better when it couldn't access a variable.

Instead of just returning "access denied," placeholder variables now include format and example hints in the manifest. So when the AI asks for OPENAI_API_KEY and gets back a placeholder, it also learns the format is "key" and an example looks like "sk-proj-...". Enough to generate correct code without seeing the real value.

{
  "name": "OPENAI_API_KEY",
  "value": "<OPENAI_API_KEY>",
  "access": "placeholder"
}

The env_check_required tool was the biggest addition. Before it existed, the AI would try to run your app, hit a missing env var error, and then ask you about it. Now it can proactively check what's missing before anything breaks. It's the tool I use most.

The env_blind_set Bug

This one stung.

What I Learned

"Default to safe" is a design principle, not a feature. It's the difference between a permission system that works when you forget to configure it and one that only works when you remember everything. envibe's most important line of code is the one that returns placeholder for unknown variables. I didn't appreciate this until the DATABASE_URL mistake in Part 2. The pattern matcher caught it because the safe default was already there. If the default had been full, that bug would have been a data leak.

AI changes the build curve, not the thinking curve. Two months from research to a published npm package, with most of the actual coding compressed into a few focused sessions. But the security decisions (which variables to protect, how to handle database URLs with embedded passwords, what env_blind_set should and shouldn't allow) took the same amount of careful thought they always would. AI compresses the implementation time between decisions. It doesn't compress the decisions themselves.

Small, focused tools matter more in the AI era. When every developer has an AI assistant that can compose tools together, the value of a tool that does one thing well goes up. envibe doesn't try to be a secrets manager. It's a permission layer. That's it. The env_check_required tool is useful because it does exactly one thing: tell you what's missing. No dashboard, no notifications, no integrations. Just a list.

Building with Claude Code was pair programming with a fast, tireless partner who needs you to make the judgment calls. The ratio of "thinking about what to build" to "typing the code" shifted dramatically. Whether that's good depends on whether you use the freed-up time to think harder or just ship faster.

This project is still evolving. There are more access patterns to consider, more integrations to build, more edge cases to find. If you're working with AI coding assistants and want control over what they can see in your environment, give envibe a try and let me know what's missing.

Read the full series: Part 1: The Idea | Part 2: The Build | Part 3: The Polish

envibe is open source: GitHub | npm | Product overview