GO — Healthy across the board

• Last commit today
• 9 active contributors
• Distributed ownership (top contributor 22% of recent commits)
• Apache-2.0 licensed
• CI configured
• Tests present

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests}

BAML is a domain-specific language that transforms prompt engineering into schema engineering by letting you define LLM functions as first-class constructs with typed inputs/outputs, automatically generating type-safe client code. It compiles .baml files into Python, TypeScript, Go, Ruby, Java, C#, and Rust SDKs, handling model orchestration, streaming, retries, and tool-calling across diverse LLM APIs without requiring you to rewrite your entire application. Monorepo with Rust workspace at root (crates/* members). Core: crates/baml_compiler2_* (lexer→parser→AST→HIR→PPIR→TIR→MIR→emit pipeline), crates/baml_builtins* (runtime), languages/python/rust/codegen_python (Python SDK generator). Language-specific SDKs generated by codegen crates. CI orchestrated via .github/workflows/ with reusable action.yml files in .github/actions/setup-{rust,python,node,go,ruby,java}.

Full-stack engineers building AI-powered applications who need reliable, deterministic LLM outputs with type safety; teams migrating from ad-hoc prompt files to production-grade AI workflows; developers in Python, TypeScript, Go, Ruby, and JVM languages who want to avoid hand-writing prompt formatting and response parsing logic.

Actively developed (version 0.0.0-beta indicates pre-1.0 but substantial codebase with 18.5M lines of Rust, full CI/CD, multiple language SDKs, and GitHub Actions for release automation). Not yet 1.0 — likely breaking changes expected — but infrastructure and testing are production-quality with reusable workflow files for Python, Ruby, TypeScript, CLI, and VS Code extensions.

Beta status (0.0.0-beta) means API stability not guaranteed. Heavy Rust dependency (18.5M LOC) with tight coupling to compiler crates (baml_compiler2_ast, baml_compiler2_hir, etc.) creates onboarding friction and potential for cascading breakage. Monorepo structure across 8+ languages requires coordinated testing; missing recent commit date in metadata makes it impossible to assess maintenance velocity.

