Should you trust
AI-generated code?

TAOL is a middleware that screens every AI coding request before it wastes compute, scores the generated output for risk, and tells you whether to apply it, review it, or write it yourself.

Try the Demo

Screens Prompts

Before any code is generated, an Intent Gate checks if your request is specific enough. Vague prompts are rejected with clarification questions — saving compute and avoiding bad output.

Scores Risk

After code is generated, four independent signals analyze it for lint errors, codebase alignment, semantic similarity, and risky dependencies.

Routes to Action

The risk signals are combined into a single trust score that routes the output to one of three zones:

Auto Apply Human Review Defer
The Pipeline

Six phases, one trust decision

Every request passes through the full pipeline. Each phase builds on the last to produce a calibrated trust score.

1
Input
Your repository and coding prompt are submitted to the system.
2
Index Codebase
Builds an AST index and BM25 search over every function, class, and method.
3
Screen Prompt
A trained classifier checks if the prompt is specific enough to generate useful code.
4
Generate Code
The enriched prompt is sent to the LLM. A circuit breaker guards against runaway output.
5
Score Output
Four risk signals analyze the generated code for quality, alignment, and safety.
6
Route Decision
Signals combine into a Composite Trust Score that routes to the right zone.
Interactive Demo

Try it yourself

Pick an example or write your own prompt. See how TAOL routes different types of requests through the full pipeline.

Examples:
Under the Hood

How TAOL Works

Three layers of analysis, explained simply first and then in full technical detail.

1 Intent Gate Pre-generation prompt screening

Before TAOL sends anything to an AI model, it checks whether your prompt is clear enough. A Random Forest classifier trained on 4,000 labeled prompts evaluates how specific and actionable your request is. If it fails, you get targeted clarification questions instead of wasted compute.

ISI — Input Specificity Index: counts file paths, function names, class names, error codes, code blocks, library references
IE — Interpretation Entropy: how many different ways can the prompt be read? Uses embedding similarity to measure ambiguity
Reachability — Reachability Gap: do the entities mentioned in the prompt actually exist in the codebase?
Quality Score — RF Classifier P(good): probability the prompt is good and actionable. Accuracy: 99.2% on 500 held-out prompts
Thresholds — Quality > 0.50: proceed. Quality 0.30–0.50: enrich with retrieved code context. Quality < 0.30: defer with clarification questions
2 Trust Signals Post-generation code analysis

After code is generated, four independent checks analyze the output. Each signal measures a different dimension of risk, from lint errors to whether the generated code actually aligns with the existing codebase.

SAG (w=0.089) — Code Quality Check: runs ruff linter. Severity weights: error=0.3, warning=0.1, security=0.5. Lower is better.
FO (w=0.270) — Function Coverage: Jaccard overlap between generated function names and codebase functions. Higher is better.
CB (w=0.547) — Semantic Similarity: n-gram code similarity with existing codebase patterns. Dominant signal — highest weight. Higher is better.
DV (w=0.094) — Dependency Safety: checks for new/unknown packages not in requirements.txt. Higher is better (no risky new deps).
3 Composite Trust Score Routing formula and thresholds

The four signals are combined into a single Composite Trust Score (CTS) using learned weights trained on 500 real-world GitHub issues from SWE-bench Verified. Higher CTS means more risk. Thresholds divide the score into three action zones.

Formula — CTS = ∑ wi · σ(signali), where σ is the sigmoid function. All signals oriented so higher = more risk.
τ1 = 0.6514 — Below this: Auto Apply. Code is safe to apply without review.
τ2 = 0.7839 — Above this: Defer to Human. Too risky — write it yourself.
Override — Any single signal > 0.9 forces Human Review regardless of CTS.
Training — Weights learned via ensemble (Logistic Regression + Random Forest + Gradient Boosting) with grid search on N=500 SWE-bench Verified instances.