Just shipped v1.1.5: Why text-scraping AI code is a dead end (and what we built instead)
Thanks for the massive support on the last update! I’ve been heads-down rewriting the core engine of LineageLens, and I'm stoked to share the v1.1.5 release.
When building an audit trail for AI-generated code, the default approach is to try and regex markdown blocks out of the LLM’s text response. It is incredibly brittle. For this release, we ripped that out entirely.
The LineageLens proxy now natively parses the underlying structured protocols:
Anthropic’s tool_use blocks (handling the streaming JSON assembly)
OpenAI’s apply_patch DSL (via the newer Responses API)
Gemini’s functionCall arrays
Why this is a game changer: Because we are parsing the native tool calls, we can build a state machine. The proxy now correlates the AI's proposed edit with the next turn's tool_result. Your dashboard doesn't just show what the AI hallucinated—it tracks whether you actually Applied, Rejected, or Errored the code.
It completely closes the context gap. The original system prompt, the exact model name, and the final edit status are all logged locally.
Replies
The state machine idea makes so much sense in hindsight. Why track the suggestion if you don't know the outcome?
Lineage Lens
@ruby_cooper Exactly. The suggestion itself is the proof of intent — but intent without outcome creates noisy audit trails.
So in v1.1.5 we moved to a state-machine model: every AI proposal is first captured, then later resolved as applied, rejected, or errored once the next diff/tool result arrives.
That preserves the full prompt → model → proposal → outcome chain while preventing rejected suggestions from being misclassified as “AI-written code.”