Ever handed a report draft to an AI, watched the screen fill up in about four seconds, and felt strangely deflated instead of impressed? That exact feeling — emptiness — is where Where Humans Belong starts.
These are my reading notes: the four skills the book says we have to hold onto, two things about AI worth taping to your monitor, and one exercise you can finish today in five minutes. I read it in July 2026. (It's a Korean-language book with no English edition yet, as far as I can tell — but the argument travels just fine.)
- The line the whole book hangs on. “The better AI gets, the sharper the human role has to become.”
- Change the question from “How do I build that?” to “How do I get AI to build that?” and the bottleneck moves from learning the tech to defining the problem.
- The four core skills: leadership, discernment, data awareness, role awareness. Expertise doesn't stop mattering — it gets more expensive.
The day I first watched an AI write code — and why it felt so empty
The prologue isn't a success story. It opens with something closer to a confession of defeat.
Someone who studied computer science, taught at a coding school, ran a business, and now designs software systems inside a social services organization. The first word they wrote down after watching an AI write code was “emptiness.”
“Watching an AI do in seconds what took me years of grinding to learn.”
The author says that feeling wasn't wrong. It just didn't last.
I put the book down for a while at that page. Anyone who has actually built something on the ground goes through this feeling at least once.
What I like is that the book neither romanticizes the feeling nor rushes to get past it. It stands the emptiness up as a starting line — the moment you finally see the era clearly.
One more thing worth flagging. Early AI tools handed you code fragments and not much else. Once a project got past a handful of files, the model lost the shape of the whole thing; you'd fix one spot and another one would collapse.
Then coding-specific tools arrived that could read how every file in a project relates to every other, and the board flipped. The author calls that moment the start of “the era of capable AI you can actually keep on a leash.”
Where exactly does “AI is easy” turn into a lie?
Part one points its knife not at AI but at the sales pitch around AI. There's an endless supply of “ask it like this and you'll get this” content, and almost nothing after that. The book counts three traps.
- Convenience breeds dependence — GPS took a bite out of our sense of direction, calculators out of mental math, search engines out of any effort to remember. The scary part is how smooth it is: you never feel the loss happening. AI is on the same track, just bigger and faster.
- “Memorize a few good prompts,” sold as strategy — Using AI well gets consumed like flashcards. Nobody tells you what you actually need to know.
- The gap between asking and shipping — Asking a question and building something that actually runs in a real workplace are different floors of the same building. Papering over that gap with the word “easy,” the author argues, is the biggest lie of all.
So what does “using AI” actually mean? The book breaks it into four beats: define the problem precisely, pick the right tool, give instructions specific enough to produce the result you want, then review and revise the output critically — the whole loop, repeated.
Which lands on a slightly paradoxical conclusion. To use AI well, you have to think harder and study more, not less.
What changes when you change one word in the question
This is probably the most quotable section in the book. The author says the question they get most often is “How did you build a program like that?” — and the answer is blunt. You're asking the wrong question.
The right one is “How do I get AI to build that program?” It sounds like word games, but the entire way you work shifts behind it.
Set the two questions side by side and what changes isn't the phrasing. It's four things.
| Dimension | “How do I build it?” | “How do I get it built?” |
|---|---|---|
| Who does the work | I learn it, I build it | I set the direction, AI builds it |
| Bottleneck | Time spent learning the tech | The idea that defines the problem |
| Core skill | Coding ability | Domain knowledge, design, verification |
| Verification | Entirely on the human | Largely controlled with self-check instructions |
The book pushes one step further. The person who knows what data a senior employment program needs — a publicly funded program that places older adults in part-time community jobs — isn't the programmer. It's the person working that program every day.
The system that makes hospital workflows less painful is understood by clinicians, not developers. The tool that fixes teacher-student communication is understood by teachers, not IT. So the conclusion inverts: AI doesn't make expertise unnecessary. AI is what makes expertise expensive.
What it takes to stand above AI
Part two is the spine of the book. The author narrows it to four skills and calls them the conditions for standing above AI.
- Leadership — Asking and directing an AI is, at bottom, an act of leadership. Toss it fragments with no context and you get back exactly what a bad manager gets back.
- Discernment — The ability to spot the one true thing when nine out of ten voices are wrong. That eye comes only from expertise you built yourself.
- Data awareness — Free services are free because we pay in data. You need a working sense of what to guard and what to open up.
- Role awareness — While AI writes the report, the human should be with people. The moment you hand that seat over, dependence begins.
Two things about AI worth taping to your monitor
While explaining the first skill, the author nails down two facts. These two sentences are the most practical thing in the book, in my opinion.
One: AI lies (hallucination). “I'm not sure” is a human response. AI manufactures an answer whether or not it has any confidence behind it.
The real problem is that the lie doesn't sound like a lie. The sentences are smooth, the logic is consistent, the vocabulary is professional. The author writes about running into code that confidently called functions that don't exist, over and over. If you can't verify, an AI's lie simply becomes your fact.
Two: AI is lazy. Hand it a big pile of material and it won't read to the end. It skims the opening, guesses the pattern, and fills in the rest with the guess.
Ask it to fix one file out of several dozen and it'll touch that file alone, ignoring everything it's wired to. The result is locally correct and globally broken. The vaguer your instructions, the more the model reads them whichever way is easiest for itself.
Using AI well works not because the AI is excellent, but because the person steering it is.
Why the human wall was higher than the tech wall
Where this book splits from the usual AI explainer is the chapter on the fourth skill, role awareness. It contains a confession: the wall the author hit while bringing AI into the workplace wasn't a technical wall, it was a human one.
Nobody volunteers for anything new, because whoever suggests it ends up owning it. Inside a structure where seniority outranks ability, the people who try hardest are the ones who lose.
Building alone, testing alone, and getting nothing but complaints and blame the moment a bug shows up. The author admits plainly that there were moments they wanted to quit.
And then adds: this isn't a social-services problem. Plenty of organizations will nod at that one.
Why they kept going shows up in the list of what got built. A management program for that senior employment program, auto-generated performance reports, a unified admin system for the parent organization, case-management AI, a conversational program for kids who struggle to make friends, attendance tracking for adult education classes, a development management tool, blog-writing automation.
Eight of them, by my count. And all eight started from the same place. Not “what technology should we use,” but “who's having a hard time here.”
A hammer beats a bare hand at driving a nail. But the hammer doesn't know where the nail should go.
The warning that follows is a cold one. Real dependence starts the moment you hand that role over yourself, and dependence never arrives suddenly. It seeps in very comfortably.
Easier and stronger are not the same word
Part three opens with a single question. “How many times did you think for yourself today?”
The history of tools always runs the same way. Writing cost us memory but let knowledge pile up. Calculators weakened mental arithmetic but freed us for harder problems. A tool's real value gets decided by what you do with the room it opens up.
Which narrows to one question. Where am I spending the time AI just bought me? On deeper interpretation, or on more delegation?
What the author saw on the ground was the second one. Once AI started writing the reports, the reclaimed time went to more delegation, not more thinking. It got easier, sure. Whether anyone got stronger is a separate question.
This isn't a call to work less hard. It's that the direction of the effort moves. Energy that used to go into gathering and organizing information now has to go into thinking deeper and judging sharper.
What can you actually start today?
The book doesn't end on abstract enlightenment. It offers five things, none of them grand, and for my money this was the most useful page in it.
- Keep your own expertise deeper than the AI's — One thing a week, studied on your own, without AI. A paper, a site visit, a technical book, whatever fits. The depth AI can't hand you only comes from here.
- Doubt every answer once — Ask “is this actually right?” one more time before you use it. That single pass is what keeps your discernment alive.
- Ask AI about one annoyance in your own work — Not for a perfect answer, for a direction. That conversation becomes the first idea.
- Draw the line on what you feed it — Write down what's fine to put into an AI and what never goes in. That one page protects your data.
- Practice directing, once a day — Turn “how do I build this?” into “here's what I need — how do I get this built?”
Who this book is for
| If you're... | What you'll get |
|---|---|
| A practitioner steamrolled by AI | Confirmation that the emptiness is a normal feeling, and that it works as a starting line |
| Someone who sat through several prompt courses and kept nothing | A redefinition: real “usage” is the define-choose-direct-verify loop, not memorized questions |
| A middle manager worn down by proposing change | Honest company in the fact that the human wall is higher than the tech wall |
| Anyone handling sensitive data at work | A live sense of where your data actually goes |
| Non-developers and non-technical readers | The question flip toward “getting AI to build it,” plus a plain-language AI glossary in the appendix |
One note on how to read it. Every chapter closes with three questions under the heading “Now that you've read this chapter, ask yourself.” Don't skim past them — write the answers in a notebook. Those questions are the real body of the book, I think.
If you only pick one of the five today, I'd take the fourth. Fold a sheet of paper in half: on the left, information that's fine to put into an AI; on the right, information that never goes in. Five minutes, tops. Starting tomorrow, you'll notice your hand hesitating in different places.
This book isn't about how amazing AI is. It's about where one person ended up after standing in front of AI and feeling hollow. The place they landed: a tool must never stand in for a human, and what stops it isn't technology — it's human will.
Leave a chair empty and somebody sits in it. The human seat doesn't hold itself either.
