Code Séance: a local AI second opinion for haunted code

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine.

What I built

Some bugs are easy to reproduce and annoying to explain. Python's mutable default arguments are a good example: a function seems to remember an earlier call, as if something stayed behind after it returned.

Code Séance gives those little ghosts a place to show themselves. Paste a short snippet, choose its language, and summon a plain-English explanation, possible bugs, and a suggested fix. The interface supports JavaScript, TypeScript, Python, Go, and Rust.

I kept the Halloween theme in the interface: a dark workspace, a floating ghost, an "incantation" editor, and a "revelation" panel. The output itself needs to stay readable. A spooky metaphor should not make a bug harder to understand.

Demo

Watch the 57-second local inference walkthrough.

The app runs locally. The included 57-second walkthrough shows the actual Go sample running through Ollama, a result labeled Local AI result, the suggested fix, and report export. The recorded request took about 38.9 seconds while screen capture and encoding were active. Built-in sample previews are explicitly labeled and do not count as AI inference.

Code

Code Séance on GitHub.

The repository includes the application source, local backend, tests, setup instructions, and raw real-inference records. Model weights are downloaded separately.

How I built it

I started the UI in Figma Make, then used Codex to implement the local backend and connect it to Ollama. The frontend uses React, TypeScript, Vite, and Tailwind CSS. The backend uses Node's HTTP server without an additional web framework.

The request takes a short route:

1. The browser sends the snippet and selected language to the local backend.
2. The backend validates the request and sends a system instruction plus a separate JSON-encoded code message to Ollama.
3. Ollama generates an explanation constrained by a JSON schema.
4. The backend validates that response before returning it to the interface.

A valid result contains a summary, an array of possible bugs, an improvement explanation, and suggested code. The interface renders those fields as text. It never executes a submitted snippet or a suggested fix.

One important correction happened during implementation. The initial exported preview returned a fixed JavaScript explanation even for unrelated input. I replaced that behavior with language-specific built-in examples and rejected custom input in sample-preview mode. An actual inference failure now produces an error rather than a canned answer.

I also moved the Ollama request out of the browser. A local backend avoids requiring users to configure browser-origin access to Ollama. Model settings can check whether Ollama is available and list installed models. Requests can be cancelled, have a two-minute timeout, and are limited to one inference at a time.

What the model tests taught me

Gemma 3 1B was the first model tested. It returned valid structured responses, but those responses were not reliable code reviews. It missed the shared mutable default in the Python example. For a valid JavaScript greeting function, it suggested a replacement that would break interpolation.

That distinction matters: matching a JSON schema proves that the interface can parse the response. It does not prove that the advice is correct.

I then tested Qwen2.5-Coder 3B and made it the default. With the final prompt, it correctly identified the Go sample's out-of-bounds loop condition and changed i <= len(numbers) to i < len(numbers). It also preserved a correct JavaScript greeting function. It still missed the Python mutable-default bug. I kept all of these results in the repository instead of treating a successful HTTP response as evidence that every review was right.

In this CPU test environment, the final Go request took about 12.6 seconds and the JavaScript request took about 4.4 seconds. These are individual observed runs, not a performance benchmark. The UI reports the measured time for each request.

The backend tests cover unavailable Ollama, missing models, invalid input, malformed output, timeout, and concurrent requests. Component tests cover the five sample languages, source labels, custom-input rejection in preview mode, settings, and report export. These controlled tests check the application behavior; they are separate from the real-model runs.

Why does open innovation matter?

The useful part of a local model is control over where the snippet goes. With the default setup, the browser, backend, and inference server all run on the same machine. After downloading the dependencies and model, there is no hosted AI API in the request path.

Model choice is also part of the application rather than a fixed service contract. I can compare a small general model with a coding model, keep the same interface, and inspect the differences. The weak first result made that ability useful immediately.

There are limits. Local inference uses RAM and CPU time, and a smaller model may give poor suggestions. The app is a second opinion, not a correctness checker. The model's suggested fix still needs a human review and appropriate tests. The interface says so, and it records which model generated each result.

Ollama is open-source. The model weights have their own licenses; those are not replaced by the application's MIT license. The README links to the relevant model terms.

The spirit of it

The ghost I wanted to catch was the bug that survives an otherwise ordinary-looking function call. The project turns that idea into a small, inspectable local tool. Its most useful feature may be how clearly it tells you where an answer came from, including when that answer is only a sample.

Credits

The UI was generated and refined in Figma Make. Codex assisted with implementation, testing, and this draft. The project uses React, Vite, Tailwind CSS, Node.js, and Ollama. Model credits and validation details are included in the repository.