AutoFix 2000

Fix, Don’t Switch: Smarter car diagnostics, less waste.

Comment

Inspiration

I was inspired the abnormally large 2005 Ford Explorer I drove in high school. Every day was a gamble: sometimes the car would start, sometimes it wouldn't. I vividly remember waiting in my school's parking lot for 2 hours because the car wouldn't start (mind you, this was a on a hot day in California), only for it start up randomly as I waited for someone to pick me up. The amount of repair costs that went into trying to fix the problem was high, and none of the efforts to fix it worked.

After nearly 5 years of dealing with this issue, the car has finally been fixed (presumably). The issue was simple, a faulty wire within the starter system. The issue was that we were not car experts, and the countless mechanics we went to kept misdiagnosing the issue to the inner electrical wirings.

This inspired me to create a dynamic system that not only teaches you how to diagnose your car, but points you in the right direction at fixing that issue rather than replacing everything and hoping it works out. This also leads to decreased waste. In fact, in researching about improper diagnostics, it was found that approximately 40% of all auto repair costs are considered unnecessary. This translates to over $20 billion annually in consumer losses, driven by unnecessary repairs, wasted parts, and improper fixes.

What it does

We built an AI-powered car troubleshooting system that generates hypotheses and reasons through the issue your describing about your car. It generates hypotheses, asks targeted questions, updates probabilities, and explains its conclusions, modeled after a real mechanic.

It utilizes a "Diagnosis Confidence" rating to ensure that what results is backed up in the empirical data you are providing. Once passing a confidence rating of 80%, you are given a diagnosis, follow-up steps, and a rundown of sustainability statistics. These statistics provide information about potential wasteful practices that could have happened if you car had not received a proper diagnosis. By preventing misdiagnosis, we reduce unnecessary repairs, saving money and reducing environmental waste.

A reasoning panel is showcased as well so you can actively see the factors being considered and potential hypotheses throughout the diagnostic process. This reasoning is exactly where the integration of K2 Think V2 branches off from a typical LLM. Where you might be given a list of generic, somewhat related, causes for your car's issue, the diagnosis confidence rating along with the deep reasoning involved here allow for a streamlined inspection that closely mimics receiving an inspection from a mechanic.

How it was built

Used Orchid AI to design and generate the frontend UI, including the landing page, diagnostic session interface, and results page. Designed the backend by creating a server with Express.js running on Node.js, which handles API routing.

Made backend API calls to the K2 Think V2 API, prompted it to act as an expert car diagnostic reasoning system that generates step-by-step mechanic-style reasoning, produces multiple hypotheses with probabilities, asks targeted questions one at a time to maximize diagnostic efficiency, and estimates waste and money saved by avoiding unnecessary repairs. Because K2 does not reliably return structured data, the raw response was passed to the Elephant API (OpenRouter) as a fallback parser to extract and organize the output into proper JSON. This structured JSON was then sent back to the frontend to dynamically update the diagnostic interface, including the hypothesis panel, confidence meter, waste tracker, and question display.

Challenges

One of the main challenges was getting K2 to reliably return responses in structured JSON format. Despite explicit instructions in the system prompt, K2 would frequently return plain text reasoning or wrap the JSON in additional commentary, requiring a multi-step parsing pipeline on the backend. The solution was to include another AI API to parse K2's response into valid JSON.

Additionally, the K2 system prompt had a tendency to generate inspection-type questions without sufficient guidance for the user on how to actually perform them. This required iterative prompt engineering to ensure that every inspection request included clear, plain-language instructions on exactly what to look for and where, accounting for the fact that most users have little to no mechanical background.

Working with the Orchid-generated frontend also presented challenges, as the dynamic nature of the generated code required manual intervention to correct the question display logic. Specifically, answer options would sometimes fail to render correctly, and the free-text input box was not consistently available across all question types. I had to restructure of the conditional rendering logic to ensure the text input appeared for every question regardless of type.

Accomplishments

The accomplishment I'm most proud of is diagnosing and solving the JSON parsing pipeline problem that K2 presented. When K2 first started returning plain-text responses instead of structured JSON, the frontend would crash entirely with parsing errors. Rather than switching to a different model, I designed a multi-layer parsing solution entirely on the backend so the frontend would never have to handle raw K2 output.

The pipeline works in three stages. First, the raw K2 response is attempted to be parsed directly, if K2 returned clean JSON, it moved on. If that fails, the raw response is forwarded to the Elephant API through OpenRouter, which is prompted to extract and reformat the content into the exact JSON schema the frontend expects. The result is then sliced between the first { and last } to strip any residual text before being parsed and returned.

What also helped was telling K2 Think to include a properly formatted JSON response at the end of every response. This allowed me to prompt Elephant to start by looking at the end of the message to get the proper JSON format needed.

Learned

I'd never worked with external AI APIs before this, and so through this project I was able to learn how they work, how to authenticate requests, how to write system prompts that actually get the model to do what you want [AI models don't always have the best memory....] I rewrote the K2 system prompt more times than I can count to get it to finally work.

What's next for AutoFix 2000

More work on the prompting....

Built With

Share this project:

Updates

Submission history