Design is deliberate, not delegated

AI can assist design. Implementation should not be allowed to establish architecture through unexamined decisions.

The problem

Developers have always made design decisions while writing software. A requirement leaves a gap; someone fills it. An edge case appears; someone chooses a policy. A new component needs to connect to an existing one; someone decides where its responsibility belongs. Experienced engineers often do this with a mental model of the whole system.

Delegating implementation to an agent does not remove those decisions. It transfers many of them to a system that may confidently prefer a plausible solution over the intended one—even when examples or a technical design have been provided.

The risk is not simply incorrect code. It is a coherent implementation of the wrong architecture.

What deliberate design means

Design establishes intent and limits before an implementation begins: responsibilities, boundaries, contracts, allowed dependencies, non-functional requirements, unresolved decisions and risks. AI can usefully generate alternatives, find inconsistencies and highlight trade-offs, but a decision still needs an accountable owner.

This does not mean producing a comprehensive blueprint for an unknown future. Design can evolve quickly. What changes is the path by which it changes: an implementation surprise is surfaced and considered, rather than silently becoming a new architectural fact.

A useful design conversation compares choices against constraints. A weak one offers a preferred answer and asks a human to accept it.

Illustrative example

A product needs to receive external requests and make them available to a team. An agent proposes that the web handler should write directly to the database and send notifications. A deliberate design separates the external interface, request storage contract and notification mechanism. The choice takes a little thought up front but keeps the web adapter from becoming the architecture.

If implementation discovers that an agreed contract cannot support the feature, it should stop and raise the conflict—not invent a shadow service to avoid the contract.

What to retain

A concise design record is often enough: decision, considered alternatives, constraints, reason for selection and what would trigger reconsideration. Include the behaviours the contract must guarantee, not merely method names.

Limits

Overdesign is a real failure mode. Architecture should match the likely pace of change and consequences of error. Do not demand elaborate design artefacts for a trivial, reversible edit. The principle is deliberate judgement, not documentation volume.

See the worked example: architecture and decision record.