Show PH: I built a VS Code extension that scores AI code risk
Something I built led to a design decision I want to get feedback on.
LineageLens is a free VS Code extension that captures every AI code insertion and scores it for risk on a 0–100 scale. Works with Cursor, Copilot, ClaudeCode, Gemini CLI. Zero config on install — just start using your AI tools and your insertions start showing up in the sidebar.
The scoring is deterministic rules: +28 for credential-like material, +24 for eval/exec patterns, +22 for subprocess calls, +14 for landing in an auth or payments file, and so on. Fully traceable. No ML, no black box.
The design decision that surprised me: missing prompt capture — when the extension records a file insertion but has no record of what was asked — adds +24 to the risk score. Same weight as detecting an eval() call.
The reasoning was that a code record without a prompt is less auditable. You cannot reconstruct developer intent. You cannot detect whether the model exceeded its scope. You cannot spot prompt injection in an agentic session. All of those failure modes require the prompt to be visible.The practical consequence: if you run only the extension without the proxy backend, your risk scores are 24 points higher for the same code than they would be with full prompt capture. The architecture exposes that gap through the score rather than hiding it. I think this is the right call, but it is not obvious — it conflates "we are missing data" with "the code is risky," and those are not the same thing.
Worth discussing: is penalizing incomplete capture a reasonable design for a risk score? Or does it make the number misleading?
Replies
This solves a problem I didn't realize I had until I read this. We've been using AI-generated code in production for months and honestly have no clear picture of which parts were written by AI vs human. When something breaks, the first question is always "who wrote this?" and the answer is increasingly "probably Claude, maybe me, not sure."
The provenance tracking angle is what makes this different from just another linting tool. Being able to trace back to the exact prompt and model that generated a block of code is huge for debugging and for compliance reviews. My only question is how it handles cases where you take AI-generated code and heavily modify it afterward. At what point does it stop being "AI code" in the tracking?
Lineage Lens
@nolan_vu That ambiguity around authorship is exactly the operational problem that pushed me toward provenance tracking. Once AI-assisted edits become normal, “who wrote this?” stops being a simple question and turns into a lineage problem involving prompts, models, edits, rewrites, and reviewers.
The heavily-modified case is one of the harder boundaries. My current thinking is that provenance should decay gradually instead of flipping between “AI” and “human.” If the original structure, logic flow, or semantic intent still survives through transformations, the lineage probably still matters even if the surface syntax changes substantially.
@praveen62 The "gradual decay" concept makes a lot of sense actually. A binary AI/human label never felt right to me because in practice it's always a spectrum. I might take an AI-generated function, keep the core logic but rewrite the error handling and rename everything. At that point calling it "AI code" feels wrong, but calling it "human code" also isn't honest. Tracking how much of the original intent survived through edits is a much smarter way to frame it.
The part that gets really interesting to me is how this plays out in regulated environments. When an auditor asks "was this code AI-generated?", a yes/no answer doesn't capture reality anymore. Having a provenance score that shows "70% of the original structure is still AI-derived" gives everyone something concrete to work with instead of guessing. That alone could save teams a lot of painful compliance conversations.
Lineage Lens
@nolan_vu I think that spectrum framing is much closer to reality than a binary label. In practice, AI-assisted development often becomes layered collaboration between prompts, generated structure, human rewrites, reviewer decisions, and later refactors.
The regulated-environment point is especially interesting to me because compliance systems usually want categorical answers while the underlying provenance is probabilistic and evolutionary. A gradual lineage/confidence model may end up being more operationally honest than pretending there is a clean boundary where code suddenly becomes fully “human.”
@praveen62 Yeah, "layered collaboration" is exactly the right way to describe it. Prompts set the intent, generated structure gives you the skeleton, then humans rewrite chunks, reviewers push back, and refactors happen weeks later. By the time something ships, the lineage is genuinely messy and a binary label just doesn't hold up.
The compliance angle is the part I keep thinking about too. Auditors want a clean yes/no but the reality is probabilistic by nature. A confidence-based model is actually more defensible in an audit than a hard claim that might fall apart under scrutiny.
Lineage Lens
Drop your comments below!!
Lineage Lens
@tehreem_fatima5 I think that separation may ultimately be the cleaner model. Right now the merged score is intentionally opinionated because incomplete provenance genuinely increases operational risk, but I also agree there’s a meaningful difference between “this code appears dangerous” and “we cannot fully explain how this code came into existence.”
A split between “Code Risk” and “Auditability/Confidence” could preserve that distinction while still allowing organizations to combine them into a higher-level governance decision if they want. It also makes the explanation surface much clearer and probably reduces the risk of users interpreting missing observability as equivalent to malicious code patterns.
PopShort.Al -Stream Short Drama
As a user, I'd probably trust the score more if I could see something like:
Risk: 42
Observability: 76%
instead of having observability gaps folded directly into the risk score.
Lineage Lens
@elara_thorn I actually think that’s a very reasonable framing. Separating “intrinsic code risk” from “observability confidence” may make the system easier to reason about operationally.
Right now the score intentionally mixes both because incomplete capture weakens auditability, but I agree there’s a conceptual difference between “this code appears dangerous” and “we cannot fully explain how this code was generated.” Exposing those as parallel dimensions instead of one merged number may ultimately produce a more honest trust model.
I’d separate this into two numbers: code risk and evidence quality. Missing prompt capture is a real audit gap, but teams will trust the tool more if the UI makes clear whether it found risky code or just low-confidence provenance. The merged score can work as a gate, but the explanation trail matters a lot.
Lineage Lens
@new_user___2672025cf1bc18102609b53 I think that distinction is very important. A merged score can be useful operationally because incomplete provenance genuinely increases governance risk, but teams also need to understand why the score increased.
Separating “code risk” from “evidence quality” may ultimately create a more trustworthy mental model: one dimension answers “how dangerous does this code appear?” while the other answers “how confidently can we defend the provenance behind it?”
Without that explanation layer, the score can start feeling opaque even if the underlying rules are deterministic.
Agreed. If you keep the merged score, I’d make the breakdown impossible to miss: “code pattern risk” vs “provenance confidence” as separate reasons. That way the score can still block a risky merge, but reviewers know whether to inspect the code itself or fix the capture pipeline.