We built a capture layer for Aider, Cline, and Windsurf
Something that surprised me while building this week: "OpenAI-compatible" is a statement about the API shape, not about how code edits are expressed inside it.
Aider does not use tool calls. It sends edits as structured text blocks — SEARCH/REPLACE delimiters — inside the assistant message. The filename is on the line before the fence, not inside it. Cline and Continue use proper tool calls. A response from some backends carries both.
The adapter we shipped this week (`openai_chat.py` in the LineageLens proxy) handles all three patterns: tool-call edits, text-content edits (Aider SEARCH/REPLACE, unified diffs, fenced blocks), and mixed responses where both appear together. It covers Aider, Cline, Continue, Copilot CLI, Goose, Windsurf, and any OpenAI-compatible backend — Azure, groq, fireworks, mistral, together.ai.
The hardest design decision was not the parsing. It was fail-open vs. fail-safe. If capture logic throws an error, do you surface it (fail-safe) or swallow it and pass through (fail-open)? We chose fail-open. A proxy that occasionally interrupts a developer's coding session gets uninstalled. Governance with a 60% retention rate is strictly worse than governance with 95% retention.
The payoff: once your whole tool stack is captured, `lineagelens report . --unreviewed --category auth` becomes a trustworthy query. Without full coverage, that filter silently excludes whole tool categories.
Full project at lineage-website.vercel.app.
What AI coding tools does your team use that you feel like you have the least visibility into?
Replies
The fail-open vs fail-safe decision is honestly the most underrated part of building governance tooling. A proxy that interrupts the dev flow even once every few days gets yanked, so I totally get the call.
The bit about "OpenAI-compatible" only meaning API shape, not edit format, is something I ran into too with Aider specifically. SEARCH/REPLACE blocks inside assistant messages tripped up our logging pipeline for a while before we realized the issue wasn't the backend, it was the message structure.
Lineage Lens
@nolan_vu I think this is one of those places where developer experience and governance are tightly coupled. A technically perfect capture system that interrupts workflows loses trust quickly, while an invisible system with broad coverage often ends up being more useful in practice.
And yes — Aider was a good reminder that "OpenAI-compatible" says very little about how edits are actually represented.
@praveen62
Yeah the "invisible system with broad coverage" framing is spot on. We tried a stricter approach early on where every AI edit had to be explicitly approved before commit, and the team just started bypassing it within a week. Turns out developers will route around anything that adds friction to their flow, no matter how good the reasoning behind it is. The tools that survive are the ones nobody notices are running.
And the Aider point about "OpenAI-compatible" is something more people need to hear. We wasted a solid two days debugging what we thought was a model issue when it was purely a message structure mismatch. The API shape matching gives you a false sense of confidence that everything underneath works the same way. It really doesn't.
The fail-open decision makes a lot of sense. If the capture layer breaks the coding flow, developers will remove it no matter how good the governance story is.
The tricky part is that “OpenAI-compatible” often gives a false sense of uniformity. The request shape may look standard, but the actual edit semantics vary a lot between tools. Capturing Aider-style SEARCH/REPLACE blocks, tool calls, diffs, and mixed responses in one layer sounds genuinely useful.
For me, the least visible areas are usually multi-agent or desktop-agent workflows, where edits, approvals, and context can move across several tools. That is where auditability gets hard: not just what changed, but which agent suggested it, which tool applied it, and whether a human reviewed the risky parts.
Lineage Lens
@vlasoffchess The multi-agent point resonates a lot. Once work spans agents, tools, approvals, and humans, the question shifts from "what changed?" to "how did this change come into existence?" That's where provenance becomes much harder — and much more valuable.
The hardest part of AI governance probably isn’t collecting data, it’s collecting complete and accurate data without hurting developer flow.
Lineage Lens
@amard_sonal I think that's exactly the tradeoff. Collecting data is relatively straightforward; collecting complete, trustworthy data without adding enough friction that developers uninstall the tooling is much harder.
Mixed responses containing both tool calls and text edits sounds like the kind of edge case that breaks naive implementations quickly.
Lineage Lens
@alicia_klein Absolutely. Mixed responses are one of those edge cases that look uncommon until you start supporting multiple tools and providers. Once they appear, naive assumptions about a single edit format break down pretty quickly.
Serand
Curious how you handle new coding agents when they appear. Is the adapter system designed so the community can add support without waiting on releases?
Lineage Lens
@anthony_adams_ That was one of the design goals. The adapter layer is intentionally modular because new coding agents are appearing faster than any single team can ship support for them. Long term, I think community-extensible adapters are probably the only scalable path for keeping pace with the ecosystem.
Lineage Lens
which ai tools are your team using !!