baselane now compiles your standard to Codex and Gemini formats alongside Claude Code, Cursor and Copilot.
baselane team · May 15, 2026 · 4 min read
Almost no engineering org standardizes on a single AI coding tool anymore, and pretending otherwise was never going to hold. Some developers live in Claude Code, some in Cursor, some are trying Codex, some default to whatever their IDE ships with. A standard that only reaches one of those tools reaches, in practice, whichever fraction of the org happened to pick that tool — which is not a standard at all.
This release adds two compilation targets to the pipeline: Codex's config format and Gemini's. Nothing changes about how a team declares its standard — the canonical spec for a repo's commands, constraints and conventions is exactly what it was. What changes is how many tool-specific files get generated from it. A repo subscribed to the relevant packs now gets its AGENTS.md/CLAUDE.md pair, its Cursor rules, its Copilot instructions, and its Codex and Gemini equivalents — all compiled from the same source, in the same PR, kept in sync by construction rather than by someone remembering to update five files by hand.
The naive version of this feature is a find-and-replace across five near-identical files. That breaks the first time one tool's format needs something the others don't — a specific front-matter field, a different section ordering, a constraint on file length. Codex and Gemini both have their own conventions for how instructions get discovered and loaded, different enough from Claude Code's and Cursor's that a shared template would have meant compromising on all of them to keep the diff small.
Instead, each target is its own renderer against the same validated source object — the same pattern the render pipeline already used for Claude Code, Cursor and Copilot. Adding Codex and Gemini meant adding two renderers, not rearchitecting the compiler. That's also why the golden output for every built-in pack is committed and checked: a renderer change that isn't supposed to change bytes, doesn't, and one that is supposed to, updates its golden alongside it in the same PR.
The list of targets will keep growing as the tool landscape keeps shifting, which it will, continuously, for the foreseeable future. That's the actual argument for compiling from one canonical source instead of authoring per-tool by hand: the cost of a new tool entering the market should be one new renderer, not a rewrite of every repo's instructions.