u/sagenschneider

I wrote a piece arguing that AI's real architectural influence isn't through technical merit, it's through defaults. Curious what this sub thinks.

The core idea: legibility gets you considered, but only the default gets you chosen. Good documentation makes a pattern possible for an AI assistant to suggest, but system prompts, rules files, and scaffolding decide what it actually recommends when nobody is steering it.

A few points from the article:

Docs are a ceiling, not a floor. I improved the docs for a YAML based endpoint approach. The assistant would use it when explicitly asked, but left to its own devices it still defaulted to \@RestController. Better docs raised what was possible without changing the default.
Vintage lock in. Training data clusters around mainstream, older patterns (e.g. classic Spring conventions dominate over WebFlux or functional styles). This is vendor independent, it's a structural bias toward established architectures over current best practice.
A self reinforcing ratchet. As AI generates more code, that code becomes training data for the next model. The set of architectures a model will volunteer narrows over time, generation by generation.

The takeaway: architectural decision making is shifting from merit based selection toward whoever controls the agent's configuration. That suggests teams should treat rules files / system prompts as first class architectural artifacts that need governance, review, and ownership, the same way we treat other architecture decisions.

Full article: https://blog.officefloor.net/2026/06/whoever-sets-default-sets-architecture.html

Do you already govern your rules files this way, or is this still adhoc on your teams?

Premise: AI coding assistants are most fluent in the architectures that dominated the 2010–2025 era. Spring being the poster child because that's where approximately 20 years of training data lives. Anything newer or in house has almost no corpus so the model steers you back to the mainstream. If AI assisted development becomes the default way we build, do we effectively freeze architecture at 2020? This is not because those patterns are best but because that's where the documentation mass sits?

That's the worry. But my testing pushed back on it in an interesting way.

I converted Spring PetClinic REST to a very different approach. I converted it to explicit, YAML-declared REST endpoints where the directory structure mirrors the URL structure, so control flow reads as a "search index" instead of implicit call stack wiring. Two findings:

It took approximately 5 iterations to get the model using the new pattern. The failures were documentation gaps not AI stubbornness. Once the schema was fully and accurately specified it adopted the unfamiliar pattern readily.
The key realization. AI doesn't need to have seen ten thousand examples of a YAML driven REST framework to use one correctly. It needs an accurate complete description.

So the stuck in 2020 risk might be real but conditional. AI defaults to 2020 when a new architecture is under documented. Give it a complete machine legible spec and the lock in breaks. Which flips the question. The barrier to post 2020 architecture isn't the AI's conservatism. It's whether we can describe our designs rigorously enough for an AI that's never seen them.

Discussion:

- Is stuck in 2020 a genuine trajectory or does documentation quality fully dissolve it?

- Does this create pressure toward explicit/declarative designs (legible to AI) and against clever implicit/convention driven ones? (is that good or bad for architecture?)

- Have you watched an AI assistant pull your team back toward mainstream patterns and away from something better suited?

Full write-up (my blog): https://blog.officefloor.net/2026/06/will-ai-keep-us-stuck-in-2020.html

Whoever sets the default sets the architecture

Will AI keep us stuck in 2020-era architectures?