botingw_job

Like many of you, I've been amazed by AI coding assistants but also incredibly frustrated by the "plausible-but-wrong" code they often produce. I'd ask a question about LangGraph, get a confident answer, and then spend 20 minutes debugging an error because the AI hallucinated a method or used a class that was deprecated two months ago. This project is my attempt to fix that by building what I call a "Grounded Assistant." The core idea is simple: an AI assistant should be grounded in the executable truth of a specific, version-controlled codebase, not just its general training data. Here’s how it works in practice: Grounding in Docs (RAG): When I ask a question (e.g., "How do I add persistence?"), the assistant doesn't just guess. It first performs a semantic search (RAG) against a local, version-correct copy of the LangGraph documentation to find the actual canonical examples and explanations. Code Generation: It then uses that specific, relevant context to generate the Python code. Self-Correction (Knowledge Graph): This is the crucial step. Before showing me the code, the assistant validates its own output against a Neo4j knowledge graph of the entire langgraph library. This acts as a pre-flight check, catching hallucinations like non-existent functions, incorrect parameters, or invalid class instantiations. It forces the AI to self-correct if its code doesn't align with the library's actual structure. The goal is to get code that is correct for my specific environment on the first try, dramatically cutting down on the debugging cycle. The project is open source and the README has the full details. I'd love to hear your thoughts and critiques on this approach! Happy to answer any questions.

I'm building this project to accelerate AI agent development, and I wanted to share a solution to a problem that's been costing me a lot of time. The core issue is that when I use a general AI assistant to write code for a rapidly evolving library like LangGraph, its knowledge is often outdated. It suggests code based on its training data or old blog posts, which might be for v0.1 of a library when I'm using v0.2. This leads to a frustrating cycle of running code, hitting an error because an API changed, and then spending hours debugging the AI's "correct" but outdated answer.

My solution is to ground the AI assistant in the executable truth of the official, version-controlled documentation. That's why I created the LangGraph-Dev-Navigator.

Here's how it works:

A Local Source of Truth: The project uses a git submodule to clone the official langgraph repository locally. This means the documentation the AI uses is the exact same one that corresponds to the code on my machine. If I need to work with langgraph==0.0.56, I just check out that tag in the submodule, and the AI's entire knowledge base is instantly aligned.

RAG on Verified Docs: The assistant is equipped with tools (perform_rag_query, search_code_examples) that only perform Retrieval-Augmented Generation (RAG) on this local, version-aligned documentation. It doesn't poll the open internet or rely on its static internal knowledge. This ensures the context for code generation is always current and correct for my environment (future goal is combines the advantages of rich Google results and precise official docs).

While the framework also has an experimental feature for validating code against a Knowledge Graph (check_ai_script_hallucinations), the primary focus right now is on this principle of grounding the AI in trusted, version-synced knowledge.

The goal is to create a blueprint for building reliable AI assistants for any fast-moving project. By ensuring the AI's knowledge comes from the right source, we can dramatically reduce debugging time and accelerate the development of complex agents.

The project is open-source, and I would love to get your feedback, especially from anyone else who has struggled with keeping AI assistants in sync with library updates.

The repo is here: https://github.com/botingw/langgraph-dev-navigator

I think this suggestion of polishing the basic layer first and then building the high level layer is a good one. Since the potential development directions are so broad (marketplace for rule sets, evaluation of rule sets, version control of rule sets, more useful tools, unit test & deployment & PM rules), I have never dared to over-design before users have clear feedback.

For project management, I have another exploratory project. This project is a set of rules that use Cursor/Cline/Windsurf as a project manager assistant. repo is here: https://github.com/botingw/pm-workflow-copilot-ide

For your 2, I understand versioning with rules. Does compose mean assembling rules? What does reasoned about mean?

For your 3, what configuration management do you recommend adding?