Building AI Agents for Automated Code Generation: A Complete Guide Using the ai-agent-book Repository

The ai-agent-book repository provides a complete learning platform combining a multilingual book with 95+ runnable Python experiments, featuring a reusable SDK that abstracts LLM provider handling to enable seamless automated code generation across multiple backends.

The bojieli/ai-agent-book repository offers a self-contained environment for building AI agents for automated code generation, merging educational content with production-ready Python implementations. This open-source project structures its codebase into three tightly-coupled layers—documentation, experiments, and a core SDK—that allow developers to progress from theory to working code generation agents without switching contexts.

Three-Layer Architecture of the ai-agent-book Repository

The repository organizes its resources into distinct layers that separate narrative explanation from executable implementations.

Content and Documentation Layer

The book/ directory contains the original Chinese markdown chapters, mirrored in language-specific folders like book-en/ and book-es/. Each chapter file, such as book/chapter5.md, provides the theoretical foundation for the corresponding hands-on experiments. This separation ensures that content updates propagate across 13 language translations without breaking code references.

Experiment Code Layer

Each chapter maintains its own sub-directory (chapter1/, chapter5/, etc.) containing scripts, modules, and test suites. The automated code generation examples reside in chapter5/, where chapter5/context/main.py implements a coding agent that translates natural language requests into executable Python code. Each folder follows a consistent pattern including README.md, sub-modules, tests/ for PyTest suites, and scripts/ for helper utilities.

Core SDK Layer (agentbook/)

The agentbook/ package supplies reusable abstractions for LLM provider handling. Located at the repository root, this SDK is imported by all experiments and includes:

• providers/__init__.py – Re-exports the public API
• providers/models.py – Defines Provider and Backend data classes
• providers/registry.py – Houses the immutable provider table PROVIDERS and alias handling
• providers/resolution.py – Implements precedence rules for provider selection
• providers/legacy.py – Maintains backward compatibility with pre-registry APIs

Provider Architecture and Resolution Flow

All experiments communicate through OpenAI-compatible endpoints, with provider-specific differences isolated in the central registry. The resolution logic in agentbook/providers/resolution.py implements a four-step precedence system:

1. Canonicalise the user-supplied provider name using aliases defined in registry.py (e.g., mapping moonshot to kimi)
2. Lookup the provider configuration via lookup() in agentbook/providers/registry.py
3. Compose a Backend object that merges provider defaults with environment variable overrides
4. Return the configured backend to construct an openai.OpenAI client

The immutable provider table PROVIDERS in agentbook/providers/registry.py declares base URLs, default models, and API key environment variables for each supported service. Adding a new vendor requires only a single entry, after which the CLI automatically offers it via --provider because SUPPORTED_PROVIDERS derives dynamically from the table.

Implementing Automated Code Generation Agents

The Chapter 5 coding agent demonstrates practical automated code generation. The script chapter5/context/main.py instantiates an agent that receives natural language instructions, queries the LLM for Python code generation, and executes the output in a sandboxed environment.

To run the experiment:

uv sync --locked --extra ch5
uv run python chapter5/context/main.py

Experiments declare requirements via extras in pyproject.toml. Install Chapter 5 dependencies using uv sync --locked --extra ch5 or python -m pip install -e ".[ch5]". Copy .env.example to .env and fill the appropriate API keys (e.g., OPENAI_API_KEY, MOONSHOT_API_KEY) before running.

Resolving LLM Backends in Python

The SDK's resolve_backend function abstracts provider selection, enabling the same experiment code to run across dozens of LLM services including free options like ollama.

# demo_resolve.py

from agentbook.providers import resolve_backend
from openai import OpenAI

# Resolve the default backend for the Kimi provider

backend = resolve_backend("kimi")

print(f"Base URL : {backend.base_url}")
print(f"Model ID : {backend.model}")
print(f"API Key  : {backend.api_key[:4]}…")

# Use the OpenAI-compatible client

client = OpenAI(api_key=backend.api_key, base_url=backend.base_url)

response = client.chat.completions.create(
    model=backend.model,
    messages=[{"role": "user", "content": "Generate a Python function to calculate fibonacci numbers"}],
)
print(response.choices[0].message.content)

Extending the SDK with Custom Providers

Adding new LLM services requires only registry modification. To add a provider named "mycloud", edit agentbook/providers/registry.py:

PROVIDERS["mycloud"] = Provider(
    name="mycloud",
    base_url="https://api.mycloud.ai/v1",
    default_model="mycloud-7b",
    key_vars=("MYCLOUD_API_KEY",),
)

After saving, the CLI automatically accepts --provider mycloud because SUPPORTED_PROVIDERS recomputes from the live table.

Multi-Agent Simulations and Advanced Experiments

Advanced experiments demonstrate complex agent interactions beyond single-shot code generation. The Voice Werewolf demo in Chapter 10 resides under chapter10/voice-werewolf/werewolf/ and implements a full multi-agent simulation.

The implementation in chapter10/voice-werewolf/werewolf/game.py runs voice-driven interactions between multiple agents, showcasing how the SDK supports sophisticated automated reasoning and state management across agent collectives.

Summary

• The ai-agent-book repository combines multilingual documentation with 95+ runnable experiments for building AI agents for automated code generation
• The three-layer architecture separates content (book/), experiments (chapterX/), and the reusable SDK (agentbook/)
• The provider resolution system in agentbook/providers/resolution.py enables seamless switching between LLM backends via OpenAI-compatible interfaces
• Chapter 5's coding agent in chapter5/context/main.py provides a working implementation that executes LLM-generated Python code in a sandbox
• New providers are added by updating PROVIDERS in agentbook/providers/registry.py, automatically exposing them to all experiments through the resolve_backend API

Frequently Asked Questions

How does the ai-agent-book repository handle multiple LLM providers?

The repository uses a centralized provider registry in agentbook/providers/registry.py that defines base URLs, default models, and API key variables for each service. The resolve_backend() function in agentbook/providers/resolution.py canonicalizes provider names, resolves aliases, and composes backend configurations, allowing experiments to run unchanged across OpenAI, Kimi, Ollama, and other compatible endpoints.

What Python version is required to run the code generation experiments?

All experiments require Python 3.10 or higher. Dependencies are managed through optional extras in pyproject.toml, allowing targeted installation of specific chapter requirements using commands like uv sync --locked --extra ch5 or pip install -e ".[ch5]".

How do I add a new custom LLM provider to the framework?

Add a new entry to the PROVIDERS dictionary in agentbook/providers/registry.py specifying the provider name, base URL, default model, and environment variable keys. The SDK automatically registers the new provider and exposes it via the --provider CLI argument without requiring changes to experiment code.

Where is the actual coding agent implementation located?

The primary coding agent experiment resides in chapter5/context/main.py. This script implements the automated code generation workflow by accepting natural language requests, calling the LLM through the SDK's backend resolution system, and executing the generated Python code in a controlled environment.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}