How We Built CodeBoard in 3 Days with AI

The Problem

A new engineer joins your team. They're smart, experienced, and ready to contribute. But then reality hits: your codebase is 200,000 lines across 500 files. The architecture diagram is two years out of date. The README has one paragraph. Documentation? scattered across Notion, Google Docs, and tribal knowledge buried in Slack threads.

The ramp-up time is 3 to 6 months. That's $300K–$600K of salary before they're fully productive. And when they finally are, the next new hire starts the cycle again.

We built CodeBoard to solve this. Paste a GitHub URL, get a complete onboarding guide with architecture diagrams, module breakdowns, code patterns, and a getting-started guide. All generated automatically.

What CodeBoard Does

CodeBoard analyzes a repository and produces structured documentation that looks like it was written by a senior engineer who actually read the code. It's not just file listings—it's a narrative.

• → Architecture overview with interactive diagrams
• → Module-by-module summaries with purpose and dependencies
• → Common code patterns and anti-patterns
• → Getting started guide with runnable examples

The Architecture

CodeBoard is a Turborepo monorepo with three main services: a Next.js 14 frontend, a BullMQ worker for background processing, and shared packages for common utilities.

Tech Stack

• ▸ Frontend: Next.js 14 with App Router, shadcn/ui components
• ▸ Worker: BullMQ job queue processing, Redis for state management
• ▸ Code Parsing: @babel/parser for JS/TS, regex-based for Python
• ▸ LLM: MoonshotAI kimi-k2-turbo-preview via OpenAI-compatible API
• ▸ Diagrams: Mermaid.js for architecture visualizations
• ▸ Deployment: Docker multi-stage builds to production

The Pipeline

When you paste a GitHub URL, CodeBoard kicks off a 4-stage generation pipeline:

1. Clone repo, parse AST across all files, build dependency graph
2. Generate architecture overview with Mermaid diagrams
3. Generate module-by-module summaries
4. Extract code patterns and write getting-started guide

Each stage runs as a separate BullMQ job, so we can process multiple repositories concurrently. Results are cached in Redis, so re-analyzing a repo is near-instant.

Key Technical Decisions

Why AST Parsing Over Raw Text

Early versions of CodeBoard fed raw code files to the LLM. This worked for small repos but fell apart on anything substantial—the context window blew up, and the output was hallucinated.

AST (Abstract Syntax Tree) parsing gives us structure. We know which functions call which, which modules import which, and we can strip away implementation details to focus on the shape of the code. The LLM still does the heavy lifting of understanding and summarizing, but it works from a structured representation instead of raw text.

Structuring LLM Prompts

Getting consistent output from an LLM is half the battle. We use a strict prompt template:

You are analyzing a {language} codebase.
Output MUST be valid JSON with this schema:
{
  "overview": "string",
  "modules": [
    {
      "name": "string",
      "purpose": "string",
      "dependencies": ["string"],
      "exports": ["string"]
    }
  ]
}

Given this AST representation:
{ast_summary}

Generate the analysis.

We validate the JSON schema before accepting the response. If the LLM deviates, we retry with a stricter prompt. This fails gracefully and keeps the pipeline moving.

The parseSteps() Challenge

Here's one that cost us an afternoon: we were splitting the getting-started guide into numbered steps using a naive split(/\n/). This broke code blocks that had line numbers like:

1. Initialize the connection:
   const db = await connect()

The split would turn 1. into a separate "step" from the code below it. We had to write a smarter parser that respects code block delimiters. Lesson: test your parsers on real repos, not toy examples.

Why Turborepo Monorepo

CodeBoard started as a single Next.js app. As we added the worker, shared utilities, and parsing packages, the directory structure got unwieldy. Moving to Turborepo gave us:

• ▸ Shared type definitions across frontend and worker
• ▸ Independent deployments—update the worker without touching the frontend
• ▸ Build caching—turborepo remembers what hasn't changed

For a small project, it's overkill. For CodeBoard, it's the right call.

The AI Workflow

Here's the part that's genuinely interesting: CodeBoard was conceived, planned, and executed with AI assistance. Not just code generation—the whole project.

AI handled project planning, architecture decisions, implementation, testing, and even this blog post. The human provided strategic direction, design feedback, and infrastructure setup.

This is what Vectry does for clients. We don't just "use AI" as a buzzword—we build systems where AI is a first-class citizen, working alongside engineers to ship faster and better. CodeBoard itself is proof of the approach.

We went from idea to deployed product in 72 hours. Not a prototype, not a POC. Production code with tests, monitoring, and a live demo.

Results

• ✓ Built and deployed in 3 days
• ✓ 6 demo repositories generated (Express, Flask, FastAPI, Zod, p-limit, node-redis)
• ✓ Full interactive documentation with zoom/pan diagrams, copy-to-clipboard code blocks
• ✓ Live at codeboard.vectry.tech