Architect-Led Development (ALD)

A disciplined engineering methodology where the architect defines role-based interfaces, DTOs, and behavioral contracts grounded in SOLID and GoF patterns—and AI generates the concrete implementations and unit tests.

Get the prompt kit See Python example

ALD is not “prompt-driven coding.” It’s design authority + delegated implementation.

One-sentence definition

ALD is a contract-first approach where you design responsibility-scoped roles (interfaces + DTOs) and validate intent via tests, while AI produces and refines implementations under those constraints.

Contract-first Role-based interfaces SOLID GoF patterns Test-validated intent AI implementation

What ALD is (and isn’t)

ALD is…

  • Micro-responsibility interface design (SRP at the contract level)
  • Role-based abstractions (policies/decisions), not layer buckets
  • Behavior-driven contracts expressed as unit tests you can approve
  • Pattern-aware composition using proven design patterns
  • AI as an execution engine for implementations and test scaffolding

ALD is not…

  • “Let the AI build the system”
  • Random abstraction layering
  • Repository/Service/Controller buckets by default
  • Copy/paste code generation without contract ownership
  • Testing as an afterthought
Core idea: You own meaning and architecture. AI owns mechanics and repetition.

Principles

Role-based interfaces

Interfaces represent responsibilities and decisions (policies, strategies, validators), not where code lives (repository/service/controller).

SOLID-first

ALD assumes strong engineering literacy: SRP/ISP drive interface granularity; OCP/LSP/DIP shape extensibility and substitutability.

Patterns as vocabulary

Abstractions “earn” their existence by mapping cleanly to well-known patterns (Strategy, Adapter, Decorator, Factory, etc.).

Tests are the contract

You review and approve unit tests as the authoritative description of behavior before you trust implementations.

Frameworks at the edges

Keep core logic framework-agnostic. Integrations adapt to the core through ports/adapters.

Architect in the loop

AI proposes; the architect constrains, validates, and refines. The architect remains accountable for correctness.

Workflow

ALD is a tight loop: define contracts → generate tests → approve intent → generate implementations → refactor under constraints.

  1. Architect defines contracts DTOs + role-based interfaces, scoped to a single responsibility.
  2. AI proposes contract tests Happy paths, edge cases, negative cases; assumptions documented.
  3. Architect approves behavior Review tests to confirm the system’s intent and constraints.
  4. AI generates implementations Concrete classes, dependency injection, no I/O in core logic.
  5. Refactor & harden Improve SOLID, pattern fit, readability; keep contracts stable.
  6. Lock the contract Interfaces + tests become the stable boundary; evolve through additive change.

ALD design rules

Interface rules

  • One interface = one responsibility (SRP applied to contracts).
  • Role-based, not layer-based: name decisions/policies, not stack position.
  • Prefer capabilities over buckets: “OrderLookup” vs “OrderRepository”.
  • Interfaces should be pattern-legible (Strategy/Adapter/Decorator/Factory/etc.).
  • Dependency injection: implementations are pluggable; no hidden globals.

DTO & contract rules

  • DTOs are immutable by default (or treated as immutable).
  • DTOs are behavior-light (invariants ok; avoid “smart DTOs”).
  • Contracts must define error modes, edge cases, and invariants.
  • Every interface gets a contract test suite.
  • Core logic remains framework-agnostic; I/O stays at the edges.
ALD stance: “CRUD repositories” often violate ISP by forcing consumers to depend on methods they don’t need. Prefer capability-focused ports (e.g., OrderStore, OrderLookup, OrderQuery).
Example: layer-based vs role-based

Layer-based (avoid)

interface OrderService {
  void submit(Order o);
  Money price(Order o);
  Order findById(OrderId id);
  void cancel(OrderId id);
}

Role-based (prefer)

interface OrderSubmissionValidator { ValidationResult validate(OrderDraft d); }
interface OrderPricingStrategy { Money price(OrderDraft d); }
interface OrderCancellationPolicy { boolean canCancel(Order o, Instant now); }
interface OrderStore { void save(OrderSnapshot s); }
interface OrderLookup { Optional<OrderView> findById(OrderId id); }

Prompt kit (copy/paste)

These prompts are designed for ALD: contract-first, SOLID + patterns, tests as the behavioral authority.

1) Generate implementation + tests

You are implementing Architect-Led Development (ALD).

Non-negotiables:
- Follow SOLID and use GoF patterns where appropriate.
- Keep core logic framework-agnostic.
- No hidden behavior: tests define the contract.
- Prefer composition over inheritance.
- Produce clean, refactor-friendly code.

Given the following interfaces and DTOs (DO NOT change signatures):
[PASTE INTERFACES/DTOS HERE]

Task:
1) Implement concrete classes for these interfaces.
2) Write unit tests that precisely express the intended behavior.
3) Cover edge cases and negative cases.
4) Make dependencies injectable. No global state.
5) Keep I/O at the edges; use in-memory fakes in tests.

Output:
- Source files with paths
- Test files with paths
- Brief notes explaining which pattern(s) you used and why

2) Contract-first tests only

We are using ALD. I want you to define the behavioral contract.

Given these interfaces/DTOs (do not change them):
[PASTE]

Write only unit tests (no implementation) that encode:
- happy paths
- edge cases
- invalid inputs and error behavior
- invariants and ordering constraints (if any)

Assume a typical unit test framework for the language.
If something is ambiguous, choose a reasonable default and document it in test names/comments.

3) Refactor pass (keep contract stable)

ALD refactor pass.

Here is the current implementation and tests:
[PASTE OR LINK SNIPPETS]

Goals:
- Improve SOLID adherence and separations of responsibility
- Reduce coupling, increase readability
- Ensure patterns used are appropriate and minimal
- Keep public contracts unchanged (interfaces/DTOs/test expectations)

Deliver:
- Proposed refactor plan (bulleted)
- Updated code (paths)
- Explanation of key design decisions

4) Pattern justification gate

ALD design review.

Given these interfaces and their implementations:
[PASTE]

For each interface:
- State the responsibility in one sentence
- Identify the GoF pattern (or explain why none is needed)
- Flag any violations of SOLID or unnecessary abstraction
- Recommend merges/splits/renames with rationale

FAQ

Why “role-based” interfaces?

Because roles model decisions and responsibilities, which are stable and testable. Layer-based buckets (Service/Repository) tend to accumulate unrelated behavior and violate ISP.

Is ALD just Clean Architecture / Hexagonal?

ALD is compatible with those styles, but it pushes the contract boundary down to a single-responsibility grain so you can scale architectural control while delegating implementation.

Does ALD require AI?

No. ALD is an engineering methodology. AI simply makes the “delegate implementation” step dramatically faster. The rigor comes from SOLID + patterns + contract tests.

What’s ALD’s stance on CRUD repositories?

A single interface exposing broad CRUD often violates ISP by forcing consumers to depend on unused methods. Prefer capability-focused ports (lookup/store/query) and adapt them to your persistence tech.

How do you avoid “too many interfaces”?

You avoid “too many reasons to change.” Interfaces are cheap; coupling is expensive. ALD uses micro-interfaces only where variability, testability, and responsibility boundaries matter.

Want to adopt ALD on a team? Start by picking one module and enforcing: role-based interfaces + contract tests. Everything else follows.

More Resources

Explore how ALD fits into broader development frameworks and see practical examples.

Python Example ALD in Business-Driven Development

Share

This is a single-page static site. Host it anywhere (GitHub Pages, S3 static website hosting, Netlify, etc.).