A different way to structure a software org

Human

Requirements

AI

Domain spec + templates

FixedCode

Deterministic generation

AI

Business logic

Human

Review + ship

Smaller teams. Faster delivery. Fewer handoffs.

AI + deterministic generation replaces the coordination overhead that slows every software org down.Create a ticket. Get a running service back. No handoffs.

Get StartedView Slides

The real cost of building software

It's not writing code. It's the handoffs, coordination, and waiting between the people who write it.

Handoffs Everywhere

PM writes requirements, waits for dev. Dev asks platform about CFRs. Platform explains for the 50th time. Dev hand-wires everything. Review catches drift. Fix. Re-review. Weeks of coordination before any business logic.

Guardrails Are Social, Not Structural

The golden path lives in wikis and CLAUDE.md files. Code reviews catch violations after the fact. Nothing enforces standards at generation time. Compliance depends on discipline.

AI Makes It Faster But Not Safer

AI coding tools accelerate delivery but produce different structural code every time. 10 teams, 50 services, 50 interpretations. Speed without guardrails is just faster drift.

Why not just use one or the other?

AI alone is fast but inconsistent. Scaffolding alone is consistent but rigid. FixedCode uses both where they're strongest.

AI Generation Alone

What it does well

  • Fast — generates entire services in minutes
  • Flexible — handles any language, any framework
  • Creative — great at business logic and edge cases

Where it falls down

  • Different output every time, even for the same prompt
  • CLAUDE.md and coding standards are suggestions, not guarantees
  • At 50 services, review agents can't catch everything
  • No regeneration path — once generated, you're on your own

Scaffolding Alone

What it does well

  • Deterministic — same input, same output
  • Consistent — every service looks identical
  • Auditable — you know exactly what was generated

Where it falls down

  • Templates are painful to write and maintain by hand
  • Fire-and-forget — generate once, then you're alone (Yeoman, Backstage)
  • Rigid — can't handle the creative, domain-specific parts
  • Nobody wants to author YAML specs manually

FixedCode: AI + Deterministic Together

AI handles the creative parts

Translating requirements into specs. Building and refining templates. Implementing business logic in extension points. The parts that need flexibility.

Engine handles the structural parts

Deterministic generation from specs. Same input, identical output. Every CFR built in. Regeneration-safe. The parts that need guarantees.

Each compensates for the other

AI can't be consistent — the engine is. The engine can't be creative — AI is. Templates are hard to write — AI builds them. Specs are tedious — AI drafts them.

The AI Sandwich

AI creates the patterns. FixedCode locks them in. AI enriches the output. You never re-prompt for the same structure twice.

AI agents call fixedcode generate via CLI, MCP, or CI pipeline. Works with any AI tool.

Learn more about the AI Sandwich

AI + Human

Creative

Domain Specs

PM / Domain Expert

Defines what to build. Plain English requirements translated by AI into YAML domain specs.

Template Curation

Developer / Platform Team

Defines how to build it. AI extracts patterns from existing services into templates. Human refines iteratively.

FixedCode

Deterministic

Crystallises AI-generated patterns into reproducible templates. Same spec = identical output, every time.

AI + Human

Creative

The custom parts: business rules, domain-specific logic, unique integrations. In clearly marked extension points that regeneration never touches.

From ticket to running service

Anyone writes a request. AI handles the translation. The engine handles the guarantees. Humans handle the business logic.

The line between PM and developer blurs — with AI + deterministic generation, anyone who understands the domain can ship a service.

Request

Human

Anyone creates a ticket, Slack message, or doc. Plain English requirements. No YAML, no terminal. The role doesn't matter — PM, developer, domain expert.

ticket
# Ticket ORD-42 (Jira / Linear / Notion / Slack)
 
"We need an order management service
with line items, status tracking,
and payment integration.
 
Should follow our standard service
patterns with event sourcing."

Translate

AI Agent

AI agent picks up the request from any source. Translates plain English into a YAML domain spec conforming to the org's schema. Asks clarifying questions if needed.

order.yaml
# Agent drafts from ORD-42:
schema: ddd/1.0
boundedContext: Order
aggregates:
Order:
attributes:
orderId!: uuid
customerId!: uuid
status: string = OrderStatus
commands:
- PlaceOrder{customerId!, items!}
-> OrderPlaced
- CancelOrder(orderId!)
-> OrderCancelled

Generate + Deploy

Automated

Spec pushed to standards repo. CI triggers fixedcode generate. Code pushed to service repo. CI/CD deploys. Every CFR built in automatically.

