Architecture Crash Course for the Generative-AI Era — How to Read This Book

About this article

This article is the entry point (00 Overview) of the Architecture Crash Course for the Generative-AI Era series. It is a TOC-style article that explains how to read this book and how to pick a starting point that fits you.

The series is roughly 80 articles long and lays out the full picture of what an IT architect actually does — written for a non-specialist audience: managers, PMs, engineers who specialize in one area, and engineers in their first three years on the job. It is not a book to read front-to-back. It is a dictionary you reach for when you need it.

What is architecture in the first place

Imagine building a house. Floor plan, structure, plumbing, wiring — the decisions about “what kind of house to build” come first, and the carpenters work based on those decisions. If you start hammering nails without blueprints, you won’t end up with a livable house.

Architecture in IT is the same. The system’s overall skeleton, technology selection, data flow, security policy — the bundle of decisions that must be made before writing code is architecture. And the person who makes these decisions is the IT architect.

If you start development without architecture, contradictions erupt as scale grows, and the cost of fixing things later becomes tens of times higher than deciding upfront. In the AI era where the value of “writing code” has declined, this power of “deciding what to build” has become the strongest weapon.

Why architecture, why now in the AI era

“In an era where AI writes my code, what am I going to be paid for?” As of April 2026, every engineer, PM, and manager I talk to has asked themselves a version of this question.

The work of writing code has gotten dramatically lighter in the past two or three years. As long as the requirements are settled, AI now produces frontend screens, backend CRUD, SQL queries, and unit tests in seconds. Vibe coding — describing requirements to AI in natural language and reviewing the generated output as a human — has become an industry standard. With that shift, the value of an engineer is moving rapidly from “can write code” to “can decide what to build.”

Put bluntly, the scarcity of “being able to write code” is no longer a moat.

The bundle of decisions that determines what gets built is exactly what we call architecture. It is the work of choosing a system’s skeleton and being able to defend why you chose it.

Meanwhile, the things you have to decide before you start writing have only gotten heavier. For example:

• Split into microservices, or stay monolithic? (A monolith bundles everything into one large application.)
• PostgreSQL or DynamoDB? (Will it hold up under future consistency requirements?)
• Build auth in-house, or hand it to an IDaaS? (IDaaS = Identity as a Service — auth provided as a managed external service.)
• AWS or Google Cloud? (Will I regret the vendor lock-in in five years?)

These are questions AI cannot answer for you. AI knows code patterns, but it cannot weigh your team’s skills, budget, existing assets, and business strategy against each other and produce the right answer.

This is the territory only a human architect can step into, and I believe it is the bundle of knowledge whose value will appreciate the most over the next 5-10 years.

Designs that age well in the AI era, and ones that don’t

In the AI era, the design itself changes. Designs that pair well with AI and designs that fight it have split into clearly different camps.

AI-friendly designs	AI-unfriendly designs
Things you can manage as code (IaC, type definitions, schemas)	GUI-only black-box tools
Mainstream standard protocols (OAuth, OIDC, REST)	Proprietary protocols, in-house frameworks
Convention-driven frameworks (Rails-style, Next.js-style)	Designs with too many degrees of freedom

Quick term refresher: IaC = Infrastructure as Code (defining server configuration as code), and OAuth / OIDC are the industry-standard protocols for federated login.

In other words, “AI-friendly design” converges with “human-friendly design.” Mainstream protocols and mainstream products have abundant training data behind them, so AI hallucinates less (a hallucination is when AI states something incorrect with confidence). Type-safe, declarative, information-rich code is what determines how accurately AI can generate against your project.

Conversely, custom-built solutions, GUI-only tools, and in-house frameworks are the choices most likely to become technical debt — AI cannot reason about them. This series will repeatedly demonstrate that convergence across every domain.

That said, real problems AI cannot solve do exist (distributed transactions, the migration cost of vendor lock-in, etc.) and I will be honest about those throughout the series.

Who this series is for

The audience is anyone working in IT, regardless of title or years of experience. More concretely:

• Managers and PMs — to understand the rationale behind technical decisions and reinforce your own.
• Consultants — to validate the technical proposals you put in front of clients.
• Specialists (frontend-only, backend-only, infra-only engineers) — to raise your resolution into adjacent domains.
• Engineers in their first three years — to put your senior teammates’ decisions into your own words.
• Mid-career and aspiring architects — to learn the patterns of technical judgment systematically.

For engineers who are not full-stack, the conceptual knowledge and decision criteria in each domain translate directly into day-job value.

A frontend specialist who knows infra. A backend specialist who knows security. That resolution into adjacent domains is, I believe, the core of what makes an engineer survive in the AI era.

AI will happily generate code outside your specialty. But whether that choice will still be the right one in five years is something only a human can judge.

What sets this series apart

There are countless intro books and tech blogs out there. This series differentiates itself in the following ways:

• Every article bakes in decision criteria assuming AI-driven (vibe coding) development. Treating “can AI write this fluently / can this be declared in code” as a first-class axis is what separates this series from other introductory notes.
• Heavy use of named real-world incidents. Segment’s 2020 monolith reversal, Amazon Prime Video’s 2023 monolith re-merge, Knight Capital’s 2012 trading disaster, GitLab’s 2017 database deletion, Google Stadia’s 2023 wind-down, Salesforce’s 1999 multi-tenant origin story — none of this stays at the level of textbook abstractions.
• Phase tables, anti-pattern tables, and numeric gates appear in every article. No empty filler words like “phased rollout” or “cautiously” — just concrete numbers (monthly cost, headcount, SLO, time).
• Written as continuous prose, in the style of a technical book or tech blog, not slide bullet lists.

