Company

Why we built baselane.

AI coding stopped being a novelty and became how work gets done. Nobody standardized it. Our founding thesis: AI practice deserves the same rigor as code.

baselane team · Jul 9, 2026 · 4 min read

Something changed in the last two years that most engineering organizations haven't caught up to, even though every one of their developers already has. AI-assisted coding stopped being a novelty a few people tried on the side. It became how work actually gets done: completions, a chat panel, an agent that reads a repo, opens a branch, and puts up a pull request. It happened fast, one laptop at a time, so it happened almost invisibly to anyone whose job is knowing what's actually running across the org.

We started baselane because we watched that gap widen at company after company, and it kept costing more than anyone expected.

Nobody decided this

Ask a platform lead how their teams work with Claude Code, Copilot, or Cursor, and you'll get an honest answer: however each developer set it up. One engineer wrote a CLAUDE.md for their repo eighteen months ago and nobody's touched it since. Another keeps a folder of personal slash-commands that never leave their laptop. A third's agent has permissions nobody signed off on, because approving them once was faster than asking. None of this was a decision. It just accumulated, the way config does when nobody owns it. By the time it's visible enough to worry about, an email won't fix it.

The cost isn't hypothetical. The same feature gets built three different ways in three repos because the agents drew from three different conventions. Nobody can say which agent had write access to what once something breaks. And the new hire spends their first two weeks discovering, repo by repo, which of six conventions their team actually uses this month.

The old fixes don't hold

Every org we've talked to has tried the obvious countermeasures, and every one has watched them fail the same way. A wiki page describing the "recommended setup" gets written once, read a dozen times, and followed by nobody. A document with no distribution mechanism is just a suggestion. A linter catches what ends up in the diff, but says nothing about the prompt, the permissions, or the instructions file that produced it. "We'll converge naturally" is the closest thing to a plan most teams have. It doesn't happen on its own. Somebody has to force convergence, and usually nobody does.

None of these are versioned, reviewed, or distributed. They sit outside the machinery that already keeps everything else in an engineering org honest.

AI practice is engineering practice

baselane is built on one idea: how your team works with AI is not a personal preference or a tooling footnote. It's engineering practice, and it deserves the same treatment engineering practice gets everywhere else: versioned, reviewed, distributed, and governed. No engineering org would accept fifty developers running fifty different lint configs with no visibility into which repos had adopted which. That's how incidents happen. We don't see why the instructions, skills, and guardrails that shape what an AI agent writes into your codebase deserve a lower bar than the linter does.

Treat your AI standard the way you already treat your code.

Author once, distribute everywhere, govern adoption

In practice, that means three things. You author your standard once: the AGENTS.md conventions, the skills, the agents, the guardrails your org has actually agreed on, as a versioned pack instead of a folder someone forgot to update. baselane distributes it everywhere that standard applies, as a pull request into every repo it fits, reviewed and merged like any other change, and as a sync to every developer's laptop through a desktop agent that layers the org standard in without touching the tweaks they've already made. And then you can actually see it: a live count, down to the repo and down to the person, of who's actually on the standard you set and who isn't yet. No slide in a quarterly review claiming "AI transformation is underway."

Where we don't compromise

The developer stays in the loop at every step. Skip that, and you trade fragmentation for something worse: invisible pushes to a repo or a laptop nobody actually reviewed. Every change baselane makes to a repo arrives as a pull request, reviewed by a human, merged on that team's own schedule. Every change to a laptop respects the developer's own edits instead of overwriting them. Nothing ships silently, and nothing skips review just because a tool wrote it instead of a teammate. If a capability isn't built yet, we say so, in the product and in the coverage report, instead of quietly no-op'ing it and hoping nobody checks.

We'd rather this be boring, the way git is boring. Git works because "whose code is this and when did it change" stopped being a Slack thread and became a question with one answer. We want the same for our AI standard: what it is, who's on it, when it last changed. That shouldn't need a retro to settle.

AI coding is only going to get more central to how software gets built. The organizations that keep treating their AI practice with the same rigor they apply to their code will be the ones who still know what's running in their own repos a year from now. That's the standard we're building toward. It's why we built baselane.

← Back to blog