PagingDr.Glitch

A smart AI troubleshooting assistant who bears pysician mindset---- recommends one high-information diagnostic test at a time, updates competing hypotheses with each result.

Comment

Inspiration

I come from a clinical medicine background, but recently I have been spending a lot of time learning Python, Linux, PyTorch, and software development.

As a beginner, I debug things almost every day. I often ask ChatGPT for help, but the answer can quickly become overwhelming: several possible causes, many commands to try, and multiple fixes presented at the same time. Even when the suggestions are correct, I still do not know which test I should run first or how the new result should change my thinking.

That experience reminded me of clinical diagnosis. Doctors do not order every possible test at once. We keep a differential diagnosis, look at the evidence, and choose the next test that is most likely to change the decision.

That became the idea behind PagingDr.Glitch.

What it does

PagingDr.Glitch is an evidence-driven troubleshooting assistant.

Instead of giving the user a long checklist, it:

  1. Builds several competing hypotheses
  2. Shows evidence for and against each one
  3. Recommends one useful diagnostic test
  4. Lets the user record what happened
  5. Updates the hypotheses using the new evidence
  6. Recommends another test or produces a final resolution report

NextTest never runs commands on the user’s computer. It only explains what to test and why.

The project has two modes:

  • AI Analysis for new troubleshooting cases
  • Local Demo for a complete PyTorch and VS Code debugging example that works without API credits

How I built it

PagingDr.Glitch is built with Next.js, React, TypeScript, Zod, and the OpenAI Responses API.

I used Structured Outputs so the model must return a predictable diagnostic state instead of arbitrary text. The response includes hypotheses, evidence, one next test, possible outcomes, a timeline event, and a resolution report when the case is solved.

I also added a second validation layer in the application. It checks rules such as:

  • Hypothesis IDs must be unique
  • Scores must total 100 during an investigation
  • There must be exactly one next test
  • Resolved cases cannot contain another test
  • Potentially destructive tests are rejected

The app has two server endpoints:

  • POST /api/nexttest/analyze
  • POST /api/nexttest/update

The first creates the initial analysis. The second takes the user’s observed result and returns a complete updated diagnostic state.

Codex helped me inspect the codebase, implement features, write tests, and fix problems. Since I had very little web development experience, I worked in small steps and manually checked each major change.

Challenges

The hardest part was not making an AI answer a debugging question. Chatbots can already do that.

The harder problem was turning the reasoning into a reliable workflow:

  • How do I make the model recommend only one test?
  • How do I prevent old evidence from staying on the screen after a test is completed?
  • How do I preserve the user’s previous state when an API request fails?
  • How do I keep the commands safe and read-only?
  • How do I make the experience useful even when API credits are unavailable?

To solve this, I separated the AI output schema from the application’s safety and consistency checks. I also built a deterministic Local Demo and mocked all OpenAI requests in automated tests.

What I learned

This was my first multi-turn AI web application.

I learned that building an AI product is not only about writing a good prompt. The state, validation rules, failure behavior, and user interface matter just as much as the model response.

I also realized that debugging and clinical diagnosis are surprisingly similar:

  • Keep several explanations open
  • Separate evidence from conclusions
  • Choose tests with high information value
  • Update your judgment when new evidence arrives

The project currently passes 41 automated tests, along with linting, type checking, and production builds.

What's next

I would like to add:

  • Screenshot and log analysis
  • Persistent troubleshooting sessions
  • Shareable investigation reports
  • IDE integration
  • Support for more debugging domains
  • Evaluation on real troubleshooting cases

My long-term goal is not to replace developers or support engineers. It is to make debugging less confusing and help people learn how to reason from evidence, one useful test at a time.

Built With

Share this project:

Updates