Building a small website today takes about ten minutes. A landing page, a form, a data table to store the submissions and an admin view to read them. You describe what you want, an AI coding tool writes the code, and then it deploys the service.
Twenty years ago the same website started with a harder question: where does the code run? You picked a machine, installed an operating system, configured the runtime, opened the network ports and set up a way to release changes.
New technology keeps arriving faster#
That question has been answered six times in thirty years.
| Stage | Roughly | The problem it solved |
|---|---|---|
| Own hardware | 1990s | The starting point |
| x86 virtualization | 2001 | One machine running one operating system was wasteful |
| Cloud (EC2) | 2006 | Buying machines and building data centers was slow and expensive |
| Containers (Docker) | 2013 | Environments differed between machines, and delivery was slow |
| Orchestration (Kubernetes) | 2014 | Manual scheduling broke down once containers multiplied |
| Functions (Lambda) | 2014 | Nobody wanted to manage servers at all |
Two things stand out in that table.
First, no generation kills the one before it. Each one wraps the one below and solves what that one left behind, so deployment keeps getting easier to put into production.
Second, the gaps keep shrinking: roughly 10, 5, 7 and 1 years between stages, with three of them landing inside twenty months, from March 2013 to November 2014, while the first waited two decades.
Then the chain collapsed into a single step. An AI coding tool will take the whole thing now: it writes the code, sets up the environment and deploys the service. The same website that once took a week of preparation comes together in minutes. The point is the speed, not the tool.
How to understand a technology#
Deployment is not a single technology, and neither are Kubernetes and AI coding. We talk about each as if the name covered one skill, but what sits under it is not the same kind of thing: some are notations you memorize, some are products you choose, some are ideas you compare, and some are mechanisms underneath. A few of them turn over every few months, and a few have not changed in decades. Modeling a technology in layers is what makes that visible.
The four layers#
The four layers are a way to take a technology apart. Splitting it shows where each piece lands: a technology belongs to one layer, while a product reaches across several. That is what makes the real questions answerable: how to learn it, whether it is worth learning and how much time it deserves.
How to learn each layer#
The next table answers the first of those three questions. At the top you work top-down, starting at the surface and going down as questions appear. Underneath you work bottom-up, starting at the mechanism and building up. What separates the rows is then how far to go and what tells you that you have gone far enough.
| Layer | How to learn it | How deep to go | How to check yourself |
|---|---|---|---|
| Syntax and usage | top-down and fast: let AI write while you check the result | enough to get the job done, since the exact wording is not worth memorising | you can see at a glance when the tool has gone off course |
| Framework and tooling | top-down: take the hottest tool today, run your first project with AI beside you, then step back and ask what this class of tool actually solves | enough to use it and to see what the class solves | you can say what the class solves, not just how to use one product |
| Paradigm | bottom-up: keep asking why it is ordered that way, as in the sequence steering, requirements, design and tasks | enough to follow the design philosophy rather than the steps | you can say what breaks when that order is reversed |
| Principle and mechanism | bottom-up: let AI tutor you into a map of your own | enough to hold the map, not the details | at three in the morning, when AI hands you five guesses, you pick the right one |
That is the whole model: four layers, each with its own way in, its own depth and its own test. It holds for any technology that is new to you.
How to understand AI coding#
The model stays abstract until it lands on a technology you actually use. AI coding is the obvious place to test it, because almost everyone is already working with it. When a new technology arrives, there is one judgement to make: split it, see which layers it spans and learn each layer its own way. You do not have to label yourself top-down or bottom-up first. In the AI era the two have largely merged, so there is little to gain by picking a side in advance.
Where AI coding lands#
| Layer | In AI coding |
|---|---|
| Syntax and usage | the wording of a prompt, how the tool is configured, what its slash commands are called |
| Framework and tooling | Cursor, Claude Code, Kiro, Qoder and the like |
| Paradigm | how you hand over context, how you frame the environment, how the loop is organised, and the spec flow behind tools like Kiro: steering, requirements, design and tasks |
| Principle and mechanism | what an LLM actually is: why hallucination cannot be removed, why the context window is a hard limit, why an agent needs a verification loop |
Two conclusions fall out of that table. AI coding spans all four layers, so “should I learn AI coding” is the wrong question. It breaks into four. Each layer is also learned differently.
How to learn it, layer by layer#
- Usage: you move through it fast, letting AI write while you check the result. The wording is not worth memorising, but you should see at a glance when the tool has gone off course.
- Tooling: you work top-down, take the hottest tool today, run your first project with AI beside you, then step back and ask what this class of tool actually solves.
- Paradigm: you work bottom-up. This layer is about how context is handed over, so the question is not which steps to follow but why they are ordered that way. Take Kiro and read its flow as a whole: what steering does before anything is written, why requirements come before design, why design comes before tasks and what breaks when that order is reversed. That reasoning is Kiro’s design philosophy, and it is the part worth learning, because it outlives the tool.
- Mechanism: you work bottom-up, letting AI tutor you into building the map. When something breaks at three in the morning and AI hands you five guesses, the map is what picks the right one.
How to learn in the AI era#
Three points to end on. The first two sit at opposite ends of the same table.
Bet early on the top two layers#
Usage and tooling were always the fastest to turn over. Getting a bet wrong there now costs days instead of months, so there is no reason to wait for a technology to settle. Place the bet early and place several at once. All of that starts with an open mind toward whatever is new.
Hold on to the bottom two#
Paradigm and mechanism barely move, so they are the part that travels across generations of tools. Knowledge from the top layers expires with the tools; the principles underneath do not. That payoff takes longest to arrive, which is why you collect a map rather than a memory of details.
Abstract whatever you learn#
Understanding how a technology works is half of it. The other half is pulling the principle out into a shape that is not tied to that one technology, so it carries into the next one and you do not start from zero.
Together they answer the question this article opened with. Not the newest tool, and not the fundamentals alone, but both, plus the abstraction that lets you carry what you learn forward.