Reading Yongho Ha, Hyangro, and the Toss team side by side

New models arrive not monthly but weekly, and the experience of using AI shifts underneath us each time. I wanted to know how companies are actually doing AX — not the shallow kind, where AI Chat is adopted as one more SaaS subscription, but the deep kind, where an organization pushes AI transformation through its real work and comes out the other side with hard-won struggles, wins, and failures. I'm grateful that Yongho Ha, Hyangro (CTO of Inflearn), and the Toss team shared exactly those accounts. This is what I took away from reading them.

Laying the three side by side, one thing jumped out. They stand in completely different places, and they hit almost exactly the same walls. How they get over those walls, though, depends on scale. So this piece doesn't stop at summarizing each source — it goes on to what only becomes visible when you overlay them.

0. Where each source is standing

If you want to transplant an insight, you first have to know what soil it grew in. That's why Hyangro spends the first third of his post on organizational context.

Hyangro (CTO, Inflearn) Yongho Ha (CEO, DataOven / CDO, Dable) Toss Team (TW Chapter)
Vantage point Runs a 56-person org Advises many companies Builds the knowledge system in a 4,000-person org
Scale 56 total (26 product, 30 business) N/A (many companies observed) ~4,000 community, 3 Technical Writers
Timing Interim report, 8 months into AI adoption Patterns across many companies' AX stages Six-part record of failure and recovery
Nature of the piece "Here's how we're doing it" "Here's which stage your company is in" "Here's how we failed"
Core asset Realism on infra, security, and pricing plans A diagnostic frame (three debts, the J-curve) Execution data and failure stories

Stitched into one sentence: Yongho Ha diagnoses the disease, Toss documents the course of treatment, and Hyangro shows how the prescription changes in a small organization.

Part 1. Hyangro — "Let me start with our context"

An eight-month interim report from someone running a 56-person org (Inflearn / Rallit; 1.65M cumulative signups, 540K MAU) that began adopting AI seriously in November 2025. The first third of the post is org specs — and that is the argument.

"When I read posts sharing AX insights, what's often missing is the context and environment the insight came out of. Every organization differs in size, budget, and infrastructure. Strip that premise away and even a good insight is hard to carry into your own situation."

Insight 1 — Efficiency and effectiveness are different claims

The first concession he makes, and the coldest coordinate in all three sources.

"I haven't seen a company above ₩10B in annual revenue — not GMV — grow 50%, 100%, or 200% through AX. What's been proven at this scale is 'you can produce your old output with fewer people.' I have not yet seen a case of 'you produce dramatically more.'"

His explanation for why it doesn't convert: AI only gets leverage where explicit knowledge already exists. If "do A → B → C and you get 100" is already codified, AI automates that path fast. But an organization that has never once produced 500 is not going to reach 500 with AI.

Case — the Tesla Model 3. Musk pushed for full automation early, production stalled, and in April 2018 he conceded: "Excessive automation at Tesla was a mistake. Humans are underrated." They re-split the line so robots merely moved seats into place while humans finished the bolts and wiring. The principle he later articulated — "Question the requirements, delete the unnecessary parts, simplify, accelerate cycle time, and then automate" — says the same thing: automate an unvalidated process and you fail.

Insight 2 — A non-deterministic tool is useless to a passive person

"Tell an unmotivated teammate to 'do AX' and they'll use AI exactly as instructed. They'll follow the company's rules and take no responsibility for the outcome — the leader told them to, and they did. And that's when AI becomes the worst possible tool. AI is non-deterministic. Three tries, five tries — there's no guarantee you get what you wanted. So it works for proactive people and does nothing at all for passive ones."

The warning that follows: the tighter the guidelines a company writes, the more people simply execute those guidelines — and when the output isn't right, changing approach and pushing again becomes nearly impossible. → "What's demanded of leaders most in this era is motivating their people."

⚠️ This collides head-on with Toss's conclusion. Part 4 returns to it.

Insight 3 — The premise "anyone with money" is collapsing (the highlight of the piece)

This appears in no other source, and it's the part that landed hardest for me.

The original framing:

"If anyone with money can use the best model, what's the moat between organizations? What you can't forget is that this is not human vs. AI — it's organization vs. organization, both using the same tools. Your competitor has the same tools you do."

But the premise is breaking:

"Top-tier models like Fable 5 are moving off flat-rate plans and onto metered pricing only. Until now, a small company could buy a team or individual flat-rate plan and get effectively unlimited tokens very cheaply, while a large company had no choice but enterprise — spending ₩2–3M per person and still landing below a Max 5x in per-person tokens. That asymmetry was actually an advantage small companies held. But when the top model leaves the flat-rate tier, the story changes. The line gets drawn between companies that can absorb metered cost and companies that can't."

💰 A case that fell out of this: one company, forced onto enterprise, budgeted ₩1.5B a month for AI and spent north of ₩4B — and is now re-examining AI usage across the board.

The question he leaves open: Inflearn runs $125/month premium seats and $200/month Max 20x. Fable-class models are out of reach there. Large companies and heavily funded ones will use them aggressively.

"If we're competing against companies while using a lesser model than they are, what should we be doing?"

He does not answer this in the post. He leaves it open. (My attempt at an answer is in Part 5.)

Insight 4 — The real intellectual asset is the decision process

"If you don't even know what your company's tacit knowledge is, start by recording every internal meeting. Documents preserve only the outcome and the follow-up actions. Your company's real tacit knowledge, its real intellectual asset, is the decision process itself."

  • You need a framework for recording that process — like Google's Architecture Decision Records (by "framework" he doesn't mean a specific technology).
  • Without the reasoning preserved, a slightly different situation produces a completely different decision. "And AI ends up with a completely different context too."
  • An alternative to recording: embed a dedicated person inside the team and have them work as part of it — watching how the work actually happens and continuously extracting explicit knowledge AI can use.

🔧 The three things that most lifted company-wide productivity (measured at Inflearn): the Knowledge Base / a set of MCPs (Atlassian, Google Calendar, Gmail, BigQuery, Mixpanel, Datadog, GitHub) / FDE embedding — a backend engineer moving into the marketing team as an AX engineer.