terminal
$ fixedcode generate --spec order.yaml
✓ Schema validated — ddd/1.0
✓ Generated 47 files in ~3s
✓ Auth, audit, logging, events, tests
✓ Pushed to order-service repo
✓ CI/CD: build → test → deploy
✓ Agent updates ticket: "Deployed"

Enrich

Human + AI

The same person — PM, developer, whoever — fills in business logic in extension points with AI assistance. The 10% that's unique. The role boundary has dissolved.

OrderValidator.kt
// extensions/OrderValidator.kt
class OrderValidator :
DefaultOrderValidator() {
 
override fun onPlace(
cmd: PlaceOrder
): ValidationResult {
// Your business rules here
require(cmd.items.isNotEmpty())
require(cmd.items.all { it.qty > 0 })
return ValidationResult.valid()
}
}

The role boundary is dissolving

Step 1 and Step 4 are done by the same person. A PM who understands the domain can request a service and implement the business rules — with AI assistance. A developer who understands the platform can improve the templates that make this possible. The distinction isn't PM vs developer. It's domain knowledge vs platform knowledge.

This isn't a code generator. It's a different org structure.

Fewer handoffs. Fewer roles involved per service. The line between PM and developer dissolves — anyone who understands the domain can ship.

Today: Handoffs everywhere

PM, dev, platform — rigid roles, rigid boundaries

  • PM → dev → platform → review → fix → re-review → deploy. Multiple handoffs, multiple waits, weeks.
  • Every new service: someone hand-wires auth, logging, events. Platform team answers the same questions.
  • Review agents check AI output. Humans review what agents flag. Every step is lossy at scale.
  • Rigid roles: PM can't ship, developer is stuck on infrastructure, platform team is a bottleneck.

With FixedCode: Roles blur

Domain knowledge matters, not job title

  • Create a request → AI drafts spec → pipeline generates → deployed. One person, one workflow, minutes.
  • Anyone who understands the domain can ship a service. AI handles the translation. Engine handles the guarantees.
  • Generated code is known-good. Review only the 10% that's unique. Templates reviewed once, applied everywhere.
  • Roles blur: domain experts ship directly, developers evolve the platform, the org scales without overhead scaling.
~3s
Generation time
90%
Code automated
0
Drift
10%
Review surface

From spec to code in seconds

order.yamlYour Spec
schema: ddd/1.0
boundedContext: Order

aggregates:
  Order:
    attributes:
      orderId!: uuid
      customerId!: uuid
      status: string = OrderStatus
      totalAmount: decimal
    commands:
      - PlaceOrder{customerId!, items!}
          -> OrderPlaced
      - UpdateOrder(orderId!){items!}
          -> OrderUpdated
      - CancelOrder(orderId!)
          -> OrderCancelled
    queries:
      - GetOrder(orderId!)
          -> Order
      - SearchOrders(page, size, filters)
          -> PagedList
    entities:
      LineItem:
        lineItemId!: uuid
        productId!: uuid
        quantity!: int
outputGenerated Output
order-service/
├──api/
└──OrderController.kt
├──application/
├──OrderCommandService.kt
├──OrderQueryService.kt
├──OrderValidator.kt# interface
└──DefaultOrderValidator.kt
├──domain/
├──Order.kt
├──LineItem.kt
└──events/
├──OrderPlaced.kt
└──OrderCancelled.kt
├──infrastructure/
├──OrderRepository.kt
└──db/migration/
└──V1__create_order.sql
└──extensions/
└──OrderValidator.kt← you write this

~20 lines of YAML. Auth, audit, logging, events, tests — all generated. Teams write business logic, not infrastructure.

One engine. Five architecture types.

Pluggable schemas for the patterns your team actually uses.

Domain-Driven

Event-driven microservices with command/query separation

REST / CRUD

Standard API services with relationships and validation

Coming Soon

Event-Driven

Producers, consumers, and event contracts

Coming Soon

Frontend

Pages, components, and data sources

Coming Soon

Infrastructure

Service catalog to deployment configs

Pluggable stack bundles

Templates tied to schema + stack. Pick your architecture, pick your language.

Domain-Driven

Spring Kotlin

~47 filesgenerated
Domain-Driven

Go gRPC

Coming Soon
In development
REST / CRUD

Express TypeScript

~32 filesgenerated
REST / CRUD

FastAPI Python

~28 filesgenerated
Event-Driven

Node.js

Coming Soon
In development
Infrastructure

Terraform

Coming Soon
In development