Introduction
A migration I ran recently completed in a single afternoon. The coordination scaffolding I built for it was never needed. The rollback path I preserved throughout was never used. Everything I applied was technically correct, and roughly half of it was answering a question the project had already stopped asking.
This article expands on my video about AI design patterns and the binding constraints that determine whether a pattern is load-bearing or optional when agentic AI compresses timelines and team sizes. The video covers the migration story directly. This article develops the diagnostic framework in more depth and gives you a structured way to apply it to your own work.
The audience for this is developers and architects who are already using AI-assisted delivery on real systems and are starting to notice that the standard playbook does not always fit. If you have ever finished a task and wondered whether the process you followed was proportionate to the actual constraints, the Pattern Re-Selection Test described here is designed for exactly that question.
Why AI-assisted delivery breaks the standard playbook
Most design patterns in software delivery were not invented to manage complexity in code. They were invented to manage complexity in teams. Strangler-fig migrations, branch-by-abstraction, multi-stage rollback mechanisms, feature switches that toggle between old and new transport paths: all of these exist because multiple engineers working across extended timelines need coordination points. The patterns are justified by elapsed time and team size.
For most of software history, those two constraints were effectively fixed. A migration affecting a production system with downstream consumers took weeks or months. It involved handoffs, review cycles, and the real possibility that the engineer who started the work would not be the one who finished it. Patterns that managed that reality were not optional. They were the craft.
Agentic AI changes both constraints simultaneously. A single engineer working with an AI coding tool can now execute, test, and verify a migration that would previously have required a team working across multiple sprints. The elapsed time compresses from weeks to hours. The team size collapses from five or six people to one person plus a model. When both constraints change together, the patterns that depended on them become optional, not because the patterns were wrong, but because the problem they were solving has changed shape.
This is not a comfortable observation. The instinct to apply the full playbook is not irrational. On a live system with a downstream consumer and a hard requirement to preserve the running path, the cautious approach feels like exactly the right engineering discipline. In my experience, that instinct is worth examining rather than simply overriding, because the consequences of a failed migration are real regardless of how fast the tooling moves. The question is not whether to be careful. The question is whether the specific form of care you are applying matches the actual constraints in front of you.
What the compression of timelines and team sizes reveals is that the standard playbook was always two things at once: patterns that managed coordination between people, and patterns that managed the essential complexity of the problem itself. At normal delivery speed, you rarely had to distinguish between them. At AI speed, you have to make that distinction explicitly, because the first category becomes optional while the second category becomes more important.
The Pattern Re-Selection Test is a way to make that distinction before you discover it the hard way.
The Pattern Re-Selection Test: three classes and what they mean
The diagnostic is a single question applied to any pattern you are currently using: what binding constraint does this pattern actually serve? The answer places the pattern in one of three classes, each with a different implication for AI-assisted delivery.
Class A: coordination-over-time patterns
Class A patterns are justified by elapsed time and team size. They exist to coordinate multiple people working across extended periods on a shared system. Migration scaffolding, strangler-style cutovers, branch-by-abstraction, heavy release ceremony, multi-stage rollback mechanisms, and feature switches that toggle between old and new code paths all belong here.
These patterns are not wrong. They are proportionate to the constraints that originally justified them. When elapsed time compresses to an afternoon and team size collapses to one person working with an AI, they become optional. The key word is optional, not obsolete. If your migration will span three months and involve four engineers, Class A patterns remain load-bearing. If your migration will span one session and involve one person, they are scaffolding for a problem you may not have.
In my experience, the error is not applying Class A patterns when they are not needed. The error is treating them as non-negotiable discipline regardless of context, which makes it harder to see when the context has changed.
Class B: essential-complexity patterns
Class B patterns are justified by the intrinsic complexity of the problem, not by team size or elapsed time. Bounded contexts, ports as a dependency discipline, idempotency guarantees, transactional boundaries, and careful management of distributed state all belong here. These patterns are unchanged by AI-assisted delivery.
In practice, they often become more important. Agentic AI does not make a distributed transaction simpler. It gets you to the distributed transaction faster. If your bounded contexts are poorly defined, AI-assisted development will surface that problem sooner and at larger scale than slower delivery would have. The essential complexity of the domain does not compress with the timeline.
A port, in the architectural sense, is a single clean boundary that makes a contract explicit and testable. It is not a coordination mechanism between people. It is a mechanism for controlling how components couple to each other. That function is unchanged whether the implementation takes six weeks or six hours.
Class C: comprehension-and-safe-change patterns
Class C patterns are justified by the need for human comprehension and safe modification of the system over time. Explicit boundaries, strong typing, tests written as specification rather than verification, hard-fail contracts that surface errors loudly rather than degrading silently, and architecture decision records all belong here.
At AI delivery speed, Class C patterns become more important for a reason that is specific to the tooling. The code now has a second reader: the model. When one engineer is accountable for more system than they can read at the pace the model writes it, the patterns that maintain legibility and safe change are not optional hygiene. They are control mechanisms.
Consider hard-fail contracts specifically. In a migration I ran, a schema-creation shortcut allowed a database to drift from the model. It was the hard-fail discipline, not any coordination process, that surfaced the problem. The system broke loudly. The failure was immediate and locatable. Without that discipline, the same drift would have produced silent degradation that could have taken hours to trace.
Architecture decision records serve a related function. In a long AI-assisted session, the context window of the model and the working memory of the engineer are both finite. When you need to return to a decision point, or when the model needs context about why a constraint exists, a written record of the intent is not bureaucratic overhead. It is the mechanism that keeps the session coherent.
Applying the classification
To apply the test, take any pattern your team currently treats as standard practice and ask which class it falls into. For Class A patterns, ask whether the elapsed time and team size that originally justified them still apply to the work in front of you. For Class B and Class C patterns, ask whether you are applying them with enough discipline, because AI speed amplifies the cost of skipping them.
The classification is not always clean. Some patterns serve more than one function, and the right classification depends on your specific context. A feature switch, for example, might be Class A in a migration context and Class B in a system where runtime configurability is a genuine requirement. The question to ask is which function the pattern is serving in this specific situation.
The following example illustrates how the three classes appear in a single piece of work. Consider a configuration component moving from file-based storage to a dedicated service, with a downstream consumer depending on the existing behaviour and a hard requirement to preserve the running path throughout.
The strangler-style cutover with a feature switch selecting old or new transport per component is Class A. It is justified by the assumption that the migration will take long enough that a rollback path needs to be preserved and exercised. If the migration completes in a single session, that assumption does not hold.
The port defining the boundary between the application and the configuration transport is Class B. It is justified by the need to make the contract explicit and testable regardless of how long the migration takes. Removing it would make the implementation harder to verify and harder to change safely.
The hard-fail contracts and the architecture decision records are Class C. They are justified by the need to maintain legibility and safe change in a session where the code is being produced faster than a human can read it in full. Removing them would transfer control from the engineer to the model, which is not a trade-off that produces reliable outcomes.
When the migration completed in a single session and the first end-to-end test passed, the Class A scaffolding had served no function. The Class B and Class C patterns were what made the result correct and verifiable.
Putting the test into practice
The most useful application of this test is before a design or planning session, not after a migration has completed. Fifteen minutes spent classifying the patterns your team treats as non-negotiable will surface questions that are harder to ask once implementation is underway.
Start with one pattern. Pick something your team currently applies to every significant change without explicitly justifying it. Write down the binding constraint it serves. Then ask which class that constraint belongs to. If it is Class A, ask whether the elapsed time and team size that justify it apply to the current work. If it is Class B or C, ask whether the discipline is being applied consistently enough to hold at the pace the tooling permits.
The common pitfall is treating this as a permission structure for removing patterns rather than a framework for examining them. The goal is not to strip the playbook down to the minimum. The goal is to understand which parts of the playbook are doing real work in your current context. In my experience, the patterns that survive that examination are applied with more intention and more rigour than patterns followed by habit.
A second pitfall is applying the test only to technical patterns and not to process patterns. Release ceremony, review gates, and approval workflows are also patterns with binding constraints. Some of them are Class A. Some of them are Class C, because they maintain legibility and accountability rather than coordination. The same question applies: what constraint does this actually serve, and does that constraint still apply?
The success condition for applying this test is a concrete answer you can bring to a conversation. Not "we should probably review our patterns" but "this specific pattern is Class A, the elapsed time and team size that justify it do not apply to this project, and here is what we are proposing instead." That is the kind of answer that moves a design conversation forward.
Closing the argument
The patterns that AI-assisted delivery makes optional are not the patterns that were wrong. They are the patterns that were right for a team size and a timeline that no longer apply to a growing portion of real work. The patterns that remain load-bearing, and the patterns that become more important, are the ones that manage the complexity of the problem and the legibility of the system, not the coordination of a team.
In my experience, the shift is already live in the work. You may not see it yet because from the inside it looks like good engineering discipline. The Pattern Re-Selection Test is a way to examine that discipline explicitly rather than discovering its proportionality after the fact.
Before your next design session, take one pattern your team treats as non-negotiable and run the test. Classify it. Name the binding constraint. Ask whether that constraint still applies. Bring the answer to the conversation.
If this framing raised questions about patterns in your own work, I would be interested to hear which class caused the most friction. Leave a comment with the pattern and the constraint you identified. Your mileage may vary, and that is the point.