AI Driven SDLC
Login

AI Driven SDLC Documentation

Guides, references, and best practices for the AI Driven SDLC platform.

Code Insights


Code Insights

Code Insights shows deterministic code-quality metrics collected during Agentic Foundation readiness scans — complexity, duplication, structure heuristics, hotspots, and threshold-based findings. Values are stored per scan; the page always shows the latest snapshot per repository. On each repository detail page, Design risks is a separate, on-demand AI analysis for semantic issues (antipatterns, error handling, and related detectors) — see Design risks below.

Note: Code Insights is separate from Integrations → Code quality (SonarQube). Sonar contributes org-level coverage and technical debt when connected; per-repo Sonar mapping is a later enhancement.

How to open it

In the app sidebar, expand SDLC Insights and choose Code Insights, or go directly to /insights/code.

What you see

Org summary

  • Repositories measured vs still pending a first metrics scan. When measured is 0, the page leads with those coverage counts instead of median quality stats.
  • Unweighted median cyclomatic complexity (CC) and duplication % across measured repos
  • Unweighted median cyclomatic complexity (CC) and duplication % across measured repos
  • Findings counts by severity (workspace total), shown as a compact severity strip under the summary cards
  • Org-level SonarQube coverage / tech-debt ratio when a SonarQube source is connected

Medians are unweighted (each repo counts equally). Large monorepos are not down-weighted.

Per-repository table

Search and sort repositories by name, LOC, average CC, duplication, or last measured time. Threshold badges call out god files, high complexity, duplication, DTO/mapper proliferation, and low test-to-source ratio.

Repository detail

Latest metrics with a provenance badge per field:

Provenance Meaning
Measured Direct tool output (e.g. lizard CC, jscpd duplication)
Derived Computed from measured inputs (e.g. maintainability band from CC + LOC)
Estimated Heuristic proxy (e.g. test LOC / source LOC — not true coverage)
Unavailable Tool missing/failed or language unsupported — shown as , never 0

Hotspots list the worst files (LOC, CC, flags). Flag icons (god file, high complexity, long parameter list, deep nesting) each have their own color; the table footer is the legend. Numbers still use amber/red for magnitude. Use Next step on a flagged hotspot for the peak function (name and line range — opens that function in the VCS), one play from the flags, and View finding when the file is in a Measured complexity finding. Findings are Measured (threshold-based) results from the latest readiness scan. Design risks is a third section for on-demand AI-detected findings — run it when you want a fresh semantic review.

Thresholds (v1)

Rule Trigger Severity
God file File LOC > 1000 or function CC > 50 (medium at LOC > 500 / CC > 20) High / medium
High complexity (repo) cc_p90 > 20 (medium when average CC > 10) High / medium
Duplication Duplicated lines ≥ 10% (medium at ≥ 5%) High / medium
Proliferation DTO + mapper LOC share ≥ 15% of repo LOC (medium at ≥ 8%) High / medium
Low test ratio Test LOC / source LOC < 0.15 Medium (estimated)

When metrics appear

Metrics are collected during readiness scans (scheduled or on-demand from Agentic Foundation). Repositories over the readiness size/LOC cap may skip LLM grading but can still receive Code Insights metrics. Tool failures never fail the readiness run — that repo’s metrics status is marked failed/skipped and the scan continues.

Design risks

Design risks is an on-demand analysis on the repository detail page. It does not run during Agentic Foundation readiness scans and does not affect readiness scores.

Use Run analysis in the Design risks section. The job shares the same worker queue as readiness scans (so it may wait if a scan is already running). Successful runs update Design risks findings for that repository; failed runs leave the last successful results unchanged. Until the first successful run, the section stays empty.

Design risks includes:

  • Measured coupling findings from the repository import graph (circular dependencies, high fan-in)
  • AI-detected semantic findings (antipatterns, error handling, and related detectors) with evidence (file, line range, snippet)

Always verify evidence before changing code.

Detectors

Detector Badge What it looks for
Circular dependencies Measured Files that form an import cycle (strongly connected component)
High fan-in Measured A file imported by many other files (change-risk hotspot)
Anemic domain AI-detected A “domain” class that only holds data while another class does the business logic that should live on it
Context leak AI-detected Request-scoped or thread-local state that isn’t cleaned up, risking data bleeding across requests
Transaction boundary AI-detected A transaction that reaches across an external call or multiple data stores without a safe rollback/outbox path
Error handling AI-detected An exception caught and silently swallowed (or logged and ignored) instead of being handled or propagated
Config cohesion AI-detected Near-duplicate configuration modules (datasources, Mongo contexts, cloud clients)
Resilience patterns AI-detected External messaging/HTTP calls without timeout, retry, or circuit breaker

Layer-boundary rules (allowed architecture layers) are not configured in the product yet, so layer-violation findings are not included.

Measured Findings in the Findings section (god file, duplication, proliferation, test ratio, etc.) stay from readiness scans only.

Supported stacks

Stack Detectors
JVM (Java/Kotlin backend) Coupling (graph) + all six semantic detectors
TypeScript / JavaScript (web SPA / Node) Coupling (graph) + all six semantic detectors
Go Coupling (graph) + all six semantic detectors
Python Coupling (graph) + all six semantic detectors
iOS (Swift) Error handling only for semantic pack (other packs roll out as fixtures mature); coupling when imports resolve

Accuracy expectations

Coupling findings come from static import analysis and can miss dynamic or unresolved imports. Semantic findings use a language model — treat them as a starting point and check the cited evidence before acting. The model is tuned to avoid noise (no finding without evidence; capped findings per run) but can still miss issues or misjudge intent.

Exporting Code Insights

From a repository detail page (/insights/code/repos/{repoId}), use Export in the page header to download a structured report of the latest scan. The layout is designed for IDE and coding-agent workflows (summary stats, hotspot table, and findings with remediation and evidence), similar in spirit to a Cursor Canvas inventory.

Format Best for
Markdown (.md) Paste into your editor or attach to an agent session; includes code snippets for AI-detected findings
PDF (.pdf) Sharing with teammates or printing a snapshot

Export is available when the repository has completed at least one metrics scan and the latest snapshot has at least one finding or hotspot. If the repo is still Pending first scan, or the scan produced no findings and no hotspots, Export stays disabled.

How to use the export

  1. Open the repository in your local checkout (same branch you intend to fix).
  2. Work findings from critical to low; use section 2. Hotspots for refactor targets. Expand a hotspot in the app for the peak function and a one-line play.
  3. For each finding, read Remediation and Evidence; for AI-detected rows, confirm the cited file and snippet before changing code.
  4. Re-run an Agentic Foundation scan after fixes to refresh Code Insights.

Exports include branch and commit in the header when the metrics row is linked to a readiness run (seed-only runs may omit them). Repo-wide findings list Suggested files from scan evidence (top duplicated files, DTO/mapper files, clone pairs, and hotspot paths when available) and fall back to the hotspot table for older scans.

Use How to use export next to the Export control for this page on the live docs site.