Development patterns and frameworks in context of AI/LLMs

Lately I’ve been thinking about how programming frameworks and “best practice” patterns might evolve as AI writes more and more of our code. A lot of what we treat as standard architecture today—MVC/MVVM, strict front-end vs back-end separation, layered services, ORMs, and even the way we slice repos and responsibilities—often feels like it was shaped as much by how teams coordinate as by what computers technically require. These patterns help multiple people move in parallel, reduce collisions, and create clear interfaces between groups. They’ve been incredibly effective for human-scale collaboration.

If AI keeps lowering the cost of writing, refactoring, and stitching code together, do we start to design systems around different constraints? Instead of organizing primarily around team boundaries (“this is the front-end team’s area, that’s the backend team’s area”), do we shift toward organizing around intent and risk boundaries? I can imagine architectures that more explicitly separate an auditable core (payments, identity, security, compliance) from fast-moving edges (UI experiments, personalization, feature tests), not because different teams need a clean hand-off, but because the blast radius matters. In that world, separation still exists, but it’s less about coordination and more about trust zones and invariants.

Frameworks exists largely to make repetitive work cheaper and safer. ORMs and boilerplate-heavy stacks became popular because writing glue code by hand is time-consuming and inconsistent. With AI, two outcomes feel plausible at the same time: we keep those frameworks, but the boilerplate becomes almost invisible because it’s generated and maintained automatically—or we simplify, relying more on explicit primitives (typed queries, thinner services, clearer domain logic) because the productivity penalty that once justified heavy abstractions is smaller when generation and refactoring are cheap. Either way, the “center of gravity” might shift away from frameworks as something humans constantly manage.

Do patterns like MVC and MVVM stay as dominant “how we structure everything,” or whether they become more like implementation details that tools can reshape safely. If AI can refactor across layers, maybe the most important “pattern” becomes less about folder structure and more about guardrails: contracts, schemas, types, state machines, property-based tests, observability, and deployment checks. Would we invest more in constraints that preserve intent and correctness, and less in conventions that primarily prevent humans from stepping on each other.

And then there’s the organizational angle—which I know can be touchy. If AI reduces coordination overhead and increases individual output, do we start seeing more end-to-end ownership by smaller teams (or even a single person for certain product slices)? Not as “one person replaces multiple teams,” but as “fewer hand-offs are required to ship a coherent feature.” I could see specialists becoming even more important, but in a different way: more as platform builders and reviewers who set standards and guardrails for high-risk areas, and less as people pulled into routine implementation for every change.

I’m not claiming any of this is inevitable—but a plausible future. If you’re building systems today, what patterns do you think become more valuable in an AI-assisted world, and which ones become less necessary? Do you expect the boundaries in code-bases to change, or the boundaries in teams, or both? And if AI is increasingly generating the “how,” what do you think becomes the most important thing for humans to be great at: defining intent, reviewing risk, designing constraints, something else? I’d love to hear how others are thinking about it.