Architecture — composing systems above the AI

1. The model writes pieces, you build systems

The model is great at the function. Pretty good at the file. Okay at the module. Bad at the system.

This is not a temporary weakness that will go away when models get smarter. It's structural. A system is the part of the code that lives across files, across services, across time, across the parts of your team that don't agree about what should happen next. Holding that in working memory is hard for humans and impossible for models that load fresh context every call.

So the model writes the pieces. You build the system the pieces fit into. That's the architecture skill, and it stays human for the foreseeable future.

2. Why "ask the AI to generate a whole microservice" usually fails

You'll see demos where someone types "build me a Twitter clone" and the model produces three thousand lines of code that compile and run. Try it on real work and you'll find it doesn't survive contact with anything.

The reasons:

No knowledge of your existing system. The model invents a fresh architecture every time. Your real microservice has to fit alongside ten others that already exist, use the same auth library, follow the same logging conventions, deploy through the same pipeline. The fresh architecture doesn't.

No understanding of what's about to change. Your team knows you're migrating the auth system next quarter. The model doesn't, so it builds against the old auth pattern that's about to be deprecated.

No memory of why decisions were made. Three years ago someone tried the obvious approach and it failed for a reason that's not in the code. The model proposes the obvious approach. You catch it because you remember the story; the model can't.

No taste for trade-offs. The model picks the textbook solution. The textbook solution is usually fine for a textbook problem. Real problems have constraints — budget, latency, team skill, operational complexity — that the textbook doesn't mention.

3. What architecture vision looks like

Architecture vision is the ability to hold a system in your head and reason about it. Not the code — the system. Which services exist. Which talks to which. Where state lives. Where the failure modes are. What deploys together and what doesn't. What's expensive at scale. What blocks the next feature.

A senior engineer with architecture vision can answer "where would I put a new feature that does X" in under a minute, because they've already located the seam in their head where X belongs. A junior asks the model, gets a reasonable answer, implements it in a place that technically works but that everyone on the team would have known was the wrong place.

The vision is not magic. It's the result of having held the system in your head long enough to know its shape. You build it by being there when the decisions were made, reading the code carefully, asking why things are the way they are, and remembering the answers.

4. The composition skill

Once you have a system in your head, you compose AI-generated pieces into it. Composition looks like this:

You decompose the feature into pieces small enough to spec well. You write a spec for each piece — input, output, contract, where it fits in the system. You ask the model to produce each piece. You verify each piece independently. Then you wire them together yourself, because the wiring is where the system-level decisions live.

The composition is the part the model can't do. Not because it's hard code — it's often three lines of imports and a function call. It's because the composition is where the system shows up, and the model doesn't have the system.

5. The example

Concrete example, kept short. You're adding a feature: when a user uploads a CSV, parse it, validate it, and email them a confirmation.

The model can write the CSV parser. It can write the validator. It can write the email sender. It can write each one in a few seconds, well.

The model cannot answer: should the parse and validate run in the request handler, or async on a queue? Should the email go through your existing transactional pipeline or directly through the email provider? What happens if the parse takes thirty seconds? What's the retry policy if the email fails? Where does the file get stored between steps? Who cleans it up?

Those are architecture questions. The answers depend on your existing infrastructure, your team's conventions, your operational tolerance, your cost budget. The model has none of that. You do.

You answer the architecture questions. Then you ask the model for the three pieces, each with a tight spec. Then you compose them. The system survives because you held the shape.

6. The deep dive

This unit is the brief version. The full treatment of system-level AI patterns — how to compose model outputs into real production systems — is its own course on Codritium. If architecture clicks for you as the bottleneck, that's where you go next: [[api-to-architecture]].

For now: when the model gives you a big slab of code, ask yourself whether the slab is one piece (one thing, one spec, one verification) or several pieces glued together with assumptions. If it's the second, break it apart. The seams between pieces are where your judgment lives.