SpecRAG

Inspiration

Embedded developers face a dangerous gap known as the "Silent Failure Problem". While modern IDEs and standard AI copilots excel at validating code syntax, they remain completely blind to physical hardware constraints. As a result, a developer can write perfectly compiling C++ code that inadvertently writes to read-only registers, violates timing constraints, or exceeds GPIO current limits. These undetected errors inevitably lead to weeks of oscilloscope debugging, expensive hardware damage, or even charred silicon. We were inspired to build a solution that transforms these costly "Runtime Disasters" into immediate "Compile-time Squiggles".

What it does

SpecRAG is a Context-Aware Hardware Copilot that bridges the critical gap between embedded code and physical hardware constraints. It operates as a real-time validation engine that intercepts embedded C/C++ code exactly as it is typed by the developer. The system cross-references this code against thousands of pages of actual hardware datasheets to catch constraint violations instantly. When a violation occurs—such as exceeding a maximum voltage limit or configuring conflicting peripherals—SpecRAG flags the exact datasheet reference and renders a diagnostic warning directly in the developer's IDE before deployment.

How we built it

We built SpecRAG using a highly modular, four-node architecture decoupled by the Model Context Protocol (MCP). For data ingestion, Node 1 features a pipeline using Azure Document Intelligence and a vector database to index hardware datasheets and technical tables. Node 2 operates as an AST Router via a FastAPI/MCP server, integrating the Tree-sitter parsing library to extract only hardware-relevant C++ logic and prevent context window pollution. We handled AI Reasoning in Node 3 by enforcing structured JSON outputs using Gemini 1.5 Flash, Azure OpenAI, and Pydantic models to guarantee zero-hallucination constraint checking. Finally, for Developer UX (Node 4), we developed a native TypeScript VS Code extension utilizing the Language Server Protocol (LSP) to capture text and render red diagnostic squiggly lines directly in the editor.

Challenges we ran into

We had to figure out how to prevent the AI from generating conversational fluff or hallucinating hardware specifications, which would have completely undermined the tool's core safety focus. Additionally, filtering the massive volume of standard C++ boilerplate code was challenging, as sending raw files directly to the LLM would result in severe token bloat and increased latency.

Accomplishments that we're proud of

We successfully established a "Zero-Hallucination" auditing environment by mathematically constraining the LLM to output predefined JSON schemas via Pydantic. To solve our dependency delays, we implemented an effective "Asynchronous Unblocker" strategy by building mock retrieval functions and static endpoints that allowed our frontend, backend, and AI teams to work in parallel without bottlenecking each other. Ultimately, we achieved complete decoupling of the system using the Model Context Protocol (MCP), meaning the heavy AI backend "Brain" runs entirely independently of the lightweight VS Code client "Body".

What we learned

We learned the immense value of using Abstract Syntax Trees, specifically via Tree-sitter, to traverse embedded C++ code and programmatically extract specific hardware tokens like PORTB or Wire, which significantly reduced our token payloads. During this process, we realized the absolute importance of preserving enclosing block structures, such as setup() and loop(), during AST filtering to maintain logical scope for the LLM. Furthermore, we discovered that utilizing mock endpoints is a critical best practice for hackathon execution, as it allowed us to test end-to-end pipeline routing before burning real API credits.

What's next for SpecRAG

Our future roadmap includes scaling SpecRAG for multi-board and IoT environments, allowing for cross board validation in complex systems and firmware updates across large IoT fleets.