I consider an article that ends at “there appear to be options” to be of zero value. The goal is that by the end of an article, the reader can answer, for their own project: “what are my choices?”, “on what basis do I pick?”, and “given my situation, here is my hypothesis for what to choose.”

The overall structure of this series

The series consists of about 80 articles organized into 12 categories. The first category, “Overview”, plays the role of a shared foundation for navigating everything else.

flowchart TB
    OV["00 Overview<br/>(Map & Compass)"]
    SY["10 System"]
    SW["20 Software"]
    AP["25 Application"]
    FE["30 Frontend"]
    DA["40 Data"]
    SE["50 Security"]
    DV["60 DevOps"]
    EA["70 EA"]
    SO["80 Solution"]
    CA["85 Cases"]
    AX["95 Appendix"]
    OV --> SY
    OV --> SW
    OV --> AP
    OV --> FE
    OV --> DA
    OV --> SE
    OV --> DV
    EA --> SO --> CA
    SY -.implementation.-> EA
    SW -.implementation.-> EA
    AX -.cross-ref.-> SY
    AX -.cross-ref.-> SE
    AX -.cross-ref.-> DV
    classDef root fill:#dbeafe,stroke:#2563eb,stroke-width:2px;
    classDef impl fill:#f0f9ff,stroke:#0369a1;
    classDef strategy fill:#fef3c7,stroke:#d97706;
    classDef ref fill:#fae8ff,stroke:#a21caf;
    class OV root;
    class SY,SW,AP,FE,DA,SE,DV impl;
    class EA,SO,CA strategy;
    class AX ref;

#	Category	Scope
00	Overview	The architect’s role, the learning roadmap, the glossary
10	System Architecture	Infrastructure, runtime, cloud, network, security foundation, monitoring, BCP, cost
20	Software Architecture	Overall structure, language, framework, API, transactions, auth sessions
25	Application Architecture	Class design, domain, naming, errors
30	Frontend Architecture	Hosting, rendering, state management, CSS, BFF, SEO
40	Data Architecture	DB selection, modeling, platform, ETL, streaming, governance
50	Security Architecture	AuthN, AuthZ, encryption, zero trust, secrets, vulnerability scanning
60	DevOps Architecture	VCS, CI/CD, test, deploy, monitoring, SLO, SRE
70	Enterprise Architecture	BA, DA, AA, TA, EA frameworks
80	Solution Architecture	Requirements, NFR, estimation, PoC
85	Case Studies	Concrete selection contrasts by scale and phase
95	Appendix	Anti-pattern collection, best-practice collection, major incident collection

The number prefixes are the category ordering. The gaps in 00 / 10 / 20 / 25 / 30 / 40 / 50 / 60 / 70 / 80 / 85 / 95 are intentionally left for future additions.

The “Overview” category contains four articles including this one. As a default reading order: this article first, then “What an IT Architect Actually Does”, then the “Learning Roadmap.” The glossary is fine to consult only when you need to look something up.

How the three companion articles fit

The four articles in the “Overview” category break down like this:

#	Article	Scope
01	What an IT Architect Actually Does	The architect’s role, types of architecture, ADRs, the One-way Door model
02	Learning Roadmap	Reading routes by role and experience — “where should I start?“
03	Glossary	A-Z and 50-on indexed lookup of every specialized term

When in doubt, follow “01 → 02 → the rest” in order. If a term blocks you, jump back to 03. These three articles are designed to live next to you as references throughout the series.

Where to start reading

Different starting points by what you want to know:

“What does an architect actually do?”

Start with “What an IT Architect Actually Does”. The role, responsibilities, types of architecture, and core mindset are all laid out, so a single article gives you the full picture.

”Where should I start, given my role?”

Read the “Learning Roadmap”. It lists concrete reading orders for managers, PMs, backend engineers, frontend engineers, new grads, and mid-career engineers as Routes A-E.

”I don’t recognize the terms used in the articles.”

Use the “Glossary”. Each term links to its first appearance or to a representative article that explains it.

That said, individual articles also include a one-line gloss the first time a specialized term appears, so you should not need to keep jumping back to the glossary. Use it when you want a bird’s-eye view or when you want to hop between related articles via terms.

How to use the series overall

This series is designed to be referenced, not read front-to-back. Concretely:

• Read each topic to absorb the concepts.
• Take the checklists at the end of each article and apply them to your own project.
• When something cuts across categories, the appendix’s anti-pattern collection and major-incident collection are great reverse lookups.
• When you want concrete design examples, the Case Studies category gives you side-by-side comparisons by scale and phase.

The expected usage is to jump from the table of contents and ping-pong between adjacent articles.

Tracing topics that span categories

Some themes span multiple categories, so you switch articles based on the angle you’re after. The most common ones:

Theme	Angle and category
Authentication / Authorization	Implementation tech (20) / Policy design (50) / Browser-side defense (30)
Datastores	System-wide placement (10) / Per-app selection (40)
Security	The system-architecture map (10) / Per-domain deep dives (50)
Monitoring / Operations	Design-time requirements (10) / Implementation and operations (60)
Data Architecture	Enterprise-strategy view (70) / Per-project view (40)
Tech selection	Enterprise-standard view (70) / Per-project view (10)
Application design	Enterprise portfolio (70) / Per-project implementation (25, 20)

When in doubt, the “Scope of this article” note at the top of each article will route you to the right viewpoint.

Summary

This article serves as the entry point of the Architecture Crash Course for the Generative-AI Era series, explaining how to read the book and how to pick a reading order.

In the AI era, the scarcity of being able to write code is going down. What goes up is “the ability to decide what to build” — that is, architectural judgment. This series organizes the criteria behind those judgments across roughly 80 articles.

The next article finally enters the main content, explaining the full picture of what an IT architect is, under the title “What an IT Architect Actually Does”.

I hope you’ll read the next article as well.