Drawing on years of building rust-analyzer (200K+ lines) and IntelliJ's Kotlin plugin, Kladov argues that architectural skill is pattern recognition trained by exposure to real codebases. He contends that books and courses teach vocabulary (layers, hexagons, ports-and-adapters) without teaching the underlying ability to see structural decisions, their rationale, and the tradeoffs they encode.
Kladov identifies a systemic problem: juniors get handed pattern catalogs while seniors get handed whiteboards, but neither approach reliably develops the skill of making good structural decisions under real constraints like time pressure, team size, and evolving requirements. The real skill is noticing concrete couplings — like a function taking a concrete type where it should take a trait — not knowing that the Strategy pattern exists.
The post's 540 points and 109 comments signal strong resonance with a developer audience that has grown tired of abstract architecture frameworks and pattern-catalog thinking. The enthusiastic reception suggests widespread agreement that the industry over-indexes on theoretical architecture knowledge at the expense of practical structural judgment built through hands-on experience.
Alex Kladov — better known as matklad, the creator of rust-analyzer — published a long-form essay on how developers actually learn software architecture. The post hit 540 points on Hacker News, resonating with a developer audience that has grown increasingly skeptical of architecture astronautics and pattern-catalog thinking.
The essay's thesis is deceptively simple: You learn architecture by reading and writing real systems, not by studying architecture in the abstract. Kladov argues that most architecture books and courses teach a vocabulary (layers, hexagons, ports-and-adapters) without teaching the underlying skill — the ability to look at a codebase and see where the structural decisions are, why they were made, and what tradeoffs they encode.
This isn't a vague "just build stuff" platitude. Kladov gets specific, drawing on his years building rust-analyzer (a 200K+ line Rust codebase that serves as the language server for millions of developers) and his earlier work on IntelliJ's Kotlin plugin at JetBrains.
The software industry has an architecture education problem. Junior developers get handed pattern catalogs. Senior developers get handed whiteboards. Neither approach reliably produces engineers who make good structural decisions under real constraints — time pressure, team size, evolving requirements, performance budgets.
Kladov's essay cuts through this by identifying what architectural skill actually consists of. It's not knowing that the Strategy pattern exists. It's the ability to look at a function signature and notice that it takes a concrete type where it should take a trait (or interface), creating an unnecessary coupling that will make the next feature twice as hard to implement. Architecture is pattern recognition applied to code structure, and like all pattern recognition, it's trained by exposure to examples — not by memorizing taxonomies.
The post draws heavily from rust-analyzer's evolution. Kladov describes specific architectural decisions: how the project uses a "salsa"-style incremental computation framework to avoid recomputing the entire program model on every keystroke, how cancellation safety is enforced at the type level rather than by convention, and how the codebase maintains a strict layering where the core analysis engine has zero knowledge of the LSP protocol that sits on top of it. These aren't abstract principles — they're concrete design choices with measurable consequences for latency, correctness, and contributor onboarding time.
One particularly sharp observation concerns dependency inversion. Most developers learn this as "depend on abstractions, not concretions" — a rule so vague it's almost useless. Kladov reframes it as a structural question: at every module boundary, ask which side owns the interface definition, because that determines which side can change independently. In rust-analyzer, the IDE-facing layer defines the traits that the analysis engine implements. This means you can swap out the analysis engine (theoretically) without touching the IDE integration — but more importantly, it means the analysis team and the IDE team can work in parallel without merge conflicts. The architecture serves the team structure, not the other way around.
The HN discussion surfaced a healthy debate about whether this approach privileges systems programmers. Several commenters noted that web application architecture involves different tradeoffs — you're optimizing for developer velocity and feature flexibility, not for latency and correctness. Kladov's examples are drawn from compilers and language tooling, domains where the "right" architecture is more legible because the problem is more constrained. A CRUD app with 47 microservices has architectural problems too, but they're harder to learn from because the feedback loops are longer and noisier.
Other commenters pushed back on the anti-book stance, pointing to genuinely useful architecture texts: "A Philosophy of Software Design" by John Ousterhout, "Designing Data-Intensive Applications" by Martin Kleppmann, and Kladov's own previous recommendations. The consensus seemed to be that the best architecture books are the ones that work through real systems in detail — not the ones that present patterns as Platonic ideals.
If you buy Kladov's argument — and the HN upvote count suggests many practitioners do — it has concrete implications for how you invest your learning time.
Stop reading architecture pattern catalogs and start reading source code of well-regarded projects in your domain. If you build web services, read the internals of a framework you respect (not just its docs). If you build data pipelines, read how DuckDB or SQLite organize their query planners. The goal isn't to copy their architecture — it's to train your pattern recognition on real tradeoff decisions made by skilled engineers under real constraints.
For team leads, the implication is about code review. Architecture isn't something you teach in a brown-bag session and then hope people apply. It's something you reinforce in every PR review by asking structural questions: "Why is this a new module instead of an extension of the existing one?" "What happens to this abstraction when we add the next feature?" "Which team owns this interface?" The best architecture education happens at review time, when the structural decision is concrete and the cost of getting it wrong is visible.
For hiring, Kladov's framing suggests that architecture interview questions ("design a URL shortener") test presentation skills more than structural judgment. A better signal: give candidates a real codebase with a real structural problem and ask them to identify it. Can they see the coupling that makes the next feature hard? Can they propose a change that reduces it without over-engineering?
Kladov's essay arrives at an interesting moment. AI coding assistants are getting better at generating code, which means the bottleneck is shifting from "writing code" to "deciding how code should be organized." If architecture is indeed a pattern-recognition skill trained by exposure, then the developers who've read the most good code will have the largest advantage in an AI-augmented world — because they'll know what good structure looks like when the AI generates something that compiles but is architecturally wrong. The practitioners who invested in understanding *why* systems are shaped the way they are won't be automated away. They'll be the ones the AI can't replace.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.