Compiler Driven Development (CDD) is a development approach designed to eradicate the disconnect between: API specifications; server implementations; client SDKs; and command-line tooling.

Unlike traditional code generators—that treat outputs as disposable or read-only—CDD provides a complete, standalone compiler for each supported language. These compilers are fully CST-aware (Concreate Syntax Tree is a whitespace+comment aware Abstract Syntax Tree), allowing true bidirectional synchronization between existing hand-edited source code and OpenAPI specifications.

Traditional tools use naïve templating—if you regenerate, your custom code is overwritten.

The CDD ecosystem is fundamentally different. It utilizes language-specific, standalone compilers capable of full AST parsing, semantic diffing, and surgical patching.

The Core Guarantee: Every part of the generated codebase is fully editable. You are encouraged to open the generated routing files, model definitions, and CLI structures, and directly inject your business logic.

• When your specification changes, the CDD compiler reads your code, builds an AST, diffs it against the new spec, and safely patches in new endpoints or fields without touching your custom logic.
• When your codebase changes, the compiler reverse-engineers your structural updates back into a 100% accurate, authoritative OpenAPI specification.

flowchart TD
    OAS["📄 OpenAPI v3 Spec"] <--> CDD{"⚙️ CDD Compiler"}
    
    CDD <--> Codebase
    
    subgraph Codebase ["💻 Application Codebase"]
        direction TB
        
        subgraph Outputs ["📦 Primary Outputs"]
            direction TB
            CLI["⌨️ CLI Tooling"]
            SDK["📦 Client SDK"]
            Server["🖥️ Server"]
            
            %% Force vertical stacking inside the subgraph
            CLI ~~~ SDK ~~~ Server
        end
        
        subgraph Core ["🔗 Core Architecture"]
            direction TB
            Models["🔗 Data Models"]
            Routes["🔀 API Routes"]
            Tests["🧪 Tests"]
            
            %% Force vertical stacking inside the subgraph
            Models ~~~ Routes ~~~ Tests
        end
        
        Mocks["🎭 API Mocks / Fakes"]

        %% Simple dependency flow down the page
        Outputs --> Core
        Tests --> Mocks
    end
    
    style OAS fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style CDD fill:#f3e5f5,stroke:#8e24aa,stroke-width:2px
    style Codebase fill:#fafafa,stroke:#9e9e9e,stroke-width:2px,stroke-dasharray: 5 5
    style Outputs fill:#e8f5e9,stroke:#43a047,stroke-width:2px
    style Core fill:#fff3e0,stroke:#f57c00,stroke-width:2px

The CDD lifecycle supports continuous evolution from any starting point:

1. Generate: Scaffold servers, SDKs, or CLIs from a central specification.
2. Edit: Developers write real, unconstrained code directly in the generated files.
3. Extract: Reverse-compile the edited code to produce an updated OpenAPI spec.
4. Sync: Apply new specification changes seamlessly into the existing, hand-edited codebase.

Every supported language operates on the same core CDD philosophies but is powered by a dedicated, native compiler tailored to that language's specific AST, idioms, and package management.

All implementations share a standardized CLI interface (cdd [subcommand]), acting as a universal toolchain.

Repository	Language	Client; Client CLI; Server	Extra features	Standards	CI Status
cdd-c	C (C89)	Client; Client CLI; Server	FFI	Swagger 2.0 & OpenAPI 3.2.0
cdd-cpp	C++	Client; Client CLI; Server	Upgrades Swagger & Google Discovery to OpenAPI 3.2.0	Google Discovery; Swagger 2.0 & OpenAPI 3.2.0
cdd-csharp	C#	Client; Client CLI; Server	CLR	Swagger 2.0 & OpenAPI 3.2.0
cdd-go	Go	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-java	Java	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-kotlin	Kotlin (ktor for Multiplatform)	Client; Client CLI; Server	Auto-Admin UI	Swagger 2.0 & OpenAPI 3.2.0
cdd-php	PHP	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-python	Python	N/A (server building blocks)	CLI ↔ SQL ↔ Pydantic ↔ docs ↔ JSON-schema	N/A
cdd-python-all	Python	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-ruby	Ruby	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-rust	Rust	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-sh	Shell (/bin/sh)	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-swift	Swift	Client; Client CLI; Server		Swagger 2.0 & OpenAPI 3.2.0
cdd-ts	TypeScript	Client; Client CLI; Server	Auto-Admin UI; Angular; React; Vue; fetch; Axios; Node.js	Swagger 2.0 & OpenAPI 3.2.0

