Skip to content

AI Driven Development

Jump to bottom
Oleksandr Geronime edited this page Jul 16, 2026 · 4 revisions

AI-Driven Development

The challenge with AI in large systems is scope. Unbounded tasks produce unpredictable results. SERP solves this structurally — framework, generator, and tooling together reduce every AI task to a bounded implementation problem with clear contracts and hard scope limits.

SERP is designed around spec-bounded AI development: architecture is explicit, infrastructure is generated, implementation scopes are enforced, and debugging is connected to the running system. AI is not asked to "understand the whole codebase and be careful." The framework gives it a smaller, typed, validated problem to solve.

This is the difference between using AI as a general coding assistant and using AI as part of an engineering system.

Ordinary AI coding SERP AI-driven development
The prompt describes intent; the codebase is the only source of truth. SerpIDL specs describe the architecture; generated code enforces the contract.
AI can wander into unrelated files or infrastructure layers. Role scopes and filesystem guards constrain where each session can write.
IPC, lifecycle, build files, and glue are easy to damage. Framework libraries and serpgen own deterministic infrastructure.
Parallel AI work requires manual coordination. Service boundaries and contracts let sessions run independently.
Debugging relies on pasted logs and human-driven experiments. AI debug sessions can call live services, read properties, and observe notifications.
"Done" is often a conversational judgment. Validation, build, tests, scope checks, and runtime inspection act as gates.

The SERP Model

SERP keeps the historical pillars — Service · Event · Runtime · Platform — and makes each one useful for AI-driven engineering:

Pillar What it gives AI
Service A bounded unit of ownership: one service, one contract, one implementation scope.
Event Typed behavior surfaces: methods, properties, notifications, streams, timers, and watchdogs.
Runtime Live observability and control: inspect a running deployment instead of guessing from static code.
Platform The surrounding safety system: generator, transports, lifecycle, logging, tests, IDE, session roles, and guards.

The result is not "AI writes C++ faster." The result is a development process where AI can work inside architectural constraints that are visible to tools and enforceable by the framework.

Why SERP Works Well with AI

Building a large distributed system with AI is hard because AI produces unpredictable results when given unbounded scope. SERP solves this structurally.

Critical code lives in libraries — AI never touches it

Threading, event loop dispatch, IPC marshaling, lifecycle sequencing, watchdog enforcement — all of this lives in the compiled SERP framework libraries. AI sessions operate on impl files in src/. There is no way to accidentally break the framework from a service session.

Glue code is generated — AI never writes it

Transport adapters, proxy/stub classes, process entry points, CMake wiring, service registration — everything that connects the pieces together is generated by serpgen from specs. It is correct by construction. AI does not write it and does not need to understand it.

AI only writes business logic

What remains after framework and generator cover their ground is purely business logic — the part that cannot be covered by specs because of its variability. This is exactly the bounded, well-scoped problem that AI handles well: implement ClimateManager::onSetTemperature, not "wire up the IPC layer."

Specs are contracts between AI sessions

The Architecture session writes IClimateManager.sidl.yaml. Every subsequent session — Service, HMI, Debug — works from that contract. The interface is authoritative. The generator enforces it at compile time. An AI implementing a service cannot diverge from what the architect specified.

The Workflow

Phase 0 — Intake and Design (optional)

Session kind: intake (greenfield) or Sync Design + Design Draft (existing project) Allowed writes: specs/**/*.design.yaml only

Before any service is implemented, its intent can be captured as an approved Design Contract — a durable, user-approved record of what a block is for, separate from the ephemeral session summaries every session also keeps. For a new project, an Intake session discusses what you want at the domain level and proposes the first contracts. For a project that already has specs and code predating this workflow, Sync Design scans what exists and proposes contracts from it, then a headless Design Draft session reads the real code and writes the description and implementation status itself. Either way, nothing is auto-approved — only you move a block to approved.

This phase is optional per-block: architecture and service sessions work fine without it. What it buys you is a durable gate — an AI session can point to why a design decision was made months later, and Implementation Runs (Phase 2) can compute exactly what's left to build from it.

Phase 1 — Architecture

