Inspiration
As a beginner programmer, I was constantly confused and discouraged by ModuleNotFoundError. I couldn't even start programming. I was already drowning in errors that had nothing to do with the code I was trying to write. The terminal told me a package was missing, but never why: which of the several Pythons on my machine my project was actually using, or where things had gone wrong. For beginner programmers, my story isn't just an example; it's literally a canon event. Sphere is the tool I wish I'd had: one that makes the invisible state of your machine visible, so the wall that stops so many people before they begin becomes something you can actually see and understand.
What it does
Sphere shows you the real state of your machine's Python setup as a live, interactive graph: every interpreter, every environment, and every installed package. It figures out which interpreter a given folder actually resolves to, then checks whether that interpreter can satisfy the project's requirements, showing each dependency as satisfied, version-mismatched, or missing. Crucially, it doesn't ask you to trust it: click any claim and Sphere shows the exact command it ran against that interpreter and what came back: a citation, not an opinion. And it doesn't just diagnose; it fixes. Sphere turns a broken environment into a working one, creating an isolated environment where one is needed rather than polluting your global Python, and re-scans to prove the fix worked instead of assuming it.
How we built it
Sphere is a Python backend and a React front-end. The backend is a truth engine: it discovers interpreters across every install method (PATH, pyenv, uv, Homebrew, conda), and reads each one's packages by running that interpreter in an isolated subprocess, so the data is the interpreter's own ground truth, never a guess. It diffs a project's declared requirements against that reality using correct version-specifier and package-name logic. The front-end renders this as a spherical graph with a per-claim evidence layer and a preview-then-execute fix loop. I built the core, the introspection engine and the fix loop, with Codex, and used GPT-5.6 to power the plain-English diagnosis layer that explains problems and proposes fixes for beginners.
Challenges we ran into
The hardest problems were about trust, because Sphere's whole value is being provably correct. Reading each environment's true package state meant running isolated subprocesses so an active shell couldn't contaminate the results, and we caught Sphere itself polluting the global Python with its own dependencies, the exact anti-pattern it warns against, which we fixed by making it install fully isolated. Building the verification layer meant capturing the actual command executed rather than reconstructing a plausible one: a fake receipt would have been worse than no receipt. And a subtle but critical bug: a failed fix once rendered as green "success," which would have broken the entire trust thesis. We caught it by deliberately testing the failure path, not just the happy path.
Accomplishments that we're proud of
This is a beginning to a tool that never lies about your machine, something I'm not only incredibly passionate about, but also proud of. Every red edge and version number is something Sphere read directly from an interpreter and can prove with the exact command it ran. We're proud that the deterministic core works with zero API keys and zero network: the AI is an enhancement, not a crutch, and that Sphere practices what it preaches by never polluting the environments it inspects. Most of all, we built the full arc: not just diagnose, but prove, fix, and verify; a broken project going green, live, because a fresh scan confirmed it.
What we learned
That the hard part of a developer tool often isn't the feature; instead, it's being correct, and being able to prove it. We learned how deep the machinery under a simple ModuleNotFoundError really goes: interpreter resolution, PATH, environment isolation, the difference between a package being installed and being installed where your code will actually look for it. And we learned that the right division of labor with AI is deterministic code where correctness matters and language models where explanation and judgment matter: facts first, narration second.
What's next for Sphere (Orbis)
Sphere's model is ecosystem-agnostic: Python is fully implemented, and the same graph extends naturally to other worlds: JavaScript and node_modules, then the "why doesn't this run on my machine" problem beyond a single language: CUDA toolchains, Docker images, and eventually Kubernetes and external vendors. The long-term vision (Orbis) is a single visible, verifiable map of everything a project needs to run, whoever or whatever is doing the fixing, human or agent. As AI does more to our systems, the layer that lets us see and trust what it changed only becomes more essential.
ChatGPT Feedback Session
019f7162-3fd6-7b72-9fa3-c3a2f2bc87d4
Log in or sign up for Devpost to join the conversation.