A true ecosystem requires standardized tooling. Once a developer learns the CDD toolchain, they can synchronize architecture across the entire polyglot stack.

• --help: Print help information.
• --version: Print version information.
• --input, -i (or -f): Target file, directory, or OpenAPI spec.
• --output, -o: Destination path for generation or sync.

$ cdd-sh from_openapi --help
Usage:
  cdd-sh from_openapi [subcmd] [options]

Subcommands:
  to_sdk          Generate a client SDK.
  to_sdk_cli      Generate a client SDK and CLI.
  to_server       Generate server boilerplate, models, and routes.
  to_openapi      Extract OpenAPI spec from an existing codebase.
  to_docs_json    Extract documentation data structure.

Options:
  -i, --input <spec>             Path to the OpenAPI specification file.
  --input-dir <dir>              Path to a directory containing OpenAPI specification files.
  -o, --output <target_dir>      Destination path for generation.
  --no-github-actions            Skip generating GitHub Actions CI workflow.
  --no-installable-package       Skip generating package definitions (e.g., package.json).
  --tests                        Generate unit tests alongside the code.
  --ephemeral                    (Server) Use ephemeral in-memory storage.
  --seed                         (Server) Seed the database on startup.
  --strict-validation            (Server) Enforce strict OpenAPI request validation.
  --enforce-auth                 (Server) Enforce authentication for all endpoints.
  --start-auth-server            (Server) Start an embedded authentication server.
  --help, -h                     Show this help message.

$ cdd-sh to_openapi --help
Usage:
  cdd-sh to_openapi [options]

Options:
  -i, --input <code_file_or_dir> Path to the source code directory or file to parse.
  -o, --output <spec.json>       Destination path for the generated OpenAPI spec.
  --help, -h                     Show this help message.

$ cdd-sh to_docs_json --help
Usage:
  cdd-sh to_docs_json [options]

Options:
  -i, --input <spec.json>        Path to the OpenAPI specification file.
  -o, --output <docs.json>       Destination path for the documentation data.
  --no-imports                   Do not include import statements in generated snippets.
  --no-wrapping                  Do not wrap the output in a top-level documentation object.
  --help, -h                     Show this help message.

$ cdd-sh serve_json_rpc --help
Usage:
  cdd-sh serve_json_rpc [options]

Options:
  --port <port>                  Port to listen on (default: 8082).
  --listen <ip>                  IP to listen on (default: 0.0.0.0).
  --help, -h                     Show this help message.

$ cdd-sh mcp --help
Usage:
  cdd-sh mcp [options]

Description:
  Run the cdd-sh CLI as a Model Context Protocol (MCP) server over standard I/O.

Options:
  --help, -h                     Show this help message.

Parse specific source files into an AST. Supported types include openapi, routes, classes, docstrings, tests, mocks, docsjson.

Emit generated artifacts from a parsed AST. Supported types include openapi, routes, classes, docstrings, tests, mocks, docsjson.

Synchronize an existing codebase directly. It parses the files and emits corresponding artifacts to maintain consistency.

• Standalone and Portable: The cdd-sh CLI is distributed as a single Go binary that bundles an embedded shell interpreter (mvdan.cc/sh/v3), jq (gojq), and awk (goawk). This means it can execute all shell parsing, diffing, and code generation logic flawlessly on Windows, macOS, and Linux without requiring bash, jq, or awk to be installed on the host system.
• Embedded WebAssembly (WASM): By utilizing Go's WASM support and embedded file systems, cdd-sh provides native cross-platform implementations for core POSIX commands (like cp, mkdir, rm, cat), ensuring a consistent and self-contained generation pipeline everywhere.

With Compiler Driven Development, specifications and code are no longer loosely coupled artifacts. They are strict, isomorphic reflections of one another, maintained by dedicated standalone compilers.

Choose your language ecosystem above and start treating your architecture as a seamlessly compiled, endlessly editable whole.

Licensed under either of

• Apache License, Version 2.0 (LICENSE-APACHE or https://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or https://opensource.org/licenses/MIT)

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.