Multi-language SDK maintenance (Python, TypeScript, Ruby, Go, Java, C#, Rust generators active). Compiler2 pipeline is the canonical implementation (baml_compiler2_*). BEPs (BAML Enhancement Proposals) tracked in workflows/beps.reusable.yaml. JetBrains plugin, VS Code extension, and Zed editor support in release workflows. Emphasis on reliable tool-calling and model-agnostic abstractions.

git clone https://github.com/BoundaryML/baml.git
cd baml
# Install Rust (MSRV 1.91.1) from .envrc or rustup
cargo build
cargo test
# For language SDKs: cargo build -p codegen_python (or codegen_typescript, etc.)

Dev environment in .devcontainer/devcontainer.json; .envrc hints at Nix flake setup. No Docker required locally.

Daily commands:

cargo build --release
cargo run -p baml_cli -- --help
# Generate Python SDK from .baml files
cargo run -p codegen_python -- --input-file myfunction.baml --output-dir ./baml_client
# Run tests
cargo test --workspace

No npm/pip install needed for local dev (pure Rust + .baml examples). SDKs built post-compile-step via codegen_* crates.

• baml_language/Cargo.toml — Root workspace manifest defining all Rust crates, dependencies, and MSRV (1.91.1)—essential for understanding the compiler setup and build configuration
• baml_language/ARCHITECTURE.md — High-level design document explaining BAML language architecture, parser flow, and crate organization—critical reading before modifying core language features
• baml_language/crates/baml_base — Foundational crate providing base types and utilities used across all other BAML crates—changes here ripple through the entire system
• .github/workflows/ci.yaml — Primary CI pipeline orchestrating tests, builds, and releases across Python/TypeScript/Ruby/Java/Go/Rust—defines quality gates all PRs must pass
• baml/main.go — Entry point for the Go SDK implementation; demonstrates how language bindings marshal BAML functions to language-specific APIs
• baml-cli/main.go — CLI tool entry point for BAML validation, code generation, and LSP—primary user-facing interface for the framework
• CONTRIBUTING.md — Development guidelines, PR process, and contributor workflow—mandatory reading before submitting contributions

Add a new BAML language feature (e.g., new type, function modifier)

1. Define lexer tokens and grammar in the parser crate (baml_language/crates/baml_parser or similar) (baml_language/crates/baml_base)
2. Implement semantic analysis and type checking logic in baml_type crate (baml_language/crates/baml_type)
3. Update ARCHITECTURE.md if introducing new architectural layers or concepts (baml_language/ARCHITECTURE.md)
4. Add codegen rules in respective language bindings (e.g., languages/python/rust for Python) (baml_language/languages/python/rust)
5. Add tests in the test suite and verify with cargo test in baml_language/ (baml_language/TEST_INSTRUCTIONS.md)

Add support for a new programming language (e.g., new SDK)

1. Create new language crate structure under baml_language/languages/[lang-name]/ following existing patterns (Python, TypeScript, etc.) (baml_language/languages/python/rust)
2. Implement FFI bindings connecting to the Rust core if compiled language; for interpreted languages, use existing FFI patterns (baml_language/Cargo.toml)
3. Create new build workflow in .github/workflows/ following the build-python-release.reusable.yaml pattern (.github/workflows/build-python-release.reusable.yaml)
4. Update release.yml to include new language in the orchestration step (.github/workflows/release.yml)
5. Document setup and quick-start in README.md and link from docs (README.md)

Add a new CLI command or codegen feature

1. Add command handler and argument parsing in baml-cli/main.go (baml-cli/main.go)
2. Create integration test in .github/workflows/integ-tests.yml to validate end-to-end behavior (.github/workflows/integ-tests.yml)
3. Update CONTRIBUTING.md if the feature affects development workflows (CONTRIBUTING.md)
4. Document the command in the official docs (link from README.md or docs.boundaryml.com) (README.md)

Fix a cross-language bug or compatibility issue

1. Identify the failing language test in .github/workflows/ (e.g., test-go-windows.yml, cargo-tests.reusable.yaml) (.github/workflows/ci.yaml)
2. Fix the core logic in baml_language/crates (baml_base, baml_type, or language-specific crate) (baml_language/crates/baml_base)
3. Verify the fix in all language bindings by running local tests: cargo test for Rust, Python pytest, TypeScript jest, etc. (baml_language/TEST_INSTRUCTIONS.md)
4. Update CHANGELOG.md with a brief fix description (CHANGELOG.md)

• Rust (parser, type system, core runtime) — Zero-cost abstractions and memory safety required for a language framework used across multiple SDKs; performance-critical path for parsing and type checking
• Go (CLI, orchestration, LSP server) — Fast compilation, simple cross-platform deployment, and built-in concurrency primitives ideal for a command-line tool and language server
• Multi-language SDK bindings (Python, TypeScript, Ruby, Java, C#, Go, Rust) — Framework must integrate seamlessly into existing ecosystems; FFI/native bindings ensure users stay in their preferred language while leveraging Rust core
• GitHub Actions CI/CD with reusable workflows — Enables testing across all language targets and platforms in parallel; reusable workflows reduce duplication for six+ language-specific release pipelines

• Parsing and type checking in Rust, CLI in Go, SDKs in native languages

  • Why: Avoids reimplementing language semantics for each target; single source of truth for BAML grammar
  • Consequence: Requires FFI layer maintenance and coordination across Rust/Go/Python/TS codebases; adds complexity in version alignment

• BAML as a schema language that generates code rather than a runtime interpreter

  • Why: Enables tight integration with host languages (Python, TS, etc.) and zero overhead for function calls
  • Consequence: Developers must regenerate code after schema changes; no dynamic schema updates at runtime

• Monorepo structure with workspace members across multiple language ecosystems

  • Why: Single CI/CD pipeline and shared governance; easy cross-language testing
  • Consequence: Large CI matrix; slower overall test cycles if not parallelized effectively

• Does not provide a runtime executor for prompts—BAML is a schema compiler; execution is delegated to LLM APIs (OpenAI, Anthropic, etc.)
• Not a machine learning framework or fine-tuning platform—focused on prompt engineering structure, not model training
• Does not handle authentication or API key management—users integrate with their own secret management systems
• Not a database or state management layer—BAML functions are stateless; persistence is the

1. Workspace edition mismatch: Rust 2024 edition requires MSRV 1.91.1; older Rust will silently fail. Check .envrc or run rustup override set 1.91.1 in cloned directory. 2. Codegen crates are strict: Each language's codegen (codegen_python, codegen_typescript, etc.) must be compiled separately; changing baml_compiler2_emit may break multiple SDKs. 3. No single entry point for examples: .baml files are scattered and referenced in integration tests (rig_tests/); there's no examples/ directory. 4. MIR is canonical: Don't assume AST/HIR/PPIR semantics are stable; the intermediate representation (MIR) is what code generators consume, so compiler bugs often require MIR-level fixes. 5. Version constant manual bump: Cargo.toml has version = "0.0.0-beta" marked as "needs manual update"; CI may fail if you forget to bump it during releases.

• Multi-pass compiler architecture — BAML's pipeline (lexer→parser→AST→HIR→PPIR→TIR→MIR→codegen) is non-trivial; understanding how each pass transforms the representation helps you debug compiler bugs and extend the language
• Intermediate representations (IR) — BAML uses 5 distinct IRs (AST, HIR, PPIR, TIR, MIR); learning why each exists (AST=parse tree, HIR=semantic analysis, MIR=codegen input) helps you localize changes and avoid breaking multiple backends
• Type schema as a first-class language feature — Unlike traditional prompt templates, BAML embeds type definitions (class/enum) as the primary way to structure outputs; this enables compiler-driven code generation and runtime validation that prompt strings cannot provide
• Tool-calling with fallback synthesis — BAML promises reliable tool-calling on models that don't natively support it (e.g., via prompt engineering); understanding baml_builtins2's retry + synthesis logic is key to extending model support
• Codegen abstraction via traits — Each language SDK is generated by a crate (codegen_python, codegen_typescript, etc.) implementing a shared trait from baml_compiler2_emit; this pattern lets you add a new language without forking the compiler
• Streaming LLM responses — BAML supports token-by-token streaming and partial type deserialization; the baml_builtins2 crate handles buffering and type coercion on incomplete responses, critical for real-time UI features
• Language-specific code generation from a single source — A single .baml function definition must emit type-safe, idiomatic code in Python (Pydantic), TypeScript (interfaces), Go (structs), etc.; this requires deep knowledge of each language's type system and conventions

• prompt-engineering/Langchain — Competing framework for chaining LLM calls; BAML differentiates by offering schema-first design and compiled type-safe stubs instead of runtime chains
• anthropics/anthropic-sdk-python — Direct integration target; BAML abstracts over Anthropic (Claude) as one model backend alongside OpenAI, Gemini, etc.
• openai/openai-python — Core model provider SDK; BAML's baml_builtins layer wraps OpenAI's client to add retries, streaming, and type coercion
• BoundaryML/baml-examples — Official example repository for BAML; demonstrates real-world function definitions, tool-calling, and multi-language SDK usage
• huggingface/transformers — Local model inference alternative; BAML's multi-model abstraction allows swapping between cloud APIs and self-hosted models

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add GitHub Action workflow for testing Ruby SDK releases

The repo has setup actions for multiple languages (Python, TypeScript, Node, Go, Java, Rust) and corresponding release workflows, but there's a .github/actions/setup-ruby without a corresponding build-ruby-release.reusable.yaml workflow completion or Ruby-specific integration tests. This is a gap for a multi-language framework that claims Ruby compatibility.

• [ ] Review .github/actions/setup-ruby/action.yml to understand Ruby environment setup
• [ ] Create .github/workflows/test-ruby-integration.reusable.yaml mirroring the pattern in test-rust-sdk.yml and cargo-tests.reusable.yaml
• [ ] Add Ruby test execution steps (likely using bundle exec rspec or similar) for the languages/ruby directory
• [ ] Integrate the new workflow into .github/workflows/primary.yml to run on PRs
• [ ] Document Ruby testing setup in CONTRIBUTING.md

Add missing C# SDK integration tests and CI workflow

The file structure shows .github/actions/setup-java, setup-python, setup-node, setup-rust, setup-go, and setup-ruby, but no setup-csharp action. The repo claims C# compatibility in the description but lacks dedicated CI coverage. This is a high-value addition for a multi-language SDK.

• [ ] Create .github/actions/setup-csharp/action.yml following the pattern of existing language setup actions
• [ ] Create .github/workflows/build-csharp-release.reusable.yaml for C# SDK builds and tests
• [ ] Create integration test workflow .github/workflows/test-csharp-integration.reusable.yaml
• [ ] Add C# test execution to .github/workflows/primary.yml
• [ ] Update CONTRIBUTING.md with C# development and testing instructions

Add comprehensive E2E tests for multi-language code generation consistency

The repo has compiler infrastructure (baml_compiler2_ast, baml_compiler2_hir, etc.) and multi-language codegen (Python, TypeScript, Ruby, Java, C#, Go) but no visible end-to-end tests verifying that the same BAML schema generates functionally equivalent code across all supported languages. This ensures schema parity and catches regressions.

• [ ] Create rig_tests/e2e/schema_generation_parity.test.ts (or equivalent) to define test schemas in BAML
• [ ] Generate code for each language (Python, TypeScript, Ruby, Java, C#, Go, Rust) from the same schema
• [ ] Verify generated types, interfaces, and function signatures are semantically equivalent across languages
• [ ] Add workflow .github/workflows/e2e-codegen-parity.reusable.yaml to run these tests on each compiler change
• [ ] Integrate into .github/workflows/primary.yml to catch cross-language regressions early

• Add missing docstrings to public APIs in crates/baml_type/src/lib.rs (especially TypeDef enum variants). This improves IDE hover hints and onboarding without touching compiler logic.
• Write integration test for Ruby SDK in rig_tests/crates/; currently Python and TypeScript have comprehensive suites but Ruby is underrepresented. Pick one BAML function (e.g., ChatAgent from README) and test it in all three SDKs.
• Create a minimal example .baml file and corresponding generated stubs for each language (Python/TypeScript/Go/Ruby/Java) in a docs/ directory with a manifest. Helps future contributors understand the expected codegen output format.
• Audit and complete error messages in crates/baml_compiler_diagnostics/src/; many error variants lack helpful context. Prioritize parsing errors since they're most visible to end users.
• Add a Makefile or justfile (Just config at root suggests partial adoption) that documents common dev tasks: build, test, codegen, release. Currently scattered across .github/actions/ and Cargo.toml.

The BAML codebase shows moderate security hygiene with some concerns. Main issues include tracked configuration files that should be local-only (.infisical.json, .gitconfig) and the inherent complexity of maintaining SDKs across 6+ programming languages. The project appears to follow good practices with Apache-2.0 licensing, GitHub Actions security workflows, and a structured monorepo layout. However, the presence of files that should contain secrets or sensitive configuration indicates incomplete .gitignore coverage. Recommendations include immediate remediation of tracked config files, comprehensive dependency scanning across all language ecosystems, and ensuring Cargo.lock and equivalent lock files are tracked for reproducible builds.

• Medium · Infisical Configuration File Present — .infisical.json. The repository contains a .infisical.json file which is typically used for secrets management. This file should not be committed to version control as it may contain sensitive configuration data or references to secret management systems. Fix: Add .infisical.json to .gitignore immediately. Rotate any credentials that may have been exposed. Use environment variables or secure secret management systems instead of committing configuration files.
• Medium · Git Config File Tracked — .gitconfig. The .gitconfig file is present in the repository root, which may contain user-specific or sensitive git configuration. This should typically be a local user configuration, not a repository-wide tracked file. Fix: Remove .gitconfig from version control. Use git hooks, documentation, or setup scripts for repository-specific configuration instead of committing .gitconfig.
• Low · Development Dependencies in Workspace — Cargo.toml (workspace configuration). The Cargo.toml workspace includes development and testing crates that may expose additional attack surface. The workspace explicitly excludes 'crates/bridge_go' but includes multiple compiler and codegen crates. Fix: Regularly audit all workspace dependencies using 'cargo audit'. Implement dependency scanning in CI/CD pipeline. Consider using cargo-deny for policy enforcement on dependencies.
• Low · Incomplete Dependency Information — Cargo.toml. The provided Cargo.toml excerpt is truncated (ends mid-dependency definition for 'bex_engine'). This makes it difficult to perform complete security analysis of all dependencies. Fix: Provide complete Cargo.toml and Cargo.lock files for comprehensive dependency security analysis. Lock files should be committed to version control to ensure reproducible builds.
• Low · Multiple Language SDKs Increase Attack Surface — Multiple SDK directories (languages/python, languages/typescript, etc.). The project maintains SDKs for multiple languages (Python, TypeScript, Ruby, Java, C#, Rust, Go). Each language binding introduces additional dependencies and potential vulnerabilities. Python and Node.js packages are particularly important to monitor. Fix: Implement language-specific security scanning (pip-audit for Python, npm audit for Node.js, etc.). Maintain separate dependency lock files for each language. Include all language-specific packages in CI/CD security scanning.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/BoundaryML/baml shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live BoundaryML/baml repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/BoundaryML/baml.

What it runs against: a local clone of BoundaryML/baml — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in BoundaryML/baml | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch canary exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 30 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of BoundaryML/baml. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/BoundaryML/baml.git
#   cd baml
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of BoundaryML/baml and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "BoundaryML/baml(\\.git)?\\b" \\
  && ok "origin remote is BoundaryML/baml" \\
  || miss "origin remote is not BoundaryML/baml (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify canary >/dev/null 2>&1 \\
  && ok "default branch canary exists" \\
  || miss "default branch canary no longer exists"

# 4. Critical files exist
test -f "baml_language/Cargo.toml" \\
  && ok "baml_language/Cargo.toml" \\
  || miss "missing critical file: baml_language/Cargo.toml"
test -f "baml_language/ARCHITECTURE.md" \\
  && ok "baml_language/ARCHITECTURE.md" \\
  || miss "missing critical file: baml_language/ARCHITECTURE.md"
test -f "baml_language/crates/baml_base" \\
  && ok "baml_language/crates/baml_base" \\
  || miss "missing critical file: baml_language/crates/baml_base"
test -f ".github/workflows/ci.yaml" \\
  && ok ".github/workflows/ci.yaml" \\
  || miss "missing critical file: .github/workflows/ci.yaml"
test -f "baml/main.go" \\
  && ok "baml/main.go" \\
  || miss "missing critical file: baml/main.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 30 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~0d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/BoundaryML/baml"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.