Insight 5 — Consolidate onto one tool (diminishing returns don't bite here)

"We used to let everyone use whatever suited them best. The sum of individually-optimal tools beat the value of pooling know-how. But AI's possibility space is effectively unbounded, so the law of diminishing marginal utility doesn't really apply."

→ Having dozens or hundreds of people on one tool, concentrating plugins, skills, MCPs, and prompt guides there, produces far better organizational output. Fragment the tools and you fragment the know-how.

And an often-missed point attached to this:

"The LLM is not holding your company's data. When you ask in natural language, it translates that into a query matching your document tool's search spec and calls it on your behalf. So no matter how much data you connect, whether the thing you're looking for actually comes back depends more on your document tool's search quality than on the model."

Insight 6 — Infrastructure: not so AI can read it, but so you can go back

  • Git. "AI is non-deterministic — more iterations don't guarantee better results, and it often blows away work by executing something wrong." Meeting notes and PRDs should be authored somewhere versioned. If Git is too much, at minimum your company-wide document tool must version everything.
  • IaC & GitOps. Product teams change infrastructure by PR while the infra team only reviews, instead of filing Jira tickets. The burden of infra carrying the full context of every request drops enormously. Edit in Pulumi → run tests → AI leaves review comments. "The psychological safety and sense of speed this environment gives you is a large, tangible difference." (Caveat: this validates resource configuration, not actual cloud behavior — that still needs integration tests.)
  • DB migration tooling (Flyway et al.). "Only versioned data lets AI understand intent and context — and lets you rewind and fix things when AI gets it wrong."

Insight 7 — Security: block it outright and it goes underground

"Say 'no' reflexively and people will use AI in the shadows — and that creates a far bigger problem."

  • DevOps + AI + security in one org. "When AI and security sit in separate boxes with separate accountability, each builds process through its own narrow lens, and that compounds the problem."
  • No personal accounts. Don't let people use personal accounts to save token cost. There have been too many MCP-borne incidents — MCPs must be whitelisted internally.
  • An AI proxy gateway is mandatory. "Traditional API monitoring detects anomalies on request count. But an AI API can have identical request counts and astronomically different cost depending on token usage — count-based monitoring will never catch that."
  • A real warehouse like BigQuery. A read-replica RDB requires repeating individual GRANTs per account, which is unmanageable at hundreds of people. A warehouse governs column-level access across many tables with a single policy tag, and supports row-level security. (Caveat: on-demand billing charges by bytes scanned, so log-scale data gets expensive → consider flat-rate, partitioning, clustering.)

🚨 The scariest case — attack through the monitoring SDK. "Wire up a tool like Datadog well and you can automate incident logs → AI analysis → fix → PR. But there are cases where the attack comes in through the SDK that collects client-side errors from browsers and apps. A case disclosed in June 2026 was exactly this — and to be precise, it wasn't a flaw in the SDK itself. The attacker injected crafted data through an exposed error-collection key, and an AI coding agent, reading it through MCP, mistook it for a trustworthy instruction and executed it." (writeup)

"Claiming you'll fully automate bug fixing with no human involved means one of two things is true: your service is too small to be worth attacking, or your security team is perfectly blocking everything." Frontend feels safe to automate because UI changes so often — but: "Repository secrets and CI environments are almost never fully isolated between backend and frontend. Poison the frontend project and the whole service is in scope."

Part 2. Yongho Ha — "Which stage is your company in?"

Written from the vantage point of advising many companies, so the asset here isn't individual cases but patterns. It starts from the observation that companies beginning AX go through remarkably similar stages and pains (denial → anger → bargaining → depression → acceptance).

The five-stage map — find your company

Stage What happens Symptom
1. Euphoria Company-wide rollout, outside trainers, an AX task force "This will transform us"
2. Stagnation Nobody uses it. Engineers use it a bit; non-engineers really don't A broken link between Input (hard to feed our context every time) and Output (have to paste results back into internal systems)
3. Excitement Pioneers (fighting the security team) connect internal systems. MCPs and Skills proliferate. An internal hackathon drives non-engineer usage up sharply Token leaderboards and token maxxing
4. Doubt ← where most companies are now It's underwhelming. Perceived speedup of only 10–20%. Nobody cares about the token leaderboard anymore
5. The last hurdle Clear Pipeline Adaption, or resort to headcount cuts "Let's cut."

His balanced read on token maxxing in Stage 3 is good:

"What we actually want is more output, but that's hard to measure and slow to appear. Token usage — an input — is, for executives, 'the first intuitive, real-time-updating proof of work they've ever had' → managers love it. But by the later stages of AX, you have to move to managing output. Token maxxing gets gamed (people burn tokens with no work behind it), and companies, alarmed at the spend without results, start clamping down on cost."

What actually blows up in Stage 4:

  • AI-generated, under-reviewed code causes a production incident.
  • A decision is made on an AI-generated report nobody scrutinized, and it turns out to be wrong.
  • The alarmed company hard-rolls-back its AI policy. → "When that happens, that company's AX is dead for six months."

This source's biggest asset — the three debts

The frame explaining why you fall into a pit mid-AX (the AI J-Curve Trap): Learning Curve + Verification Tax + Pipeline Adaption.

Debt Definition Why it grows in the AI era
Technical debt The volume of output you've produced slows the next thing you build AI code is locally optimal, globally ignorant. And it's plausible
Cognitive debt You can neither understand nor vouch for what was produced Output arrives in a heap; building context becomes a separate, deliberate act
Intent debt You can never again know why it was built this way Working alone with agents, intent survives only in a prompt that evaporates

Technical debt — what's distinctive is that AI's debt is plausible:

"AI doesn't produce obvious bugs. Unit tests pass. Things break when you wire the whole thing together in production. Code generated faster means debt accumulated faster." → Without a dedicated response, a company's velocity gets worse within 5–19 months. (Simulation-derived, so treat the numbers loosely — the trend is what matters.)

Cognitive debt — "cognitive surrender":

"It used to be that output arrived slowly, built procedurally by your own hands, so building context was something that simply happened to you. You'd look up one day and you knew. Now output arrives all at once, and understanding it has become a deliberate, separate act of work. And companies don't realize they now have to budget time for that act." → At first people try to review the output, but it's too much. Eventually they read only the conclusion and give up on the rest, then hand it to the next person. Who does the same. → Karpathy: you can outsource thinking but not understanding — except people are surrendering understanding too. → "We end up in a pipeline of one-click hand-offs: from your click to my click."

📌 A real case. A report came back from an employee who'd analyzed data with AI: "there's no increase in news traffic." By AI's sense of an average, it wasn't a spike — but in that company's domain, a 20–30% traffic increase is an enormous inflow. Thinking got delegated to AI, and the (sometimes wrong) result circulated internally.

Intent debt — worse than cognitive debt:

"Cognitive debt means the information exists but wasn't understood. Intent debt means it never existed at all." "The person who knew that left the company." / "The reason was in a chat thread somewhere and I can't find it." Previously, a team worked a problem in meetings and context was naturally backed up in other people's heads; slicing work up for collaboration left intent in the trail (messages, comments, notes). The further AX goes, the more one person works alone with agents, and that trail disappears.

📌 Case — the companies that rolled back. Firms that preemptively cut headcount to save cost ended up rehiring those same people at higher salaries (Google, Salesforce, Duolingo, Klarna, CNET). → "So far, a human head is still the best storage device we have for tacit knowledge."

The remedy — move human work from production to verification

Production Verification
The old employee Production + Verification
The future employee (AI does it) Verification

The key is not trying to verify everything: don't verify code and intermediate states — verify the result rigorously. (This also shrinks the surface you have to cognitively hold, which reduces cognitive debt.)

The duck test: "Wherever it came from, however wildly the AI thrashed to produce it, if it passes hundreds of verification layers a human carefully defined, you can trust it. And the tacit knowledge you inject while building those layers is what pays down intent debt."

The three kinds of verification layer:

  1. Binary checks — pass/fail (test cases). Easiest to build, and you'll build the most of these
  2. Quantitative metrics — throughput, latency
  3. Qualitative rubrics — "is this architecture extensible without being over-abstracted?", "are there too many colors in this design?" → LLM as a judge (score 1–5)

Verification is needed at run-time, not just build-time. If the product you ship is an AI agent (an insurance-review agent, an ordering agent), it's non-deterministic — it occasionally goes off the rails. You need a standing verification layer at execution time too.

🧠 The moment perception shifted — the Claude Code source leak. The source code of the tool that changed how the world writes software leaked, and the code quality was lower than expected. People realized: "The reason we needed well-organized, A-grade code all this time was to fit within the size of human cognitive space. If AI can freely handle code that isn't organized to an A grade — if it just delivers the result — isn't that enough?" → "If it passes verification and the result is guaranteed, the process doesn't have to be optimal."

💡 A tip you can use today — always verify in a separate agent instance. "An LLM tends to defend what it just said. Ask the same session that did the work to 'also verify it' and it will catch only a small fraction." A prompt that works well: "Spawn N sub-agents that critique the existing work in parallel from different critical perspectives. If a critique comes back and holds up, re-verify it in the main session and accept it if valid. Repeat this entire process twice."

Extracting tacit knowledge — reverse the roles

The root problem is that tacit knowledge is the stuff "I know, but don't know that I know." You don't know you know it until someone asks. So let AI do the asking.

Matt Pocock's "grill-me" (github.com/mattpocock/skills) "Interrogate every aspect of this plan relentlessly. Walk each branch of the design tree and resolve the dependencies between decisions one at a time, until we reach a shared understanding. For each question, also give me your recommended answer. Ask one question at a time. If a question can be answered by exploring the codebase, check the codebase first instead of asking me."

"grill-with-docs" — grill-me evaporates when the session ends, so this variant runs the same process but emits Markdown documents the next session can reuse.

The specific skill isn't the point — the inversion is:

"Conceptualize yourself as the verifier and advisor, and set AI up as the aggressive questioner. That is: the questioner is not you. It's the AI."

The conditions for an AI-native company — and the real bottlenecks

Conditions: Queryable (even meetings and small decisions recorded, machine-readable) → Closed loop (last attempt's results feed the next) → Self-improving.

So once you have that, is company velocity unbounded? No. Three bottlenecks remain:

  1. Building an SSOT is extremely hard. "Forget AX — most companies haven't even digitized. And once you set an SSOT up, drift creeps in over time."

  2. Burnout arrives fast. "However good your verification layers, there will always be a human-in-the-loop element — and as those queue up, that human becomes the bottleneck. → In the AX era, managing mental energy paradoxically becomes the most important thing."

  3. Taste won't converge. ← the real problem

    "When AI can produce infinitely, what decides what to produce is taste. But taste has no right answer and resists codification. You have to converge and unify it so one product doesn't sprawl across many tastes — and that convergence runs on slow human communication (meetings). → Human taste-convergence, not AI's generation speed, becomes the bottleneck. Downstream work halts waiting for taste to settle, and that sync process drags an AI-native company's velocity back down to an ordinary company's."

So what's left for humans

In an 8-hour day: before AI = 6h doing + 2h judging → after AI = 2h instructing + 6h judging.

"If you're still spending 6 hours producing directly, you're living the old way."

The role model, unexpectedly, is your CEO. They're worse than you at marketing, engineering, and design — and yet they observe your work, direct it, and run the company. AI will soon be better than you at engineering, marketing, and design. And you have to become the person who directs it.

The three capabilities of "someone who owns a job start to finish":

  1. Someone who decomposes problems — breaking one enormous problem into dozens you can hand to an AI or a person
  2. Someone who detects failure fast — "hand it off and walk away, and it dies"
  3. Someone who finds the structure that makes work work — arranging the relationships between agents. "Org leaders have always done this — they call it a reorg"

→ In short: "the ability to find answers in ambiguous situations."

And why expertise still matters:

The Gell-Mann amnesia effect — "You read an article in your own field and see it's riddled with errors, then turn the page and believe the article on a subject you don't know." The medium changed from newspapers to LLMs; the bias is identical. Some of what looked plausible from AI looked that way because we weren't experts. → To filter the plausible fake and be confident in the real thing, you need expertise. The person who can build the most valid verification layer is the domain expert.

The conclusion — expertise, redefined: "From master of a skill to owner of an operation."

Part 3. The Toss team — "Here's how we failed"

A six-part series. 4,000 people; three Technical Writers. The value here is not the conclusion but the trajectory of failure. Each stage exists because the previous one failed.

① One person writes more        → failed: can't keep pace with a changing product
② Build a culture (workshops)   → failed: the first contribution happens, the second doesn't
③ Ship a tool (a Skill)         → failed: nobody used it. You had to invoke it deliberately
④ Embed it in the workflow      → worked. And now too much has piled up
⑤ Set standards and governance  → they are here now (Knowledge Committee)
⑥ Knowledge circulates itself   → the goal (create · verify · refresh · retire)

Most organizations stop somewhere in ①–③ and conclude "our team just lacks the will." The value of this series is that it proves, with failure data, that this was never a will problem — it was a structure problem.

Insight 1 — Code is not the SSoT

"People say code is the SSoT. But code preserves only the result. It records what it does, not why it was written that way. A true SSoT is only complete when the code and the context around it are both present."

Their definition of knowledge is precise too: "verified information that, in a specific context, helps someone make a better decision and act." → If it isn't verified, it isn't knowledge.

Insight 2 — Documentation fails on structure, not on will

"Documentation is work for 'later,' not for 'now,' so it's always deprioritized." "Documentation always begins with individual willpower. The writing itself takes little time — but the decision to write is expensive, so it slips whenever you're busy."

The cost you actually pay when documentation is missing:

  • You spend more time hunting history than developing — "you search chat threads from years ago, and when that fails you walk over to the author and ask"
  • Prolonged unknown unknowns — "the state of not even knowing what you don't know lasts far longer"
  • A psychological hurdle — "'everyone probably knows this' so you don't share it; 'maybe I'm the only one who doesn't know' so you don't ask"

Insight 3 — Lower the burden and behavior changes (measurably)

The problem: "Asking a question means publicly admitting you don't know something — and that itself is a burden."

Intervention Result
A "consult the bot" week (changing the atmosphere) Questions went from 2.5/day to 11/day (4x+); 40 more people joined the channel
A bot broadcasting one small piece of knowledge daily "Being told to write a finished document is daunting. Adding a line to knowledge that's already being shared is far easier."

Side effect: as question volume rose, platform engineers and DevOps started treating the channel as a support surface and answering directly.

Insight 4 — A question the bot couldn't answer = a signal that a doc is missing ⭐

Across all three sources, I think this is the highest-leverage idea per unit of cost.

Someone asks the bot → the bot can't answer → "there's no doc here"
                                            → AI gathers sources and drafts one
                                            → a human just checks the evidence and approves

Why it's powerful: documentation's hardest problem is "I don't know what to write." This loop harvests that answer from users' actual questions. Nobody has to set the priority by hand.

Toss Commerce went one step further: every night, AI drafts documents from two signals — (1) deploy and policy-change announcements, and (2) questions the bot failed to answer. A human only checks the evidence and approves.

Insight 5 — A checklist can be poison to an AI ⭐

Their review-automation failure. It generalizes well beyond writing.

  • Attempt: TW review comments → checklist → AI checks item by item
  • Result: "It missed the problems that mattered and forced out comments that didn't need to exist."
  • Cause: "The conditions for good writing are fixed. Bad writing is broken differently every time."
  • Fix: instead of a checklist, give principles + (incorrect example ↔ correct example) pairs and let the AI judge for itself

Generalized: where the shape of the right answer converges, a checklist works. Where the shape of the wrong answer diverges, a checklist actively degrades performance — there you must supply the reasoning and leave room for judgment.

A related observation: "Hand an AI the guide humans read and it will apply the rules mechanically." Which is why every principle got paired with a bad and a good example.

Insight 6 — The moment a tool requires deliberate invocation, adoption dies ⭐

Toss built a good Skill, shipped it, and nobody used it.

"We announced it internally with grand expectations — 'now everyone will write good docs.' And people just… didn't use it much."

Three reasons:

  1. Installation was hard (CLI setup is alien to non-engineers)
  2. You had to consciously remember, mid-work, "ah, I should write a doc now"
  3. A human still had to go find the source material and hand it to the AI

The principle behind the fix: don't move people to the tool. Plant the tool where people already are.

Task Where they planted it Why
Writing The company messenger Tacit knowledge surfaces in conversation
Editing GitHub PRs The moment a review begins is already defined

"The moment a review begins is already defined" — I love this line. When looking for a place to attach automation, don't invent a new trigger. Find the one that already exists.

The result: "Before, you had to think 'I should clean this doc up' and invoke the AI. Now you don't even have to do that."

Insight 7 — Knowledge becomes debt the moment you accumulate it ⭐⭐

The final twist of the series, and its most important warning. Toss succeeded at documentation. And because they succeeded, they met a new problem.

  • "We made it easy to accumulate documents — and now the problem is that too much has accumulated"
  • "The bot answered, quite calmly, on the basis of a stale policy — and it was wrong"
  • "The bot presented an experiment that had already ended as current policy"
  • "When a policy owner changed, nobody could explain why the existing review criteria had been set that way, and the policy overhaul stalled"

"Tools gather information faster and make drafting easier. But 'can I trust this document,' 'who owns this policy,' and 'is this current policy or the record of a finished experiment' — a tool can't decide any of that for you. Automation didn't remove the problem so much as it made the absence of standards impossible to ignore."

Knowledge has a four-stage lifecycle, and most organizations automate only the first:

Stage Difficulty to automate Most organizations
Create Easy (AI is good at it) ✅ Doing it
Verify Medium (evidence checks, approval flow) ⚠️ Leaning on human approval
Refresh Hard (needs change-signal detection) ❌ Usually absent
Retire Hardest (needs an owner and a standard) ❌ Essentially absent

Toss's answer: governance. A Knowledge Committee. The decisive difference from a guild: "a defined membership holds decision authority, and its decisions carry real force in the organization." (A guild was voluntary, so it could neither decide nor compel.)

A two-layer structure: the TW chapter sets company-wide standards; each domain and chapter operates them in its own area.

"Without company-wide standards, every domain accumulates knowledge its own way. But if the center dictates all operations, it can't keep up with the pace on the ground."

Toss's four knowledge-management standards:

  1. What we know, we leave to the organization — repeated questions / important decisions / what a new joiner must know. These three, unconditionally
  2. What we leave behind must be findable — by human search and AI reference
  3. It must be usable at the moment it's needed — wired into the workflow
  4. Accurate information stays current — assign an owner and a review cadence

"Keeping knowledge in a state where it can be trusted and used matters more than accumulating it."

Insight 8 — Splitting docs for humans and docs for AI

"Documents that AI will read often need detail that humans simply don't need."

Commerce split documentation into two tracks: central docs (human-friendly, TW-managed) and per-team repos (AI-friendly, accumulated automatically during work). The reason: agonizing over "this is context only our team's AI needs — should I really put it in the shared doc?" was itself the hurdle that stopped people writing.

"This structure exists precisely because documents are no longer read only by humans."

Part 4. What you see only when you overlay them

4-1. Three sources, the same wall

The wall Yongho Ha Hyangro Toss
Context disappears Intent debt — "the artifact survives; the intent evaporates" "If the reasoning isn't preserved, AI ends up with a completely different context" "Code preserves only the result" / "nobody could explain why the criteria were set that way"
You can't trust the output Cognitive debt, cognitive surrender "AI is non-deterministic — more tries don't guarantee better results" "The bot answered calmly on the basis of a stale policy — and it was wrong"
Verification is the answer The duck test — hundreds of verification layers Tests, AI review, and integration tests baked into infrastructure "Knowledge is verified information"
The SSOT won't hold "Building an SSOT is extremely hard" (bottleneck #1) "Record your meetings. Write ADRs." todoc — a product built to solve exactly this

So whether it's 56 people or 4,000, an operator or an advisor — the diagnosis converges.

For AI to do well it needs the organization's context. That context currently lives in people's heads and in prompts that evaporate. And the work of extracting it will never, ever be sustained by individual willpower.

4-2. And here they collide head-on — motivation, or structure?

This is the point I sat with longest.

Hyangro:

"Tell an unmotivated teammate to 'do AX' and they'll use AI exactly as instructed. AI is non-deterministic — it works for proactive people and does nothing at all for passive ones. What's demanded of leaders most is motivating their people."

Toss:

"Documentation fails not from a lack of will, but from structure. More fundamentally, the problem is a structure that depends on individual willpower."

One says it comes down to motivation. The other says depending on willpower is the failure mode. Both conclusions came out of real practice, which makes it hard to call either one wrong.

Here's the reconciliation I arrived at.

They operate at different layers.

  • Structure creates the surface area on which motivation can act. Anything that only happens if someone wills it — writing docs, capturing context, adding verification — must be pushed down into structure. Demanding motivation without providing structure is a leader offloading their own job onto individuals. → Toss is right.
  • But a layer remains that structure cannot reach. When AI doesn't give you what you need and you have to change approach and try five, ten more times — that cannot be mandated by process. As long as the tool is non-deterministic, that layer runs on human agency all the way down. → Hyangro is right.

So the question isn't "motivation or structure." It's "what do we push down into structure, and what do we leave to motivation?"

Toss's data proves it. Getting people to write their first doc at a workshop works. Getting them to a second and third contribution does not.

The first one happens through motivation. The tenth only happens through structure.

When a leader says "let's get better at documentation," they are betting the tenth on motivation — and that fails without exception. A leader's job is to make the tenth structural, and to protect the motivation that produces the first.

The proposition gets collected elsewhere too. Yongho Ha's "human-in-the-loop items queue up until that human is the bottleneck" and Toss's "we automated creation and left refresh and retirement to human will" are the same failure.

4-3. Governance is a precondition for Queryable

Yongho Ha's AI-native conditions — Queryable + Closed loop + Self-improving — are compelling, but unattainable without Toss's part 6.

To be Queryable        → knowledge must exist
For knowledge to exist → it must be trustworthy    ("if it isn't verified, it isn't knowledge")
To be trustworthy      → someone must own it

This is the true identity of the "building an SSOT is extremely hard" bottleneck. An SSOT is not a technology problem — it's an accountability problem. Toss built the tool (todoc), and still had to build a structure of accountability (the Knowledge Committee) on top of it.

4-4. DX before AX — but purposeful DX

Yongho Ha: "Every company's data comes in exactly two kinds: it doesn't exist, or it's unusable." The same holds in the AI era — most companies haven't done the DX that AX presupposes. And DX's central flaw was always that it was DX without a purpose.

Hyangro's infrastructure list — Git, IaC/GitOps, Flyway, Workspace SSO, BigQuery — is exactly "DX with AX as its purpose." And what's striking is that he adopted it not "so AI can read our stuff" but "so we can go back when something goes wrong."

"Only versioned data lets AI understand intent and context — and lets you rewind and fix things when AI gets it wrong."

For an organization using a non-deterministic tool, the infrastructure requirement isn't fast. It's reversible. I think that reframing is the most practically useful thing in his piece.

Part 5. Attempting the question Hyangro left open

He ends the post with this, unanswered.

"If we're competing against companies while using a lesser model than they are, what should we be doing?"

Having read all three, I think the question resolves if you rephrase it.

Model tier is a constant we don't control. So what are the variables we do control?

Two. The context that goes into AI, and the verification that filters what comes out. And nearly everything all three sources describe reduces to those two variables.

  • Hyangro's ADRs, meeting recordings, KB, MCPs → context
  • Hyangro's tests, AI review, integration tests → verification
  • Yongho Ha's three debts → the absence of context (intent debt) and verification (cognitive debt)
  • Yongho Ha's duck test → verification
  • Toss's todoc and knowledge system → context
  • Toss's Knowledge Committee → the trustworthiness of context = verification

Why this is the answer.

A model's capability determines how well the AI reasons. But an organization's results are determined by how well the AI produces the right thing on top of our context. If the organization's explicit knowledge isn't in order, a better model simply generates a more sophisticated wrong answer about your company. (Yongho Ha's "there's no increase in news traffic" report is precisely that.) Conversely, with context and verification in place, output from a lesser model gets filtered and corrected into something you can trust.

Layered on top of this is the perception shift the Claude Code leak produced.

"If it passes verification and the result is guaranteed, the process doesn't have to be optimal."

A better model produces a more elegant process. But what guarantees the result is not the elegance of the process — it's the verification layer. And as Yongho Ha nails down, good verification layers come from domain expertise, not from money.

"Building good verification requires domain understanding. You need a deep grasp of the business to define what 'correct' even is. Which means only an expert can build a good verification layer."

So, to put the answer together:

  1. Concede the model gap up front. You can't build strategy on a variable you don't control.
  2. What closes the gap is context. Explicit knowledge, ADRs, meeting records, conventions, the KB — the org that feeds better context to the same model wins. And that's a function of what you've accumulated over years, so it can't be bought back overnight.
  3. What makes the gap irrelevant is verification. With a thick verification layer, you can trust output regardless of its origin. Without one, you can't trust even the best model's output.
  4. And both come from people. It resolves back into hiring, training, and motivating well — the conclusion Hyangro had already reached in his own point 4. Except now you arrive there knowing why.

Anything you can buy with money doesn't differentiate you. Only what money can't buy becomes a moat.

Models you buy. Context, verification, and people you don't.

Part 6. What to take, by scale

Don't transplant these wholesale — exactly as Hyangro warns at the top of his piece.

Small (~50 people)

Take this Source
The "bot couldn't answer = doc is missing" loop Toss. A nearly free signal. Highest priority
Meeting recordings + ADRs Hyangro, Yongho Ha. You can start today with no tooling
Consolidate onto one AI tool Hyangro. The fewer the people, the greater the payoff from concentrating know-how
Verify in a separate agent Yongho Ha. An improvement that fits in one prompt
Principles + examples, not checklists Toss. You only have to edit your existing review bot's prompt
Do NOT take this Why
A Knowledge Committee A 4,000-person solution. At 50 people the committee itself is the overhead. What you need is "one page of standards + a named owner per knowledge area"
A dedicated TW org You don't have the headcount. Use FDE embedding (Hyangro) instead
Building your own doc platform (todoc) Half a year and a whole product team. Don't build — buy a tool with good search and consolidate into it

Mid-to-large (300+)

  • Governance comes before tooling. Toss only discovered "we have no standards" after building the entire tool. At scale, that discovery is far more expensive.
  • Splitting human-facing and AI-facing docs becomes mandatory. (Toss Commerce)
  • Going metered without an AI proxy gateway will produce an incident. The ₩1.5B budget → ₩4B actual case.
  • The token leaderboard is a Stage 3 instrument. If you're in Stage 4 and still watching an input metric, you've missed the moment to move to output management. (Yongho Ha)

Part 7. What none of the three could answer

The questions that remain after reading. I think this is the actual frontier right now.

  1. Where is the crossover from efficiency to effectiveness? Hyangro says "haven't seen it." Yongho Ha names it "Pipeline Adaption" but nobody tells you the order of operations. His diagnosis stings more: "it turns out feature velocity was never the constraint on revenue. Direction, marketing, and sales matter more — and those are still trapped in old workflows nobody dares reform."

  2. Who owns retiring knowledge? Even Toss says they're "still designing it." Create, verify, and refresh can be tooled. Retiring is a judgment — "this is no longer valid" — and judgment is accountability.

  3. Who protects the human left at the end of the verification chain? Yongho Ha's second bottleneck: "however good your verification layers, there will always be a human-in-the-loop element, and that human becomes the choke point." → The paradox that mental and energy management becomes more important in the AX era.

  4. How do you speed up taste convergence? The bottleneck Yongho Ha calls "the real problem." Human taste-convergence is slower than AI's generation, and that sync process drags an AI-native company back to ordinary speed. (Hyangro's 1–4 person squad experiment reads as one response — reduce the number of people whose taste has to converge.)

  5. What happens when top models leave flat-rate plans entirely? The question Hyangro raises and doesn't answer — and the other two sources don't touch at all. Push it to the scenario where even team plans go metered, and the premise that "small orgs can experiment more aggressively" starts to wobble.

Sources