CodeSentinel

Inspect AI code repairs with static checks, TypeScript verification and reviewable evidence, powered by NVIDIA Nemotron on Nebius.

Comment

Inspiration

Automation scripts often sit between a webhook, a credential and an external action. A repair that removes a warning can still break the handler or leave a notification unguarded. Developers need to inspect both the proposed change and the evidence behind its acceptance.

CodeSentinel focuses on that review boundary: a bounded TypeScript repair workflow with explicit checks, source comparison and honest verification limits.

What it does

Paste a single-file TypeScript automation script, analyze configured findings, then inspect a repair proposal. The workspace shows original and returned source, remaining findings and downloadable run evidence. A CLI provides the same audit and repair workflow.

Configured rules target hardcoded credentials, external notifications without the supported approval guard, and malformed workflow expressions. Candidate repairs pass through non-empty output checks, supported AST export/signature constraints, TypeScript semantic diagnostics and a score anti-regression check. An accepted improvement with unresolved findings is PARTIAL; the CLI refuses to apply it as a successful repair.

Generated code is never executed by these checks. A score of 100 means no configured findings remain; runtime behavior and business equivalence remain NOT_VERIFIED.

How we built it

The interface uses Next.js 15, React 19, TypeScript and Tailwind CSS. The backend combines deterministic rules, the TypeScript Compiler API, Zod validation and an OpenAI-compatible client for Nebius Token Factory.

NVIDIA Nemotron proposes repairs through the Token Factory inference API. Each run has a shared limit of two inference requests, at most 4,000 output tokens per request, an 8,192-byte serialized request cap and zero automatic SDK retries. The orchestration loop is capped at three iterations. Source comparison and verification evidence remain available for developer review.

Nebius and NVIDIA integration

We integrated the Token Factory inference endpoint and made one controlled real request on 28 October 2026 using nvidia/nemotron-3-super-120b-a12b. On a small fixture with an explicitly fictitious credential, the returned repair replaced the hardcoded value with process.env.API_CREDENTIAL and passed the configured static, TypeScript and fixture structure checks.

Saved evidence includes the provider response ID, raw response, request budget and usage: 143 prompt tokens plus 736 completion tokens. This is one observed repair, not a reliability or latency benchmark. Nano is configured as a fallback but was not exercised in this call. Nebius AI Cloud compute was not used.

The video separates the deterministic interface walkthrough, labelled MOCK_SIMULATED, from the saved real Nemotron response. They are different fixtures; the three-issue interface demonstration is not presented as live inference.

Challenges we ran into

The difficult part was defining what a repaired result can honestly promise. We added explicit PARTIAL outcomes, bounded inference, supported structural checks and a visible NOT_VERIFIED runtime boundary instead of treating a model's explanation as proof. We also aligned the model prompt with the exact helper symbols available to the TypeScript verifier.

Accomplishments and what we learned

The final release passed 98 automated unit, route and CLI tests in offline mode, plus type checking and a production build on a curated source export. Earlier interface validation recorded 30 browser checks. Fourteen focused guardrail checks are shown in the video.

Judge testing instructions provide a local test build and reproducible deterministic walkthrough without an API key or inference charges. The saved real response can be inspected without another paid call. Optional live mode is documented separately and may incur provider charges.

We learned that repair quality needs separate signals: a model proposal, configured findings, TypeScript diagnostics, supported structure and a readable diff. None alone proves business correctness.

Potential impact and what's next

The intended audience is developers reviewing webhook and automation scripts. CodeSentinel helps them examine a suggested repair and reject unsupported changes before applying it. We have not measured production incident reduction or developer time savings.

Next steps are optional isolated runtime tests, broader multi-file support and CI integrations. These are future work, not current capabilities.

The project is open source under the MIT license. The demo uses English narration generated with ElevenLabs and English captions.

Built With

Share this project:

Updates

Submission history