For the past few decades, between the person who wanted to make something into a digital tool and the tool itself, there always stood one more person. The developer. That position was so obvious no one questioned it — just as you leave a car to a mechanic, you leave a tool to the one who makes it. We accepted this division of labor like a law of nature. The one who knows the work and the one who builds the tool are different people, and the bridge between them is precisely the requirements, the specifications, the outsourcing contracts. But if you compress into a single sentence what this magazine has done across six issues, it is this: that one person's position began to shake. And the shaking is not an event of technology. It is an event in which a person's place changes. The one who makes the tool moves over to the one who knows the tool best. This piece retraces how that one sentence arrived, at the fingertips of the real people we met over six months. We won't start from the abstract. We'll start from people, and end with people.

The old order
First let's draw, exactly, the order we're trying to leave. If a lawyer wanted a tool for consultation records, he had to explain his work to a developer. If a farmer wanted to turn thirty years of field records into a screen, he had to find a developer and ask. If a teacher wanted to turn her grading rubric into a tool, she had to translate that rubric into a requirements document and hand it over. The one who knew the domain was always in the seat that explains from behind, and the developer always in the seat that builds up front.
This order carried a loss that doesn't catch the eye. The subtlety of a domain wears down in transit. Nuances like "in this case it's a little different" or "here you have to look at this first" — passing through the explanation, through the requirements document, through the developer's interpretation, through the compromise of schedule and budget — wear away bit by bit. The one who knew best couldn't build it himself, and the one who built it didn't know that much. There was always a gap between them. The place where, after it's all built, "this isn't it" comes out; the place where months pass again waiting for the second version.
We didn't even count that gap as a cost. "That's just how it is." A tool that couldn't be built didn't even occur to anyone. Too small, only I'd use it, embarrassing to call a developer over — and so tools that were never even born and vanished sat in a heap in every expert's desk drawer.
The one who knew best couldn't build it, and the one who built it didn't know that much. That gap lay beneath nearly every tool.
Why the order flips
What this magazine showed issue by issue was, in fact, one piece at a time of flipping that old order. Let's now line up the pieces that looked scattered.
"The Age of Apps Without Installation" lifted out, whole, the chain that sends what's built to the user — build, review, install, update. "Why We Gave Up Compiling" turned the screen from ice into liquid. What ought to change often is no longer frozen in the hardest place to change (inside compiled hardware). "The Foundation Is Already There" showed that eight-tenths of making something is domain knowledge, and that the wall of the missing two-tenths has come down decisively. "Every Server Is an App" showed that a system already running becomes an app. And "Experience Compounds" showed that what's made this way doesn't stop at being made once, but grows on its own.
Put these five pieces together and they become one conclusion. *Making no longer requires being a developer.** When the screen grows light as one axis you lay on, and the missing two-tenths becomes a matter of laying on rather than building* — the person who already has the eight-tenths can stand in front himself. The domain expert walks out from the seat where he explained from behind, into the seat where he builds up front. The subtlety that wore away in transit now becomes a tool directly, without wearing away.
For decades the domain expert explained from behind, and the developer built up front. That order flips. The person who knows best what to make now stands in front.
This is the one sentence of this magazine's six months. But left as a sentence alone, it ends up just another plausible vision. We could arrive at this place because that sentence had already happened at people's fingertips.
The people we met
So as not to leave it abstract, let's call up the people these six issues actually brought. They are not metaphors.
Jeong Bok-san (58), who grows tomatoes in Hwacheon, Gangwon Province, was someone who used the computer to look up market prices and search. Eight greenhouses, six crops, thirty years of farming. In the shed, thirty handwritten farming notebooks of thirty years slept under dust, never to be opened again. They were full of records like "the tomatoes in greenhouse 3 got soft rot in July this year" — records only he could read and only he knew the meaning of. He didn't write a single line of code. He simply knew what he had to look at each morning — which crop in which greenhouse, against the record of a few days before, which signal he must not miss. Now his phone shows "crops to check today." Instead of a hoe he carries that one screen and walks the greenhouses at dawn. Thirty notebooks that had been dead became, at last, a single screen he could ask.
Han Mi-jeong, a middle-school Korean-language teacher, was buried each week under performance-assessment answers from 132 students across four classes. She had never learned to develop. But for twenty years she had known what it means to grade by the same yardstick. When she moved that standard onto a screen, the evening after the test her tablet showed "answers to grade today" along with a checklist. She got her midnights back.
Han Do-gyeong, director of a family-medicine clinic, doesn't know code. But when seeing a chronic-disease patient on a follow-up visit, he knows better than anyone the flow of what to ask first and what is dangerous to leave out. He moved only that flow onto a screen. And a diagnostic tool he deliberately did not make — knowing what should be left to a person is also domain knowledge.
Yun Jae-seong, a tax accountant holding 180 clients at a solo office, built himself a screen that shows "today's deadlines" each morning. Which client has how many days left on which filing, what penalties attach if you miss something — the flow of reading receipts, building up each client's history, distilling the deadlines, and posting notices was something no developer could know from the start, something only he knew at his fingertips. Had he outsourced it, half that subtlety would already have worn away in the first meeting.
Han Ji-yeon, a PM at a translation company, now holds alone, with her own tool, the whole flow of gathering, organizing, table-making, reviewing, and sending that four or five people used to split. Not by cutting people, but by extending her own hands. The tool didn't replace her. It only sent her hands farther.
These people have something in common. None of them became a developer. None of them got a new profession. They simply brought forward what they already knew best — thirty years of fields, twenty years of grading, a daily clinical flow, a feel for 180 clients' deadlines. The one missing axis — the screen — had become something you lay on, not something you build.
Without a single line of code, by his own hand. That this one sentence repeated identically across six people — that's all this magazine discovered.
Why now, of all times
Then we have to ask. These people knew their work best thirty years ago too. Jeong Bok-san's field was there then; Han Mi-jeong's grading rubric was in her head then. So why is it only now that they stand in front?
The answer lies in this: the physical nature of the one missing axis has changed. For a long time, making a tool required two things — knowing what to make (the domain), and building it so a machine understands (the screen and the code). The first eight-tenths Jeong Bok-san already had in abundance. What stopped him was always the latter two-tenths. And those two-tenths were building — like laying brick on brick, writing the screen in code and hardening it firmly inside the device. That was a different profession, one you had to spend a lifetime learning.
This is precisely the heart of the change this magazine tracked across six issues. Those two-tenths shifted from building to laying on. As the screen becomes not a brick hardened inside the device but a definition laid lightly on a server — a screen stands by merely saying "what to show." You don't have to write code and harden it. That lifetime skill once needed for building is no longer the price of entry. The wall Jeong Bok-san couldn't cross didn't vanish; it lowered to a height you can cross with words.
So the person who has the eight-tenths finally lays on the two-tenths himself. What had been two people's work becomes one person's work. The reason it's now and not thirty years ago is only that — because the one axis that blocked him shifted from building to laying on.
What it flips — the reinstatement of the soft
Here we must absolutely head off a common misunderstanding. This is not saying "now everyone becomes a developer." It's the exact opposite. It's saying you can make things without becoming a developer. Not "learn to code," but "coding is less needed to make." Jeong Bok-san never learned SQL, and Han Mi-jeong never did find out what a function is. That's the heart of it.
And in that very moment, something long treated as soft hardens again — knowing a domain deeply. A farmer's thirty years, a teacher's grading rubric, a doctor's clinical flow, a tax accountant's feel for deadlines, a translator's eye for quality. That thick thing, once pushed aside as secondary with "that's not a skill," "that's just experience," "anyone could do that given time," becomes, in this age, the core asset of the tool.
This is no small reinstatement. Throughout the age of technology, domain experience was treated only as an input value to explain and hand off to a developer. A thick career may have been respected in the meeting room, but in the seat where tools are made it always had to stay one step removed. Now it stands in front. And once it stands in front, the arithmetic flips completely.
| The old order | The changed order | |
|---|---|---|
| The one who knows the domain | explains from behind (input value) | builds directly up front (asset) |
| The act of making | the developer builds | the expert lays on |
| Subtlety | wears away in transit | becomes a tool directly, unworn |
| A thick career | respected only in the meeting room | the strongest builder's weapon |
| A small tool | given up, too embarrassing to ask for | made by oneself in ten minutes |
The one who knows best becomes the strongest builder — the thicker the foundation, the longer the career. Because the one missing axis (the screen) is of nearly the same thickness for anyone, while the foundation one holds is that person's alone. A person of thirty years gains the edge over a person of three. At least in this age, having done something long is not a loss but a compounding.
Honestly
The more a piece is about vision, the more honest it must be about limits. Otherwise all of this becomes a hollow declaration.
It is not that the developer disappears. What must be hard — the runtime, the protocol, real-time control, the deep layers of security, complex algorithms, the bedrock of large-scale data — is still, and even more so, the developer's domain. It has to be. Jeong Bok-san's screen comes up smoothly because, beneath it, someone built the engine that draws it, and built it firm. What changes is the surface. That surface a domain expert once had to cross to make his own tool now becomes theirs. The hard foundation goes deeper, and the surface you make on opens wider. The two are not competition but a division of labor — the developer digs deeper, the expert builds his own surface. Depth holds up breadth.
And it isn't that every tool is made this way. Large systems, refined products, services used by millions at once still need professional development, and will go on doing so. What this age newly opens is the place for the countless small tools that sat in between — the ones that fit your own work exactly, that only you use, that you've gone without because they couldn't be built. One of Jeong Bok-san's screens doesn't change the world. But if such screens spring up as many as there are farmers, as many as there are teachers, as many as there are doctors and tax accountants and translators — the sum of those small things is by no means small. Rather, that sum covers the world more thickly than a few big products.
That Han Do-gyeong deliberately did not make a diagnostic tool is one face of the same honesty. Drawing the boundary of what to leave to the tool and what to leave to the person doesn't vanish because the screen got easy. It becomes more important. Being able to make something doesn't mean you should make all of it. Knowing where the tool's work ends and a person's judgment begins is also the domain expert's share. What got easy is the hand that makes, not the responsibility for what ought to be made.
One last thing. This is not magic. Jeong Bok-san and Han Mi-jeong, too, were stuck at first and tried again. They had to learn how to restate the flow in their heads in the language of the screen. Before the single line "crops to check today" became a screen, he had to ask himself again why his notebook had been written the way it was. It's only that this learning was a different kind of thing from learning a programming language from scratch. The wall didn't vanish; it lowered to a height worth crossing. Honestly, that's about it. And that much changes everything.
Not an end but a beginning
This issue is the last of six months since launch. But it is not an end. Because domains are endlessly many, and people who will make their own tools are endlessly many. The places we brought across these six issues — the chip that ran without a screen, the instrument with no API, the dashcam footage no one could touch, the equipment screen made in thirty minutes, and Jeong Bok-san, Han Mi-jeong, Han Do-gyeong, Yun Jae-seong, Han Ji-yeon, the one family that handed down notebooks across three generations — are only a few cases of the beginning. One sliver of the iceberg.
Your domain will be nowhere in this magazine. That's the heart of it. We called up a farmer and a teacher and a doctor and a tax accountant and a translator not because they're special, but because they're everywhere. In your work too there is something like Jeong Bok-san's thirty notebooks. A flow that lives only in your head and was never carried to anyone, a judgment you repeated by hand every time, a small tool you wanted but folded away, too embarrassed to ask for. The seat that knows best is known by you, and the one missing axis is now something you lay on, not something you build.
What this magazine did was only point a finger at that seat. Looking where the finger points, and actually making something there — that's you, standing in front. And if you hit a place where you're stuck, there are people who walked the same road first. Jeong Bok-san did. Han Mi-jeong did. They too, at first, said "how could I ever do this."
For decades we believed "the one who makes" and "the one who knows" were different people. What this magazine showed over six months is that the two can become the same person — and that when they do, the tool turns out best. This magazine was not an end but the first signpost pointing to that beginning. Now it's your turn to stand in front.
makemind.dev "Horizon" — This piece opens the volume "The Age of Domain Experts" and closes six months since launch. The age where the one who knows best what to make stands in front begins here.