Session role: system-architect
Allowed writes: specs/services/**, specs/interfaces/**, specs/deployments/**
Tool: Architecture session in the SERP VS Code panel

The architect session designs the full system decomposition:

  1. Identify service boundaries, responsibilities, and dependencies
  2. Define interface contracts in SerpIDL (methods, properties, notifications, types)
  3. Define deployment topologies (which services run in which processes, which transport)
  4. Validate specs with serpgen validate — catches inconsistencies before any code is written
  5. Write an architecture summary that child sessions inherit automatically

The session follows a structured workflow: requirements → research → decomposition → validation → review → revision. Unresolved design questions block stage completion — forcing explicit decisions rather than implicit assumptions.

Output: A complete specs/ tree. Running serpgen generate-workspace after this phase produces all interfaces, base classes, and process entry points.

Phase 2 — Service Implementation

Session role: service-implementer
Allowed writes: src/services/<group>/<service>/**, tests/services/<group>/<service>/**
Tool: Service session per service in the SERP VS Code panel

Each service is implemented in an isolated session. Sessions for different services can run in parallel — they cannot touch each other's files.

Each service session automatically receives:

  • The architecture summary from Phase 1 (design decisions, constraints, rationale)
  • The interface spec for this service (what methods it must implement)
  • The generated base class (method signatures, property declarations, notification wiring)
  • Existing implementation files (if resuming work)

The AI implements handlers, fills in lifecycle methods, mutates properties, fires notifications — all strictly within the generated interface contract. The scope guard blocks any write outside src/services/<group>/<service>/.

Key property: adding a new service to the system means opening a new session. Sessions do not need to coordinate. The specs coordinate them.

At scale, this phase doesn't have to mean one manually-opened session per service. Implementation Runs compute which service/HMI/sequence blocks aren't implemented yet (or need updating) across the entire project from Design Contract + state drift, and spawn a session per task automatically — a persisted, resumable batch job rather than a chat window per service. This is the part of SERP that most directly answers "how do you actually get an AI to build a large distributed system": not one long conversation, but many bounded, independently-scoped sessions launched and tracked as one unit of work.

Phase 3 — Debug and Fix

Session role: runtime-investigator (Analyze/Debug) or deployment-fixer (Fix)
Allowed writes: Fix role — src/services/**, tests/**
Tool: Debug session tied to the active deployment

Debug sessions have access to a running system. The AI does not guess — it observes.

Structured debug cycle:

List methods → Call method → Observe result → Form hypothesis → Call again → Fix → Build → Test

Using the serp.runtime.call MCP tool, the AI can:

  • Call any public method on any running service: ClimateManager.SetTemperature, MediaManager.Play
  • Read current property values: current temperature, playback state
  • Subscribe to notifications: observe events as they fire

This is the same capability exposed by the Runtime Inspector in the VS Code UI — but available directly to the AI session, enabling automated investigation without human relay.

Debug sessions inherit summaries from all parent sessions — the architecture context and all service implementation summaries. The AI debugs with full awareness of design intent.

Scope Isolation and Parallelism

Every session has a hard-enforced write scope. This is not a convention — it is a pre-tool-use hook that blocks writes at the shell level before they reach the file system.

Session Can write Cannot write
Architecture specs/ src/, gen/, tests/
Service (cabin/Media) src/services/cabin/MediaService/, its tests All other services, specs/, gen/
Sequence same as its owning service Everything else
HMI src/components/<group>/<component>/ src/services/, gen/
Fix src/services/**, tests/** specs/, gen/
Exploration anywhere except gen/ gen/ only
Intake / Design Draft specs/**/*.design.yaml only *.sidl, *.suml, src/**, gen/**, build/**
All sessions — gen/** (always forbidden)

This makes parallel AI sessions safe. An architect session and three service sessions can run simultaneously with no risk of collision.

Logging as AI Infrastructure

SERP logs all inter-service communication and all lifecycle events automatically, in a uniform format — this is not application-level logging added by developers, it is framework-level instrumentation.

Every method call between services is logged with:

  • Caller thread and callee thread
  • Method name and arguments
  • Timing

Every service lifecycle transition is logged:

  • Created, Initializing, Initialized, Deinitializing, Deinitialized

Because the format is consistent and predictable across the entire system, AI can analyze logs without custom parsing logic. A debug session can read a log and immediately understand which service called what, in what order, and where a chain broke — without needing deployment-specific knowledge about log formats.

Context Inheritance

Sessions form a hierarchy. Child sessions inherit summaries from parents automatically:

architecture::system
    └── service::cabin/ClimateManager
    └── service::cabin/MediaManager
    └── service::platform/VehicleHal
            └── sequence::cabin/ClimateManager/HandleSetTemperature

When a Service session opens, it receives the architecture summary — the design decisions, constraints, and rationale from Phase 1. When a Fix session opens, it receives architecture and all service summaries. Each level of AI work builds on what came before without re-reading everything from scratch.

Summaries are stored in .serp/ai/summaries/ and updated by the AI at the end of each session. They are the institutional memory of the build.

Structured Workflows and Validation Gates

Sessions do not run as open-ended chats. Each role follows a structured workflow with named stages and completion criteria.

Example: Architecture workflow stages

Stage Goal Completion criteria
requirements_analysis Understand the problem No unresolved critical questions
research Collect domain knowledge Key artifacts written
decomposition_draft Write specs serpgen validate passes
validation Verify consistency IR dump clean, no circular deps
hostile_review Attack the design Review artifact written
revision Fix findings Revalidation passes

Unresolved critical questions block stage advancement. Validation failures trigger automatic loop-back to the fix stage. The AI cannot declare work done until all gates pass.

Validators run automatically at the right stages:

  • generator_validate — runs serpgen validate on specs
  • build — CMake build passes
  • service_tests — component tests for the modified service pass
  • scope_lock — all written files are within allowed scope

Summary

Property What it means for AI
Framework libraries AI cannot break threading, IPC, lifecycle — not in scope
Code generation AI never writes glue — only business logic remains
Spec contracts Architecture AI defines what; service AI implements it; no negotiation
Design Contracts An approved, durable record of intent — not just a chat transcript — gates what a session may call "implemented"
Scope enforcement Hard file-system-level blocks — AI parallelism is safe by construction
Batch implementation Implementation Runs spawn a session per not-yet-implemented block project-wide, as one resumable unit of work
Runtime access Debug AI calls live services, reads state, observes events in real time
Uniform logging AI analyzes logs without custom parsers
Summary inheritance Each session builds on prior sessions — context is layered, not re-read
Workflow stages Structured progression with validation gates — AI cannot skip steps

See Also

SERP Wiki

Getting Started

The Development Model

Architecture Language

Code Generator

Framework Internals

VS Code Plugin

Examples

Clone this wiki locally