Which Architecture Patterns Survive AI?

If an agent can write the layers, adapters, and plumbing of an application, which architecture patterns are still worth asking it to implement?

The answer starts with the pressure that made the pattern useful. Some patterns reduce the work of writing repetitive code. Others isolate change, organize ownership, or manage failures that can occur regardless of who wrote the implementation. Several do more than one of these jobs.

As implementation becomes cheaper, each choice deserves another look. Generating a familiar architecture is easy to ask for. Understanding which responsibilities that architecture carries takes a more specific account of the system.

Start With The Pressure

A pattern bundles decisions under a name. That name can help a team communicate, but it can also conceal which properties the system needs and which costs it is accepting.

The distinction is about responsibilities. A persistent pressure can acquire a different solution as databases, runtimes, compilers, and development tools take on more work.

Reconsider The Cost Of The Layers

An abstraction that saves repetitive typing has different economics when an agent can produce the repetition cheaply. A general framework may take more effort to understand and maintain than several small, direct implementations.

That does not settle the design. Copies of a business rule can drift even when their first versions cost little to generate. A shared definition can be valuable because a change has one authoritative place to land. Conversely, forcing unrelated rules through a common abstraction can make changes harder.

Consider an application that maps every request through several nearly identical object models. Those mappings may enforce a useful boundary, such as preventing a public API from exposing internal data. Where they merely repeat the same shape, the team should examine what they contribute. Cheap generation reduces typing effort while leaving review, debugging, and compatibility work.

Domain-driven design still offers useful questions about language, ownership, and invariants. The appropriate implementation can be small. Neither a class hierarchy nor a service boundary follows automatically from naming a domain concept.

Separate Domain Meaning From Effect Execution

A refund rule can state which change is permitted, which invariant must hold, and which payment effect is required. Executing that effect involves separate decisions about transactions, provider calls, delivery, and recovery.

When domain logic is expressed through a particular effect stack or framework, those execution decisions can become part of the representation of the rule. Changing the runtime then requires recovering the rule from that machinery. A higher-level language can make the transition and its required effects explicit before choosing how to execute them.

This separation also gives verification a useful subject. A checker can reason about the refund constraint, while the mapping into a concrete implementation has its own obligations. Stronger verification helps establish properties within a model; the choice of model determines how directly those properties describe the business behavior we care about.

Ports and adapters is one familiar way to separate responsibilities in code. Cohesive pursues that separation in the language representation, where domain definitions and realizations are connected explicitly. Current support depends on the block and target; the representation alone does not prove an adapter correct.

Reliable Publication Still Needs A Mechanism

Suppose accepting a refund must durably record a payment obligation. If the application updates its database and separately publishes a message, a failure between the writes can leave committed state without the required delivery. Faster code generation leaves that failure window in place.

A transactional outbox can record the state change and publication obligation in one local transaction. A publisher delivers the recorded work afterward. The design still needs to account for duplicates, retries, retention, and recovery.

The durable requirement is that the accepted change and its obligation cross the appropriate commit boundary together, followed by delivery under stated assumptions. Another storage or runtime mechanism may satisfy that requirement directly. In that case, a separately implemented outbox may add no value.

This is where architecture can become part of compilation. When tooling knows the requirement and the target capabilities, it can select or generate a supported mechanism and report unmet obligations. Such a mapping requires evidence about the target's behavior. A matching API shape is insufficient.

The persistence and coordination article examines the mechanisms and their boundaries in more detail.

A Process Can Outlive Its Execution Strategy

An approval process might wait days between brief actions. Another process might continuously consume events while maintaining substantial live state. Both have process meaning, but their execution costs and recovery needs differ.

Persisting resumable state in object storage may suit some infrequent work, provided coordination and recovery are handled. Frequent reloads, large state, low latency requirements, or live resources that cannot simply be serialized may favor a database, a resident process, or another execution strategy.

Durable execution addresses continuity across interruptions. It does not determine the entire domain process, and choosing a workflow engine does not settle every external effect's failure semantics.

Cohesive separates the process definition from its operational requirements and host binding. A supported realization must satisfy the required persistence, ordering, timing, and recovery behavior. Moving an active process also requires compatible state and a migration plan. Some targets will be conditional or unsupported for a given process.

That leaves room to change an execution strategy as the workload changes while keeping the accepted process meaning identifiable. The extent of that freedom depends on the guarantees the new realization can preserve.

Ask What The Pattern Must Establish

When reviewing an architecture proposed by a person or agent, start with a concrete change or failure. Determine what must remain true, at which boundary, and who is responsible. Then compare mechanisms against that requirement, including their operational costs and the assumptions they introduce.

A local update may need a database transaction. Work crossing a network can introduce new delivery and recovery obligations. A business boundary can help organize ownership without becoming a separate deployment. Each choice needs a reason tied to the system being built.

Cohesive's capability analysis frames the same problem for tooling: state the required semantics, inspect direct or composed realizations, and make gaps visible. As more implementation work moves into tools, these explicit requirements give both people and agents a basis for judging the architecture they produce.