Modern cars have a diagnostic port under the steering wheel. Plug in a cheap adapter, and you can read part of what the car already knows: fault codes, sensor values, and in some cases module-level state.
The data is not always complete, and it is not always easy to interpret. But the important point is that the machine is already talking.
Plenty of tools can read it. Far fewer can explain it well.
What a mechanic actually does is fascinating if you think about it. They plug in a scan tool, get a code like B1310, then spend the next few minutes cross-referencing that code against their experience, the service manual for that specific model and year, the symptoms the owner described, and whatever other codes showed up on other modules. The code itself is just a pointer. The cross-referencing is the skill. And that skill takes years to build.
Cars are not special in this regard. HVAC systems spit out fault codes. Industrial PLCs log errors to standard protocols. Marine engines, building management systems, warehouse equipment, factory lines. All of them generate structured diagnostic data through documented protocols. All of that data is there, waiting for someone with enough training to interpret it.
The problem is not access. The problem is interpretation.
I know this because my convertible roof broke, and I spent weeks confused by it.
The broken roof
My 2010 Ford Focus CC is a hardtop convertible. The roof folds into the trunk in about 30 seconds. Or it used to, until the passenger window regulator failed. The cable-pulley mechanism inside the door broke, the motor spins but the glass doesn't move, and the roof refuses to operate.
The confusing part: when I scanned the car's computers, the roof module reported zero errors. Nothing. Clean. The mechanic fixed the window position in place, the roof worked exactly once, then stopped again. And still, no error codes on the roof.
I'm a software developer, not a car mechanic. But I had a hunch. What if the roof module wasn't broken at all? What if it was doing exactly what it was designed to do, and the real problem was somewhere else entirely?
So I did what felt natural as a developer: I exposed the diagnostic data to an AI through a small tool and asked it to explain the pattern.
Connecting the scattered pieces
I built a small piece of software that lets Claude (Anthropic's AI) access diagnostic data through MCP, a protocol for exposing tools to AI systems. The technical details are in the full build story, but what matters here isn't the code. It's what happened when the AI could see all the pieces at once.
For the experiment, I exposed the relevant diagnostic state to Claude through the MCP tool: the same module scan I had seen in FORScan (a popular car diagnostic tool), plus a local fault-code lookup database I had scraped from public references. The roof module was clean, zero errors, just like before. But the passenger door module had two fault codes: a power door unlock circuit failure and a heated mirror circuit issue.
Then I asked the question that had been bugging me for weeks: "The roof won't operate, but the roof module has no errors. Why?"
The answer was not hidden. It was scattered. Part of it was in the module scan. Part of it was in the fault-code descriptions. Part of it was in how convertible roof sequences work. Claude's useful contribution was pulling those pieces into one explanation.
It explained that the roof controller, before it starts the folding sequence, sends a command to the door modules: "lower the window slightly." This is a safety check. The roof needs to confirm the windows are clear before folding over them. If the window can't move, the sequence aborts. But it doesn't store an error, because from the roof module's perspective, nothing is broken. It asked the window to move, the window didn't move, so it stopped. That's not a fault. That's the system working as designed.
The actual problem was on the door module. The window regulator is broken, so the "lower window" command always fails. The roof gives up every time. But the error codes that explain why are on a completely different computer, in a completely different part of the car.
No mechanic had explained it to me that way. Claude produced the same working hypothesis almost immediately: the problem was not the roof module failing, but a prerequisite system the roof depends on. I haven't confirmed this by replacing the regulator yet, but it matched what I later found in Ford service documentation.
Why this matters beyond my car
Here's what got me thinking. The AI didn't do anything magical. It read some structured data exposed through a narrow set of tools. It looked up fault codes in a database. And it combined all of that with general knowledge about how convertible roof mechanisms work. Each piece of that information existed somewhere already: in the car's memory, in diagnostic code databases, in automotive engineering documentation. But they existed in separate silos. The car doesn't know what its own codes mean in plain language. The code database doesn't know how Ford's roof sequencing works. The engineering documentation doesn't know what's specifically wrong with my car.
The mechanic's job has always been to be the human glue between all of these sources. Read the codes, check the manual, apply experience, explain to the customer.
What I built as a small prototype, with a cheap Bluetooth dongle, essentially gave the AI the ability to be that glue for first-pass explanations. And it turns out AI is remarkably good at this particular task. Not because it's smarter than a mechanic, but because cross-referencing structured data against a broad knowledge base and producing a coherent explanation is literally what language models do.
Now think about every other industry where the same pattern exists.
An HVAC technician stares at fault codes from a rooftop unit and cross-references them against the unit's service history, the building's configuration, and their own experience. A marine engineer reads engine diagnostics on a cargo ship and decides whether it's safe to continue the voyage. An electrician troubleshoots a PLC on a factory floor, matching error logs against wiring diagrams and the machine's operating manual.
Many of these scenarios follow the same shape: structured data comes out of a standard protocol, a trained human interprets it using domain knowledge, and the result is a plain-language explanation or decision. The protocol part is often less mysterious than it looks. Cars have OBD-II. Buildings have BACnet. Industrial systems often expose Modbus, OPC UA, or vendor APIs. These interfaces are not always clean, complete, or safe to automate, but they already exist.
The interpretation part still benefits from years of training. But for many first-pass explanations, triage steps, and operator-facing summaries, it just became much easier to augment.
What this doesn't replace
I want to be clear about something: the AI didn't fix my car. The window regulator is still broken. The roof still won't fold. I still need to take the door panel off, remove the old cable-pulley mechanism, install a new one, and recalibrate everything. No amount of AI is going to do that for me.
And I think that's actually the important distinction. There are two separate skills in any repair or diagnostic job. The first is understanding what's wrong. The second is physically fixing it. AI can help with the first, especially the pattern-matching and cross-referencing parts. It can read the data, connect it to broader knowledge, and explain what's happening in words anyone can understand. But the second skill, the hands-on part, still belongs to humans. Probably for a long time.
The value isn't in replacing the expert. It's in making the expert's knowledge accessible to everyone else. Right now, if your car throws a check engine light, you have two options: pay a mechanic to diagnose it, or Google the error code and hope someone on a forum had the same problem with the same car. The first option costs money and time. The second is unreliable. There's a huge gap in between, where you could understand what's happening with your own equipment if someone (or something) just explained it to you.
That gap is what AI fills. Not the wrench. The explanation.
The bigger pattern
What surprised me most about this project wasn't that it worked. It was how little code it took. The prototype bridge between the diagnostic data and Claude is about 250 lines. The protocol was already standardized. The diagnostic port was already there. The model already had general knowledge about automotive systems. All I had to do was connect the pieces.
And that's the pattern I keep coming back to. The physical world is full of machines that already speak. They speak in fault codes, registers, event logs, sensor values, and protocol-specific messages.
The opportunity is not to make AI "control" those machines. In most cases, it shouldn't. The opportunity is to build a safe explanation layer over the data they already produce. That means deciding which data to expose, which actions to forbid, how to preserve auditability, and how to combine live state with domain knowledge safely.
I open-sourced the car diagnostic tool because I think this idea is bigger than one broken convertible. If you're in HVAC, or marine engineering, or industrial automation, or building management, you're sitting on the same opportunity. Your machines already talk. The documentation may be ugly, incomplete, or vendor-specific, but the signals are there. The missing piece is the bridge: narrow tools, read-only access where possible, domain context, and a model that can turn machine state into language.
The bridge is no longer the impossible part. The hard part is building it responsibly: deciding what to expose, what to forbid, how to preserve auditability, and where the human stays in control. But the explanation layer, the part that turns machine state into something a person can reason about, is suddenly much easier to build.
This is the kind of interface more companies will need: not another dashboard, but a safe translation layer between operational systems and the people who depend on them.
The machines are already talking. We finally have a better way to listen.
*The technical build story, with code and setup instructions, is here: github.com/petrpatek/obd2-mcp-server*
