Do design patterns still matter when AI writes the first draft?

AI will happily emit a Strategy here, a Factory there, and a comment that says “clean architecture” above a file that is neither. The speed is seductive. It also tempts a lazy conclusion: design patterns are obsolete because the model already knows the Gang of Four.

I still use a few patterns. I stopped teaching them as a religion. The useful question is not “does the catalog still exist?” It is “when does a named shape reduce risk for the humans who must change this code after the generator moves on?”

Here is how I decide — as someone who reviews AI-assisted PRs weekly and still owns production.

What patterns were always for

Patterns are compressed experience. They are not moral virtue. Observer, Strategy, Adapter, Facade — these names exist so two engineers can talk about a trade-off without redrawing it from scratch.

AI changes the cost of producing code that resembles a pattern. It does not change the cost of misunderstanding the pattern’s purpose. If anything, resemblance without purpose is now cheaper, which makes empty ceremony more common.

When I still reach for a named pattern

I use a pattern when three conditions show up together:

1. The variation is real and will grow (multiple payment providers, multiple export formats).
2. The boundary needs to stay stable while implementations churn.
3. The team will be safer if the shape has a name in review.

Examples that still earn their keep:

• Strategy / policy objects for pricing, entitlements, or tax rules that multiply.
• Adapter at the edge of a third-party API you do not control.
• Facade when a messy subsystem needs a boring public door.
• Outbox / queue + worker (a distributed cousin of classic decoupling) when you must not lose a side effect.

In those cases I will ask an AI assistant to draft the skeleton — then I will insist the names match the actual boundary, not a tutorial’s folder tree.

When patterns become cosplay

I push back when AI (or a human) introduces:

• Abstract factories for two concrete classes that will never become four
• Visitor for a sum type that a switch would clarify
• Singleton “services” that are global mutable state with better branding
• Layers so pure that a simple feature requires eight files and zero clarity

Generated code loves architecture diagrams. Production loves the smallest shape that keeps change local.

My review question is rude and effective: “What becomes easier to change because this pattern exists?” If the answer is “it looks professional,” delete it.

AI as a junior who memorizes the catalog

Treat the model like a junior who has read every patterns book and shipped little under pager load. It will over-apply. Your job is selection and deletion.

Practical workflow I like:

1. Describe the variation and the stability boundary in plain language.
2. Ask for the simplest implementation that passes tests.
3. Only then ask whether a named pattern would clarify the next three changes.
4. If yes, refactor toward the pattern with tests green the whole time.

Starting from the pattern catalog is how you get Framework of the Week inside a feature branch.

Teaching without the religion

I no longer make juniors memorize UML for patterns they will not meet this quarter. I teach:

• Find duplication that varies for a reason
• Name the stable axis
• Hide the churn behind a small interface
• Prefer deletion over cleverness

When a classic name helps, I introduce it as vocabulary — “this is basically an Adapter” — not as a badge. When AI proposes a pattern, juniors should be able to reject it with a reason.

That skill matters more now, not less, because the generator will not be embarrassed by a wrong abstraction.

Patterns that matter more in an AI world

Some shapes gained importance precisely because generation is cheap:

• Clear module boundaries so generated code has a place to land
• Contract tests at API edges so agents cannot casually break clients
• Feature flags so experiments are reversible
• Idempotent handlers so retries from generated glue do not double-charge

Call them patterns or call them engineering manners. Either way, they are the difference between “AI wrote a demo” and “AI helped ship a system.”

A short personal allowlist

If I am honest about what I still teach and use:

• Adapter at vendor edges
• Strategy when policies multiply
• Facade for scary subsystems
• Repository only when it is a real abstraction, not a ceremony over SQL
• Null object rarely, and only when it removes special cases cleanly

Everything else must win an argument against a simpler alternative in the same PR.

The answer I give in interviews now

Do design patterns still matter when AI writes the first draft? Yes — as shared language and as tools for managing variation. No — as a checklist that proves sophistication. The craft moved upstream: choosing which shape deserves a name, and deleting the ones that only exist because the model has seen them too many times.

Let AI draft. You decide whether the pattern is carrying weight. If it is not, the most senior move left is the oldest one in the book: simplify until the next change is obvious.