Beyond the Hype: A Technologist and Anthropologist Decode AI’s Promise and Limits
posted: 01-Dec-2025 & updated: 06-Dec-2025
Prologue: The Question Behind the Algorithm
The Chime window opened, and Kabir’s face filled my monitor—the brightest expression I’d ever seen from him.
It was December 2019, a grey Vancouver morning. My wife and daughter were still asleep. I was alone in my home office, staring at the screen, waiting for the words I’d been both hoping for and dreading for the past week.
“The A/B test results are in,” Kabir said from his Seattle office.
Seven days. That’s how long we’d waited. Seven days to account for weekly patterns in customer behavior—Monday through Friday variations, weekend shopping habits. Seven days after three weeks of nightmare when our first algorithm version had lost revenue, when I’d hurt Amazon’s business, when the three teams in Vancouver, Seattle, and San Francisco had worked around the clock analyzing what went wrong.
Seven days to know if version two would work.
“Annual revenue increase through Amazon Mobile Shopping App,” Kabir read from his screen, voice carefully controlled but unable to hide the excitement: “$207,133,371.12.”
I stared at the number.
$207 million.
Two hundred and seven million dollars. Not profit—revenue. But revenue that wouldn’t exist without my algorithm choosing the optimal main menus for each Amazon customer every day. Revenue from increased engagement, more pleasant shopping journeys, and better matches between what customers wanted and what they saw first.
God, it worked brilliantly.
I should have felt triumphant. Three years earlier, I’d left a comfortable position at Samsung to join Amazon specifically for moments like this—applying AI at scale that mattered, touching hundreds of millions of lives, and generating measurable impact.
The mathematics had worked perfectly. Collaborative filtering combined with content-based filtering, customized statistical methods solving the cold-start problem, and algorithms tested and refined until they provably improved customer experience.
But sitting there in my Vancouver home office, watching Kabir’s excited face on the monitor, I felt something unexpected: emptiness.
Not because the work didn’t matter. It did. Customers found products they wanted more easily. Amazon grew its business. My career advanced.
But because I suddenly understood, with uncomfortable clarity, that I’d become extraordinarily good at optimizing for objectives I hadn’t chosen and wasn’t sure I believed in.
On my desk: two monitors, one still showing Kabir’s congratulatory smile, the other displaying data dashboards I’d built. A framed photo of Prof. Stephen Boyd from my Stanford graduation, his understated smile reminding me that convexity guarantees success only after you’ve chosen what to optimize for. A mechanical keyboard worn smooth on the ASDF keys from years of writing optimization algorithms—first at Samsung, then here. A small circuit board from Samsung’s DRAM architecture project. My daughter’s drawing of a piano, reminding me of that ninth-grade revelation. And beneath it all, a coffee-stained printout of Amazon’s Leadership Principles, “Have Backbone; Disagree and Commit” highlighted in yellow.
The $207 million would be reported up the chain. Kabir would present to his VP. My manager Adam would mention it in my promotion case for Principal Applied Scientist. Somewhere, Jeff Bezos would see a metric tick upward.
But I kept thinking about a different number. A different moment. A different kind of value that no A/B test could measure.
I was fourteen the first time I encountered the right question though I didn’t recognize it then.
It was 1990, late autumn in Seoul, the kind of evening when the heating hasn’t quite caught up with the cold. I was alone in our apartment—the sounds of Gangnam’s construction boom filtering up through double-paned windows that never quite sealed properly.
I sat at our upright piano, a modest Samick that my mother had scrimped to buy, practicing a Chopin Nocturne in E-flat major, Op. 9, No. 2. Nothing special. I’d been playing for years by then, with the methodical diligence of a good Korean student who practiced because practice was what you did, not because of any particular passion. My technique was adequate. My musicality was, charitably, developing.
But something happened that evening.
I can’t tell you what measure I was in, or whether I played the passage particularly well. I remember only that a feeling washed over me—sudden, overwhelming, utterly beyond language. Not happiness exactly. Probably closer to bliss, but not that, either. Kind of peace, but not that, either. Something else, something that seemed to bypass words entirely and reach directly into whatever part of me experienced being alive probably somewhat existential part of me.
In that instant, I understood more clearly than I’d understood anything before why music is beautiful.
Not the theory—I’d studied that, could explain harmonic progressions and voice leading and cadential structure. Not the technique—I’d practiced scales until my fingers ached and knew how to execute a proper trill. But something else entirely. Something that lived in the space between the notes, in the resonance between mathematical structure and whatever-it-is that makes us human.
The nocturne’s melody—those descending thirds in the right hand, the left hand’s steady pulse—they were just air pressure variations. Sinusoidal waves propagating through space. One-dimensional acoustic phenomena that any microphone could measure. Yet this single-dimensional time-series data was giving me an experience richer than any visual art I’d seen, more emotionally profound than any literature I’d read, more moving than the mathematical theorems I’d studied. The paradox was impossible to ignore: the simplest possible sensory input—variations along a single dimension—was creating the most complex conscious experience I’d ever known.
I sat there in our Seoul apartment, the Chopin still resonating in my fingers, the streetlights beginning to glow orange through the window, and I didn’t have an answer.
Thirty-five years later, with a PhD in electrical engineering, two decades building optimization and AI systems, hundreds of seminars delivered across the world’s top universities, I still don’t have an answer.
But I know the question matters.
I know it matters more than the $207 million.
Between that ninth-grade piano bench and the hollow morning in Vancouver lie decades of optimization.
At Samsung (2004-2017), I revolutionized how semiconductor engineers designed DRAM cells, moving the entire process from human intuition to mathematical proof. I remember the first time I showed the senior engineers at Samsung’s Hwaseong campus my iOpt platform—their skepticism was palpable. They’d been designing chips longer than I’d been alive. Why would they trust an algorithm over their instincts?
But the math didn’t lie. Hundreds of parameters—transistor widths, oxide thicknesses, doping concentrations—all optimized simultaneously using optimization techniques. What took human designers weeks of trial and error, my system could do in hours, and with provably optimal results. Within two years, hundreds of engineers were using iOpt daily. The satisfaction was real: watching abstraction become silicon, watching mathematical theory produce actual circuits that went into smartphones in millions of pockets worldwide.
At Stanford (1999-2004), Prof. Stephen Boyd taught me that convex optimization isn’t just mathematics—it’s a way of seeing structure in chaos, of recognizing when problems have a hidden elegance that makes solutions not just possible but inevitable. I remember sitting in his office in Packard Building, second floor, with the afternoon light streaming through, as he sketched an optimization landscape on his whiteboard. “See?” he said, in that understated way of his. “The problem wants to be solved. We just have to see its structure clearly.”
My academic lineage traces back through Boyd to Carl Friedrich Gauss himself—through Fourier and Laplace, through Klein and Lipschitz, through mathematical truths that transcend culture, language, era. The same harmonics that Pythagoras discovered in vibrating strings underlie quantum mechanics, general relativity, and the neural networks powering today’s AI revolution.
Mathematical inevitabilities. Truths that would hold in all imaginable universes.
But Amazon’s $207 million taught me what inevitabilities cannot do: they cannot tell you what to optimize for.
The recommendation algorithms worked because they had a clear objective function: maximize revenue per session. Everything else followed mathematically. But “maximize revenue” is itself a choice, not a truth. We could have optimized for user satisfaction, for serendipitous discovery, for expanding rather than narrowing taste, for long-term customer loyalty, for helping people find what they needed rather than what they wanted, for human flourishing by some definition we’d have to actually articulate and defend.
The mathematics doesn’t choose. The mathematics doesn’t care. The mathematics is a powerful servant and a terrible master.
We choose. But mostly, we don’t choose consciously. We inherit objective functions from quarterly earnings reports, from venture capital term sheets, from the ambient ideology that whispers constantly: growth, scale, efficiency, and more.
I sat there that December morning, the rain still falling, the $207 million still glowing on my screen, and I understood something that my fourteen-year-old self had intuited at the piano but that I’d spent two decades trying not to think about:
The algorithm had taught me only how to pursue it efficiently. But the piano—long before I knew what algorithm meant—had taught me to ask what’s worth pursuing.
And the second question is infinitely harder than the first. But perhaps the only ultimately important question to ask!
This is a book about that second question—and whether we’re asking it at all.
It begins where I am now: Co-Founder & CTO of Erudio Bio in California, building AI-powered cancer diagnostics that could actually save lives. Co-Founder & CEO of Erudio Bio Korea, bridging Silicon Valley innovation with Korean medical excellence. Using dynamic force spectroscopy—literally measuring the forces between individual molecules—and machine learning to detect biomarkers that might catch cancer years before traditional methods. Gates Foundation backing. Clinical trials with Seoul National University Bundang Hospital. Real medical impact. Stakes that couldn’t be higher.
But also: watching Sam Altman testify to Congress about needing trillions of dollars and multiple nuclear power plants to scale AI. Watching these systems hallucinate with terrifying confidence—making up citations, inventing facts, and confabulating entire biographies. Watching the inequality gap widen as those with access to computation pull away from those without. Watching energy consumption soar toward environmental crisis while we call it progress. Watching tech billionaires become richer than nation-states while median wages stagnate.
And watching almost everyone—journalists, policymakers, investors, even many AI researchers—fundamentally misunderstand what these systems actually are.
Let me be precise about this, because precision matters:
Large Language Models (LLMs) don’t “know” anything. They don’t (and can’t) believe, reason, understand, or think. They estimate conditional probabilities over token sequences. They are extraordinarily good at pattern completion, and pattern completion can be extraordinarily useful. But completion is not comprehension. Statistical correlation is not causal understanding. Fluency is not consciousness. And most dangerously: confidence is not truth; never truth.
When ChatGPT tells you “Mary Lee Pfeiffer” in response to “Who is Tom Cruise’s mother?” it isn’t accessing knowledge. It’s doing something far more mechanical yet paradoxically more remarkable: estimating conditional probabilities over token sequences.
The proof isn’t just that it might get the reverse query wrong—it’s that the asymmetry itself is impossible if genuine knowledge is present. When I ask the system “Who is Mary Lee Pfeiffer’s son?” and it responds “I don’t have specific information about Mary Lee Pfeiffer or her family,” we’re witnessing not a gap in knowledge but the fundamental nature of pattern completion. Knowledge is bidirectional. Pattern matching is not.
This isn’t a bug. It’s not a limitation we’ll be able to overcome with more parameters or better training. It’s what these systems are. It’s their architecture, their ontology, and their fundamental nature.
Contemporary LLMs are too powerful, too versatile, and too useful for most people to accept that they fundamentally lack the human capacities we so readily attribute to them. Yet understanding what they truly do—and don’t do—is crucial for our technological future.
The careless use of terms like “believes,” “thinks,” or “knows” isn’t harmless shorthand. It actively shapes public understanding, policy decisions, and the trajectory of technological development. When lawmakers hear that AI systems “believe” things, they make fundamentally different regulatory decisions than they would if they understood these systems as sophisticated pattern-matching engines. When companies anthropomorphize their AI systems, they make different choices about trust, verification, and human oversight.
And it matters—crucially—that we understand this clearly. Not to diminish the achievement (these systems are remarkable), but to avoid catastrophic misdeployment. To avoid building a future on misunderstood foundations. To avoid optimizing brilliantly for the wrong things.
I’m writing this book with a co-author who brings everything I cannot: Jun-Young Park earned his PhD in cultural anthropology studying how humans create meaning in community, earned a master’s degree in economy, and bachelor’s degree in semiconductor engineering (yes, really—he understands both the circuits and the culture), works as a writer translating complexity into clarity, and creates YouTube contents that make technical concepts accessible without dumbing them down.
Where I see algorithms, he sees rituals. Where I see optimization landscapes, he sees power structures. Where I see objective functions, he asks: whose objectives, and who chose them?
He asks the questions different than those engineers are trained to ask: What does this technology change about being human? Whose values are encoded in “neutral” systems? When Silicon Valley talks about “disruption,” who bears the cost? What are we optimizing for, really?
Together, we’re attempting something rare: a book that explains how AI actually works—with real technical precision with mathematical rigor, not metaphors or mysticism—while examining what it means for human societies, cultures, relationships, and futures.
Each chapter pairs technical analysis with anthropological inquiry. Semiconductor optimization meets Salzburg Global Seminars on inequality. Convex optimization meets the dimensional paradox of music. Stanford PhD rigor meets Seoul Science High School wonder. Amazon’s machine learning meets the question: Who decided this is what we should optimize for?
Not another AI hype book promising miracles.
Not another AI doom book predicting apocalypse.
But an honest reckoning with both genuine capabilities and essential limitations—and the wisdom to tell them apart.
Part One follows my journey from Boyd’s Convex Optimization theory through Samsung’s fabs, Amazon’s algorithms, Gauss Labs’ industrial AI, to Erudio Bio’s cancer diagnostics—not (only) as success stories but as laboratories for understanding what transfers across domains and what doesn’t. What works, what fails, where AI creates value, and where it destroys it. Where pattern recognition should end and human judgment must begin.
Part Two dismantles the mythology. What LLMs actually do (and cannot do). Why they hallucinate; it’s by design (accidently), not accident. Why most digital transformations fail; it’s humans, not technology. How AI amplifies inequality. Why “AI consciousness” is a category mistake. Why data, not models, is the real competitive advantage. What multi-agent systems might offer.
We refuse the false choice between Silicon Valley’s techno-optimism and the humanities’ techno-skepticism. Both perspectives are necessary. Both are insufficient alone.
I’m writing this from Silicon Valley, where I lead the Silicon Valley Privacy-Preserving AI Forum (K-PAI), where Korean innovation meets American entrepreneurship, where I advise companies and governments on both continents, where I give dozens of seminars annually across Stanford, KAIST, Seoul National University, Samsung, POSTECH, DGIST, Sogang University, Yonsei University, and Korea University.
I’ve seen the venture capital pitches that promise “AI transformation” without understanding what the AI actually does or what transformation actually means. I’ve seen the quarterly pressure that turns thoughtful engineering into rushed deployment. I’ve seen the demo-to-production gap that kills 70% of AI projects. I’ve built systems that created genuine value and systems that created only PowerPoint slides. I’ve watched brilliant engineers confuse pattern matching with reasoning, correlation with causation, and deployment with understanding.
And I’ve watched inequality accelerate in real time. Watched energy consumption soar toward crisis. Watched truth become harder to distinguish from confident hallucination. Watched the gap widen between those who understand these systems and those who fear or worship them. Watched the concentration of computational power create new forms of geopolitical leverage. Watched developing nations forced to choose between Chinese surveillance systems and American profit extraction.
Mostly, I’ve watched us forget to ask: What are we optimizing for?
Not “Can we build this?” but “Should we?”
Not “Does it work?” but “For whom?”
Not “Is it intelligent?” but “Is it wise?”
Not “Does it scale?” but “Does it serve human flourishing?”
This book is my attempt—our attempt—to articulate that difference clearly, and to argue that the difference matters for every decision we’re making about AI right now.
Because we are building systems of tremendous power. And we are doing so while fundamentally misunderstanding what they are, what they can do, what they cannot do, and what we should even want them to do.
We are optimizing at planetary scale without asking what we’re optimizing for.
We are deploying systems that can pass the bar exam and hallucinate case law in the same conversation.
We are trusting pattern completion with decisions that require judgment.
We are confusing statistical correlation with causal understanding.
We are mistaking fluency for knowledge, confidence for truth, capability for wisdom.
My ninth-grade self, sitting at that Samick piano in Seoul, overwhelmed by beauty that mathematics could describe but never fully explain, knew something my Amazon algorithms never will:
The question is everything.
The question behind the algorithm. The objective behind the optimization. The values behind the metrics. The purpose behind the power.
Let’s get the question right.
[Transition to co-author’s voice]
When Sunghee first told me about the Tom Cruise’s mother problem—how ChatGPT confidently invents a biography for someone who doesn’t exist—I recognized it immediately. This is every anthropologist’s nightmare and vindication simultaneously.
Nightmare because millions now trust these systems with truth.
Vindication because it reveals what anthropology has always known: knowledge is not data retrieval.
I study how humans create meaning in community, across time, through ritual and relationship and the ineffable space between words. When machines simulate these processes without participating in them, something essential is lost—and something dangerous is created.
A cultural anthropologist and an optimization theorist writing about AI together might seem strange. But the strangeness is the point. What we’re building in Silicon Valley requires both lenses: the technical and the human, the mathematical and the cultural, the analytical and the experiential.
This book is our attempt to hold both simultaneously. To refuse the false choice. To insist that the most important questions about AI are simultaneously technical and human.
How we answer those questions will determine whether AI amplifies human flourishing or undermines it. Whether it narrows inequality or widens it. Whether it preserves what makes us human or erodes it.
The technology is here. The question is what we do with it.
Let’s begin.
Sunghee Yun & Jun-Young Park
Silicon Valley & Seoul, December 2025
PART I: THE REAL AI JOURNEY — From Mathematics to Medicine
Subtitled: How Algorithms Actually Get Applied (And What Works)
Chapter 1: The Foundation — Stanford, Boyd, and the Mathematics of Optimization
The late afternoon sun streamed through the tall windows of Packard Building’s second floor, illuminating dust motes that hung in the air like tiny mathematical points suspended in space. It was winter 1999, my first academic year at Stanford, when the apprenticeship I’d hoped for became real: Prof. Boyd had accepted me as his PhD student. I sat across from him in his corner office, watching him sketch an optimization landscape on his whiteboard with practiced strokes.
“See?”
he said, in that understated way of his that made profound insights sound almost casual.
“The problem wants to be solved. We just have to see its structure clearly.”
He drew a bowl-shaped curve—a simple parabola in two dimensions that represented something far more complex: a convex optimization problem in high-dimensional space. Then, for contrast, he sketched a landscape with multiple valleys and peaks, a treacherous terrain where algorithms could get trapped in local minima, forever missing the global optimum hidden somewhere in the distance.
“General optimization,” he said, tapping the multi-valley landscape, “is like searching for the deepest point in a mountain range while blindfolded. You might find a valley, but how do you know it’s the deepest valley? You don’t. You can’t. Not without checking every other valley, which might take forever.”
He turned back to the bowl. “But convex optimization?” A slight smile. “Every valley you find is the deepest valley. Every local minimum is the global minimum. It’s not just easier—it’s categorically different.”
I had come to Stanford to study electrical engineering, drawn by its legendary faculty and the convergence of theory and practice that Silicon Valley represented. But I hadn’t expected to encounter something that felt less like a technique and more like a revelation about the architecture of solvable problems.
The mathematics was elegant in a way I’d rarely experienced. When a problem is convex, every path downward leads to success. Not to “a” solution, but to “the” solution—provably, globally, optimally.
It was 1999. The dot-com bubble was about to burst leaving many parts of Silicon Valley littered with the detritus of failed startups and abandoned business plans. But in Boyd’s office, surrounded by stacks of papers and the quiet hum of mathematical certainty, I was learning something that would outlast every boom and bust cycle: some problems have an intrinsic structure that makes them not just solvable, but guaranteeably solvable.
The Miracle of Convexity
To understand why this matters—not just for academic mathematics but for everything from the circuits in your smartphone to the algorithms that recommend your next purchase—you need to grasp what convexity actually means.
A function is convex if, when you draw a line between any two points on its graph, the function lies below that line. Geometrically, this means no “bumps” that could trap you. Analytically, it means that the local structure of the problem tells you everything about its global structure.
Picture it this way: imagine you’re hiking in thick fog, unable to see more than a few feet ahead, trying to find the lowest point in the terrain. In a general (non-convex) landscape, following the slope downward might lead you into a shallow valley while the true lowest point lies somewhere else, hidden by ridges you can’t see. You’d need to exhaustively explore every depression, every valley, every dip—a potentially infinite task.
But in a convex landscape—a perfect bowl shape, mathematically speaking—any path downward eventually leads to the same place: the global minimum. The local gradient points toward global truth. Following the slope is sufficient. You need no cleverness, no intuition, no luck. The structure of the problem itself guides you to the answer.
This isn’t just convenient. It’s transformative.
Consider the general optimization problem:
\[\begin{array}{ll} \text{minimize} & f_0(x) \\ \text{subject to} & f_i(x) \leq 0, \quad i = 1, \ldots, m \\ & h_j(x) = 0, \quad j = 1, \ldots, p \end{array}\]In the general case, this problem can be extraordinarily difficult. Local search algorithms might get trapped. Determining global optimality can be computationally intractable—sometimes impossible in practice, even for moderately sized problems.
But when $f$ and $g_i$ are convex functions, and $h_j$ are affine (linear) functions, everything changes.
\[\begin{array}{ll} \text{minimize} & f_0(x) \\ \text{subject to} & f_i(x) \leq 0, \quad i = 1, \ldots, m \\ & Ax = b \end{array}\]The feasible region—the set of points satisfying all constraints—becomes convex. The objective function has no spurious local minima. And most remarkably: any local minimum is automatically a global minimum.
This guarantee transforms the impossible into the systematic. It turns art into science.
Not an Accident—A Search for Mathematical Beauty
I’d loved mathematics obsessively since childhood—winning medals at the Korean Mathematics Olympiad, insisting on proving every theorem in my engineering textbooks in college while classmates just wanted to use the formulas. When I arrived at Stanford in 1998 planning to research digital communication (the hot field then, like AI is now), I thought I knew my path.
Then I took Boyd’s EE364: Convex Optimization in Winter 1999.
The course was legendarily difficult, but I wasn’t frustrated—I was home. Late one night, working through a problem set that used duality theory to reveal hidden structure in a circuit design, something clicked. Not just understanding the problem—understanding what I wanted to do with my life.
I emailed Boyd. The next day, he accepted me into his research group.
Everything that followed—Samsung, Amazon, Gauss Labs, Erudio Bio—traces back to that moment when a search for mathematical beauty found its home.
The First-Order Optimality Condition
One of the most beautiful results in convex optimization is also one of the simplest. For a differentiable convex function, a point $x^\ast$ is optimal if and only if
\[\nabla f_0(x^*) = 0\]That’s it. Find where the gradient vanishes, and you’ve found the global minimum. No need to check second derivatives. No need to explore the rest of the space. The local condition is sufficient for global optimality.
This is remarkable when you think about it. In general optimization, a zero gradient tells you only that you’ve found a critical point—which could be a local minimum, a local maximum, or a saddle point. You’d need to check second derivatives (the Hessian matrix) and even then you’d only know about local behavior.
But for convex functions, the first-order condition is complete. The local gradient tells you everything about the global structure.
I remember the first time I truly grasped this. Boyd had assigned a problem about portfolio optimization—choosing how to allocate money across different assets to maximize expected return while minimizing risk. The problem had a convex formulation (a quadratic objective with linear constraints), which meant we could solve it efficiently even with thousands of assets.
But what struck me wasn’t the efficiency—it was the certainty. Once we found the solution, we knew it was globally optimal. Not just “probably good” or “best we could find”—actually, provably, globally optimal.
In a world of uncertainty, heuristics, and approximations, this kind of guarantee felt almost magical.
Duality: The Hidden Perspective
If convexity is the heart of optimization theory, duality is its soul.
Every optimization problem has a dual problem—a hidden perspective that often provides deeper insights than the original formulation. For the primal problem:
\[\begin{array}{ll} \text{minimize} & f_0(x) \\ \text{subject to} & f_i(x) \leq 0, \quad i = 1, \ldots, m \\ & h_j(x) = 0, \quad j = 1, \ldots, p \end{array}\]we construct the Lagrangian:
\[L(x, \lambda, \nu) = f_0(x) + \sum_{i=1}^m \lambda_i f_i(x) + \sum_{j=1}^p \nu_j h_j(x)\]The dual function is then:
\[g(\lambda, \nu) = \inf_{x} L(x, \lambda, \nu)\]And the dual problem seeks the best lower bound (by maximizing its objective function):
\[\begin{array}{ll} \text{maximize} & g(\lambda, \nu) \\ \text{subject to} & \lambda \geq 0 \end{array}\]Weak duality tells us the dual optimal value always provides a lower bound on the primal optimal value. This always holds (even for non-convex problems).
But for convex problems satisfying mild regularity conditions (like Slater’s condition), we have strong duality: the dual optimal value equals the primal optimal value.
This is profound. It means every convex optimization problem can be viewed from two perspectives—the primal (minimizing the objective) and the dual (maximizing the best lower bound)—and these perspectives give the same answer.
The dual variables have beautiful interpretations. In economics, they’re shadow prices—the marginal value of relaxing a constraint by one unit. In game theory, they’re optimal strategies. In machine learning, they reveal which data points are most important (support vectors, for example).
Boyd devoted three full lectures to duality theory. “This isn’t just a mathematical curiosity,” he emphasized. “Duality gives you another way to see the problem. Sometimes the dual is easier to solve. Sometimes the dual has a clearer interpretation. Sometimes the dual reveals structure the primal obscures.”
He was right. Years later at Samsung, I would rely on dual formulations to solve circuit optimization problems. But the real surprise came from an unexpected application: I could use dual optimal values to perform local sensitivity analysis of the primal problem. This theoretical insight became practically essential when designing next-generation DRAM cell schemes—it gave me exact derivatives of objective and constraint functions that would have been impossible to compute otherwise.
The irony was beautiful: I was solving optimization problems to calculate derivatives—inverting the usual logic where generally derivatives (are used to) solve optimization problems. Duality theory had revealed a hidden bridge between two seemingly separate mathematical tasks.
These moments—when abstract theory suddenly unlocked concrete engineering problems, when mathematical elegance coincided perfectly with practical necessity—were among the most astounding and gratifying of my career. They felt less like clever applications and more like glimpses of some deeper structure in the universe, where pure mathematics and physical reality were different expressions of the same underlying truth.
At Amazon, dual perspectives would illuminate what the primal obscured. When collaborative filtering algorithms failed mysteriously, the dual formulation exposed the actual bottleneck: not the algorithm design but the constraint structure. Dual variables quantified exactly how data sparsity limited performance—turning vague concerns about insufficient training data into precise measurements of marginal value. The same shadow prices that had optimized transistor widths at Samsung now optimized recommendation quality for millions of users.
At Erudio Bio, duality theory shapes our entire approach to biomarker discovery. Finding cancer signatures in biological data means optimizing detection accuracy under strict constraints: limited samples, measurement noise, biological variability. The primal asks what biomarker combinations achieve our accuracy targets. The dual asks what accuracy is actually achievable given our constraints—and which constraints limit us most. This perspective transforms experimental design: instead of trying random biomarker combinations hoping for accuracy improvements, we compute exactly which additional measurements would most relax our binding constraints. Pure mathematics, guiding the search for tools that might save lives.”
The KKT Conditions: Where Geometry Meets Analysis
The Karush-Kuhn-Tucker (KKT) conditions represent one of the most elegant bridges between geometry and analysis in all of mathematics.
For a point to be optimal in a convex optimization problem, it must satisfy:
Stationarity:
\[\nabla f_0(x^\ast) + \sum_{i=1}^m \lambda_i^\ast \nabla f_i(x^\ast) + \sum_{j=1}^p \nu_j^\ast \nabla h_j(x^\ast) = 0\]Primal feasibility:
\[f_i(x^\ast) \leq 0, \quad h_j(x^\ast) = 0\]Dual feasibility:
\[\lambda_i^* \geq 0\]Complementary slackness:
\[\lambda_i^\ast f_i(x^\ast) = 0\]These conditions capture the geometric intuition that at the optimum, the gradient of the objective function must be a linear combination of the gradients of the active constraints.
For convex problems, the KKT conditions are both necessary and sufficient for optimality. Find a point satisfying these conditions, and you’ve found the global optimum. This transforms constrained optimization from an art into a systematic science.
I remember working through a particularly tricky problem set where we had to use the KKT conditions to solve a portfolio optimization problem analytically. The problem involved maximizing expected return while constraining risk and requiring certain positions to be non-negative. After hours of algebra, the KKT conditions revealed something beautiful: at the optimum, assets split into three categories. Some had positive holdings (with zero dual variable—their non-negativity constraint wasn’t binding). Some had zero holdings (with positive dual variable—they would enter the portfolio only if their expected return increased). And some had holdings exactly at their constraint boundaries.
The complementary slackness condition encoded this perfectly: for each constraint, either the constraint is satisfied with slack ($f_i(x^\ast) < 0$) and its dual variable is zero ($\lambda_i^\ast = 0$), or the constraint is active ($f_i(x^\ast) = 0$) and its dual variable is positive ($\lambda_i^\ast > 0$).
This single condition—$\lambda_i^\ast f_i(x^\ast) = 0$—captured the entire economics of constrained resource allocation.
Pure. Elegant. Universal.
Interior-Point Methods: Revolution in Algorithms
The theoretical beauty of convex optimization would matter less if we couldn’t actually solve these problems efficiently. This is where interior-point methods enter the story—a algorithmic revolution that occurred in the 1980s.
Traditional methods like the simplex algorithm for linear programming worked by walking along the edges of the feasible region. Interior-point methods took a radically different approach: they stay inside the feasible region and approach the boundary only in the limit.
The key insight is to replace hard inequality constraints $f_i(x) \leq 0$ with barrier functions that approach infinity as you approach the boundary:
\[\text{minimize} \quad f(x) + \frac{1}{t} \sum_{i=1}^m -\log\left(-f_i(x)\right)\]As the parameter $t$ increases, solutions to these barrier problems trace out the “central path” that approaches the optimal solution of the original problem.
Using Newton’s method to solve the barrier problems, and carefully increasing $t$, interior-point methods solve convex optimization problems in polynomial time—a theoretical breakthrough that also had enormous practical impact.
Boyd’s textbook, Convex Optimization (co-authored with Lieven Vandenberghe), came out in 2004, just as I was finishing my PhD. It became the Bible of the field—the text researchers quoted chapter and verse, the book PhD students annotated like theological scholars. Mathematically rigorous yet surprisingly readable, with applications spanning engineering, finance, statistics, and machine learning, it shaped how an entire generation understood not just optimization techniques but the very structure of solvable problems.
That book is now cited over 84,000 times. It shaped how an entire generation of researchers and practitioners think about optimization. And it emerged from the same tradition Boyd was teaching me: mathematical precision in service of practical problem-solving.
Why This Powers Modern AI
Fast forward twenty six years from those afternoon sessions in Boyd’s office. Today, virtually every machine learning system relies on the foundations we were studying in EE364.
Training a neural network? You’re solving a (usually non-convex, but locally convex) optimization problem.
Fitting a support vector machine to data? Convex optimization. Period.
Training a logistic regression, which is a simplest form of neural network? Convex optimization. Period.
Solving a linear regression? Convex optimization with a closed-form solution. This happens every time you draw fitting lines in your Excel sheets.
Designing recommendation systems, detecting spam, recognizing images, translating languages—all of these involve solving optimization problems, many of which have convex structure or convex relaxations.
The $207 million in revenue my Amazon recommendation systems generated? That came from iteratively solving hundreds of extremely large convex optimization problems per second, each of them guaranteeing we could find good solutions efficiently.
Google’s PageRank algorithm that revolutionized web search? Based on the principal eigenvector of a matrix—a problem with convex formulation.
The training of GPT-4 and every other large language model? Massive-scale optimization problems, broken into smaller pieces with convex structure.
Convex optimization is the backbone of modern AI. It’s the hidden infrastructure that makes machine learning actually work at scale.
But—and this matters enormously—the fact that we can efficiently find optimal parameters for a machine learning model tells us nothing about whether the model should exist, what it should optimize for, whose data it should train on, or what values it embodies.
We can train a model to maximize engagement (which often means maximizing outrage and addiction). We can train a model to maximize revenue (which often means exploiting psychological vulnerabilities). We can train a model to maximize accuracy on a benchmark (which often means encoding historical biases into automated systems).
The mathematics works beautifully for all of these. Convex optimization doesn’t judge your objective function—it just guarantees you’ll reach it efficiently.
And here’s where modern AI gets even more complex: deep learning—the technology behind GPT-4, image recognition, and most headline-grabbing AI—actually involves non-convex optimization. The loss landscapes have multiple local minima. We have no guarantee that gradient descent finds the global optimum.
Yet even these non-convex problems rely fundamentally on convex optimization principles. We break massive problems into smaller convex subproblems. We use local convex approximations to guide optimization. We apply techniques—like momentum methods and adaptive learning rates—that emerged from studying convex optimization. The training of every neural network layer involves solving convex optimization problems iteratively.
So when people ask “How does AI actually work?” a significant part of the answer is: “Convex optimization—applied millions of times, at massive scale, using principles discovered in Boyd’s office and classrooms like EE364.”
The infrastructure is mathematical. The applications are human. And the gap between those two is where everything interesting—and dangerous—happens.
Mathematical Lineage and Universal Truths
One afternoon in his office, Boyd showed me his academic genealogy chart—the mathematical family tree tracing advisor-student relationships backward through history.
“You see this?” He pointed to his name, then traced upward through his advisor, and their advisor, and back through generations of mathematicians. The line went through Carl Friedrich Gauss himself, then further back through Fourier and Laplace, through Klein and Lipschitz, all the way to the very foundations of mathematical analysis.
My Erdős number—the degrees of separation from the legendary mathematician Paul Erdős through coauthorship—was three. But this was different. This was intellectual lineage, ideas passing through minds across centuries, each generation adding insights while preserving the core truths.
“These aren’t just names,” Boyd said. “These are people who discovered things that are true in all possible universes. The Pythagorean theorem. Fourier analysis. The structure of convex sets. These truths existed before humans evolved and will exist after we’re gone. We’re just the temporary custodians of these insights.”
He paused, looking at the chart. “That’s what mathematics is—the search for universal truths. The things that would have to be true regardless of physics, biology, culture. The inevitable structures.”
I thought about this often over the years. The same mathematical inevitabilities that Pythagoras discovered in vibrating strings 2,500 years ago underlie quantum mechanics, general relativity, and the neural networks powering today’s AI revolution. The harmonic series that creates music’s beauty is the same series that appears in signal processing, wireless communications, and machine learning.
Mathematical truths are universal. They transcend culture, language, era. A theorem proven in ancient Greece remains valid in modern Silicon Valley. An algorithm that works follows mathematical principles that would work on any planet with rational beings capable of computation.
But here’s what Boyd never explicitly said, though I eventually understood: mathematics can tell you how to optimize, but it cannot tell you what to optimize for.
The objective function—that thing we’re trying to minimize or maximize—comes from outside mathematics. From human choice. From values, goals, purposes we must articulate and defend.
Convex optimization gives you guaranteed success reaching your objective. But it offers no guidance on whether that objective is worth reaching.
Boyd’s words about universal truths and temporary custodians stayed with me. Because my own path to becoming one of those custodians was anything but inevitable.
Finding My Place in the Lineage
That genealogy chart Boyd showed me—the line from him to Gauss—it represented more than intellectual history. It represented something I’d been searching for since childhood without knowing quite what I was searching for.
I’d been obsessed with mathematics from an early age. Not the casual “I’m good at math” that many students experience, but something closer to addiction. In high school, I won medals at the Korean Mathematics Olympiad and the Asian-Pacific Mathematics Olympiad, spending weekends working through proofs while my classmates played basketball or pursued more typical teenage activities.
The beauty of mathematics consumed me—the way a proof would suddenly click into place, the elegance of a well-constructed argument, the inevitability of logical deduction. Other subjects felt arbitrary, contingent, and debatable. Mathematics felt true in a way nothing else did.
When it came time to choose a college major, I knew exactly what I wanted: pure mathematics. I wanted to spend my life in that world of rigorous proofs and elegant abstractions, following arguments wherever they led.
My father and my high school teacher had other ideas.
“You can do mathematics in electrical engineering, too,” they argued almost unanimously. “But EE gives you something more,” my teacher continued. “Most critical twentieth-century technology as we know it started from the invention and commercialization of semiconductors. The transistor, integrated circuits, and almost everything modern derives from that. You’ll have both the mathematics you love and the practical impact you need.” My father nodded. “Mathematics is beautiful, but what will you do with it? Teach? EE opens more doors.”
They were persuasive. And perhaps I wasn’t as certain as I thought. I enrolled in Electrical Engineering at Seoul National University.
But my obsession with mathematical rigor didn’t fade—it just frustrated my engineering professors. In Engineering Mathematics—a course designed to teach engineers how to use mathematical tools, not exactly to make them understand their theoretical foundations—I insisted on proving every theorem in the textbook. Every. Single. One.
Other students would ask: “How do I apply Fourier transforms to this circuit problem?” I would ask: “But why must the Fourier transform have these properties? Can we prove convergence rigorously?” The professor would sigh. “Yun, this is an engineering course. We don’t have time for all the proofs. Just learn to use the tools.”
I couldn’t. I needed to know why things were true, not just that they worked. Looking back, I realize I was trying to smuggle pure mathematics into engineering through the back door.
But there was something else, too—something that would eventually lead me to optimization rather than pure mathematics.
I loved coding.
Not the way most software developers loved it—not primarily for building applications or solving practical problems—but for its structural beauty. The way elegant code revealed mathematical patterns. The way a well-designed algorithm expressed abstract logic in concrete form. The way you could see the architecture of a solution in the organization of the code itself.
I loved coding for the same reason I loved mathematics: both revealed beautiful structures hiding beneath surface complexity. A good algorithm was like a good proof—economical, clear, and inevitable.
This should have told me something about what I was really looking for. Not pure mathematics divorced from application, but mathematics embodied in systems, in algorithms, in things that computed and solved and worked.
When I applied to Stanford in 1998, I stated in my Statement of Purpose that I wanted to research digital communication. This was the hot field at the time—almost exactly the way AI is now. Everyone wanted to work on it. The market demanded it. The future seemed to lie in wireless systems, information theory, and coding theory.
It seemed like the obvious choice. Digital communication was among the most mathematical topics in electrical engineering—far more so than, say, semiconductor device physics or power systems. It involved beautiful theory: information theory, probability, signal processing, and coding theory.
I arrived at Stanford in Summer 1998 ready to immerse myself in this world.
But something felt wrong.
The mathematics was there, yes—but it wasn’t deep enough for me. It felt applied, instrumental, a means to an end rather than an end in itself. The problems were interesting, but they didn’t scratch the itch I’d had since those Korean Mathematics Olympiad days.
Then, in that autumn quarter, I took EE263: Introduction to Linear Dynamical Systems. Boyd’s course. Everything changed.
The way he presented material—terse, precise, practical, yet demanding that you see not just techniques but the structure beneath them. The way every lecture built toward deeper understanding of how systems behave, why certain problems have elegant solutions, what mathematical principles govern dynamic behavior.
This wasn’t just applied mathematics. This was mathematics itself—rigorous, beautiful—that happened to be applicable.
I fell in love immediately.
When I enrolled in EE364: Convex Optimization in the next quarter, Winter 1999, that love deepened into certainty.
The course was legendarily difficult. Problem sets required not just calculation but genuine insight. I spent entire weekends in Cecil H. Green Library, surrounded by other sleep-deprived graduate students, wrestling with duality theory and KKT conditions.
But I wasn’t frustrated. Within a few weeks, (and probably deep inside, immediately) I realized: I was home.
I still remember the night it crystallized completely. It was early in the quarter, probably 2 AM, not long after I’d passed the PhD qualifying exam. I was in my dormitory, working through a problem set alone. The problem involved formulating a circuit design question as a convex optimization problem, then using duality theory to reveal hidden structure in the solution.
As I worked through the dual formulation, computing the Lagrangian, deriving the dual function, something extraordinary happened.
The dual problem revealed information that was completely hidden in the primal formulation. It showed exactly which constraints were limiting the solution, quantified how much the objective would improve if we relaxed each constraint, exposed the fundamental trade-offs in the circuit design.
It was like seeing in a new dimension. The same problem, but viewed from a completely different (but obviously connected) angle that revealed structure I couldn’t see before.
And in that moment—2 AM, alone in my room, staring at pages of mathematical derivations—I suddenly understood what I wanted to do with my life.
This. This perfect synthesis of rigorous mathematics and practical application. This field where proving theorems mattered and solving real problems mattered. This framework elegant enough to satisfy my obsession with mathematical beauty, yet powerful enough to design circuits, optimize systems, solve engineering problems that actually mattered.
Pure enough for the mathematician in me. Applied enough for the engineer also inside me!
The feeling was overwhelming. Certainty. Conviction. Destiny, if you believe in such things.
I didn’t wait until morning. I couldn’t. I did what I had to do. I opened my email and wrote to Prof. Boyd right then, at 2 AM:
“Dear Prof. Boyd,
I would like to work with you on convex optimization. I don’t know yet exactly what research problems or topics I want to pursue, but I know this is the field where I belong. Would you consider taking me as your PhD student?”
I hit send and went to sleep.
The next day, Boyd replied: “Come by my office this afternoon.”
I sat across from him in that same office where, months later, he would sketch optimization landscapes on his whiteboard. Where he would show me the mathematical genealogy chart. Where I would spend countless hours over the next five years learning to see the world through optimization’s lens.
“What do you want to work on?” he asked.
“I don’t know yet,” I admitted. “But I want to learn how to see the way you see—to recognize structure, to know when problems can be solved, to understand the architecture of solvable problems.”
That understated smile. “That’s a good reason.”
He accepted me into his research group. Just like that.
Two quarters. That’s all it took from arriving at Stanford to finding my life’s work. Not because I’d planned it strategically, but because I’d finally encountered the thing my obsessive mathematical mind had been searching for all along.
My father and teacher had been right, in the end. Electrical engineering did give me mathematics and practical impact. Just not in digital communication, not in the field I’d expected. But in a field I had never imagined existed.
I remembered when I told Prof. In-Joong Ha in SNU that I wanted to understand (or rather know) what the positive-definiteness of matrices mean. Prof. Ha told me that that’s exactly one of many things that you would learn in graduate school. I hoped so badly that I would have that understanding once I arrive at Stanford. He was right, but also wrong in an interesting way. He was right in that I finally had that understanding in Prof. Boyd’s Convex Optimization class. He was (kind of) wrong in that that happened in a totally unexpected way.
In Boyd’s office, working on convex optimization, I found my place in that lineage stretching back to Gauss (who not only called Number Theory as the Queen of Mathematics, but also devised a very practical mathematical method called Least-Square Methods, which is literally still being used in every modern mathematical tools including Excel sheets every day today). Not as a pure mathematician proving theorems divorced from application. Not as a pure engineer building systems divorced from deep theory. But as something in between—someone who could see mathematical structure and build things that mattered. Someone who needed both the beauty of proofs and the satisfaction of systems that worked.
The fourteen-year-old who fell in love with Chopin’s Nocturne had learned that beauty can justify existence by itself. The Stanford graduate student working through duality theory at 2 AM learned that beauty can also serve—that elegance and utility need not be separate.
That mathematical lineage Boyd showed me wasn’t just about intellectual pedigree. It was about finding where you belong—where your particular obsessions and capabilities align with problems that matter.
Everything that followed—Samsung, Amazon, Gauss Labs, Erudio Bio—would flow from that 2 AM moment of recognition.
Not accident. Not serendipity.
Just a long-held love finally meeting its proper object.
What Stanford Taught Me Beyond Mathematics
Looking back, my years with Boyd taught me three things that shaped everything that followed:
First: Structure matters more than cleverness.
The most powerful solutions come not from ingenious tricks but from recognizing the inherent structure of problems. When you see that a problem is convex—or can be transformed into something convex—you unlock guaranteed global solutions. No amount of cleverness helps if you’re solving the wrong class of problem.
This lesson would prove crucial at Samsung, where I’d transform circuit design from an art (experienced engineers tweaking parameters based on intuition) into a science, or further into technology (algorithms exploiting convex structure to prove optimality).
Second: Local information can reveal global truth—but only in special cases.
For convex problems, following the local gradient leads to global optima. This is remarkable but also rare. Most problems aren’t convex. Most landscapes have multiple valleys. And for those problems, local information is insufficient.
This lesson would haunt me at Amazon, where we’d build systems that optimized locally (maximizing click-through rates, optimizing engagement metrics) without asking whether local optima were globally desirable.
Third: Mathematics tells you how but not what.
Convex optimization gives you guaranteed success reaching any objective you specify. But it offers no guidance on whether that objective is worth reaching. The objective function comes from outside mathematics—from values, goals, purposes you must articulate and defend.
This lesson I’m still learning. It’s the gap between the fourteen-year-old at the piano (overwhelmed by beauty, asking why this matters) and the engineer watching $207 million flow from optimized algorithms (understanding how it works but questioning what it’s for).
Leaving Stanford, Carrying Questions
In 2004, I defended my PhD dissertation: “Convex Optimization for Digital Integrated Circuit Applications.” The work was solid—I’d developed new algorithms for digital circuit sizing using new class of convex optimization called generalized geometric program to handle more complex circuit constraints.
The defense went smoothly. My committee asked good questions. Boyd nodded at my answers with that understated approval I’d learned to recognize. I was done.
That evening, I walked through Stanford’s campus—past the Rodin sculptures, past Memorial Church with its golden mosaics, past the palm trees swaying in the California breeze. In my bag was a copy of my dissertation, 162 pages of theorems, algorithms, proofs, and most of all, applications.
I had learned to see mathematical structure. I could recognize convexity, construct duality, exploit optimization landscapes. I could prove theorems and write code and solve problems that would have been intractable without these tools.
But I carried questions too—questions that mathematics couldn’t answer:
What should we optimize for?
When is efficiency good, and when does it destroy something valuable?
How do we choose objectives that serve human flourishing rather than arbitrary metrics?
What happens when we optimize brilliantly for the wrong things?
These questions would follow me to Samsung, where algorithms would meet silicon. To Amazon, where theory would generate hundreds of millions in revenue. To Gauss Labs, where industrial AI would confront manufacturing reality. To Erudio Bio, where optimization would serve human health.
Anthropological Lens: The Culture of Silicon Valley Academia and the Mythology of Mentorship
By Jun-Young Park
Sunghee’s account of his time with Stephen Boyd reveals something anthropologists recognize immediately: the ritual construction of legitimate knowledge through lineage.
When Boyd showed Sunghee the mathematical genealogy chart tracing back to Gauss, he was performing what we call tradition authentication—establishing that their work participates in a continuous chain of intellectual authority stretching back centuries. This isn’t unique to mathematics or Stanford. You see it in martial arts (tracing lineages back to legendary masters), in religions (apostolic succession), in crafts (master-apprentice relationships).
But Silicon Valley academia adds its own distinctive flavor to this ancient pattern.
The Mythology of Individual Genius
Notice how the story centers on individual relationships: student to advisor, advisor to their advisor, brilliant mind to brilliant mind. This narrative erases the broader social infrastructure that makes such relationships possible—the staff who maintain the department, the taxpayer funding that supports research, the thousands of students who don’t get mentored by famous professors, the wives and families who supported these “great men” throughout history.
The genealogy chart is a technology of prestige. It tells you who matters (those with famous advisors) and who doesn’t (those working in industry, those at less prestigious institutions, those whose contributions were intellectual but not “original” enough for naming credit).
When Sunghee says having Boyd as his advisor was “one of the luckiest things that have ever happened to my life,” he was being genuine—this relationship genuinely shaped his career. But the flip side is that career opportunities in academia and elite industry disproportionately accrue to those who win the advisor lottery. The system rewards those who study with professors who combine rare intellectual gifts with outstanding scholarly records, creating self-reinforcing prestige hierarchies.
Legitimacy Through Lineage vs. Legitimacy Through Results
Contrast this with Silicon Valley’s other mythology—the scrappy entrepreneur who drops out of Stanford to build something that “changes the world.” That narrative prizes results over pedigree, disruption over tradition.
These two mythologies coexist in Stanford’s culture: you’re supposed to learn from established masters (gaining legitimacy through lineage) while disrupting existing order (gaining legitimacy through innovation). The contradiction is rarely examined.
Sunghee navigated both tracks. His PhD provided institutional legitimacy—the credential of Boyd’s lineage that opened doors at Samsung, Amazon, Gauss Labs, and eventually enabled him to co-found a Gates Foundation-supported biotech company building AI platforms for drug discovery. But his real impact came from bridging theory and practice: transforming abstract optimization principles into working circuit designs, recommendation systems, and biomarker discovery tools.
The Invisible Labor of Knowledge Transfer
Boyd’s teaching appears effortless in Sunghee’s account—the understated comments, the simple diagrams, the elegant insights. But this effortlessness is itself a performance, a display of mastery that obscures enormous preparation and accumulated experience.
Anthropologists studying expertise recognize this pattern: true masters make difficult things look easy, which paradoxically makes their expertise seem almost mystical rather than learned through deliberate effort. This mystification serves the prestige economy—if Boyd’s insights seem to flow from natural genius rather than decades of practice, they become more valuable and less replicable.
The real knowledge transfer happens not in those elegant office sessions but in the hundreds of hours Sunghee spent working through problem sets, reading papers, failing at solutions, gradually developing mathematical intuition. The mythology focuses on the advisor’s wisdom. The reality is mostly the student’s work.
Universal Truth vs. Cultural Practice
Sunghee writes about mathematical truths being “universal—transcending culture, language, and era.” And in one sense, this is correct. The Pythagorean theorem holds in all contexts. Convex optimization principles work regardless of who applies them.
But what we choose to optimize, which problems we consider worth solving, how we deploy these mathematical tools—these are deeply cultural choices.
The fact that a generation of researchers now frame diverse problems as optimization problems reflects not just the power of the mathematics but the cultural dominance of a particular way of seeing. We’ve been trained to ask: “How can I formulate this as an optimization problem?” We less often ask: “Should this be optimized at all?”
Consider: indigenous knowledge systems often resist optimization logic. Many traditional practices seem “inefficient” from an optimization perspective—rituals that take longer than necessary, agricultural methods that yield less than maximized, social customs that constrain individual choice. But these “inefficiencies” often encode hard-won wisdom about sustainability, social cohesion, and values beyond maximization.
When we export optimization thinking globally—teaching it in universities worldwide, embedding it in AI systems deployed across cultures—we’re not just spreading neutral mathematical tools. We’re spreading a particular worldview about what matters (that which can be quantified, measured, and optimized) and what doesn’t (that which resists quantification).
The Question Boyd Couldn’t Teach
Sunghee ends the chapter noting that mathematics tells you how to optimize but not what to optimize for. This is precisely where technical expertise meets cultural values—and where anthropology becomes essential.
Optimization is never value-neutral. Every objective function embodies choices about what matters. When Amazon optimizes for engagement, it chooses to value attention over well-being. When drug companies optimize for profit, they choose shareholder returns over patient access. When we optimize AI systems for benchmark performance, we choose measurable metrics over harder-to-quantify harms.
The mathematical optimization succeeds perfectly in all these cases. The algorithms find global optima. The KKT conditions are satisfied. Duality holds.
But whose values are we optimizing for? Who decides the objective function? Who benefits from the optimization, and who bears the costs?
These questions can’t be answered by mathematics alone. They require what mathematics deliberately excludes: context, power relations, historical understanding, ethical reasoning, and democratic deliberation.
The Sacred and the Secular
Finally, notice the almost religious language (but actually farthest from religious, and rather extremely logical, according to his accounts) Sunghee uses about mathematical truth: “universal truths,” “inevitable structures,” “things that would have to be true in all possible universes (if there could be such things).”
This isn’t accidental. Mathematics occupies a curious position in modern culture—it carries some of the authority that religious truth once held. Mathematical proofs are certain in ways almost nothing else can be. They promise access to eternal truths independent of human judgment or cultural variation.
But this sacredness has consequences. When we formulate problems mathematically, we purify them—stripping away the messy social context that makes them matter. A mathematical optimization problem is clean, formal, and pure. The real-world application is messy, political, and value-laden.
The danger is using mathematical purity to avoid engagement with messy reality. “We’re just optimizing this objective function” becomes a way to avoid asking whether the objective is just. “The algorithm made this decision” becomes a way to disclaim responsibility for the decision’s consequences.
Sunghee doesn’t fall into this trap—his prologue explicitly names the gap between mathematical elegance and human values. But many who learn these tools do. They believe that making something mathematical makes it neutral, objective, and beyond critique (wrongly).
Understanding convex optimization is essential for working with modern AI systems. But understanding the cultural work that optimization thinking does—how it shapes what questions we ask, what solutions we consider legitimate, what values we embed in systems—is equally essential.
The mathematics is universal. What we do with it is not.
Chapter 2: Samsung — When AI Met Silicon (2004-2017)
The Samsung Semiconductor fabrication facility in Hwasung occupies more space than I could comprehend on my first day in 2004. Clean rooms the size of football fields. Machines worth hundreds of millions of dollars. Production lines running 24/7, fabricating chips that would power phones, computers, and servers around the world.
I’d come from Stanford, where we proved theorems on whiteboards and ran simulations on workstations. Here, mathematics met physical reality at nanometer scale. Here, optimization theory would either work in the real world—or reveal itself as elegant abstraction with no practical power.
Stanford had prepared me for the mathematics. It hadn’t prepared me for corporate politics, skeptical engineers, or the crushing weight of decisions worth billions of dollars.
From Theory to Silicon
My role at Samsung was officially “Senior Engineer” in the Computer-Aided Engineering (CAE) Team of Memory Business Division of Samsung Semiconductor, Inc. Practically, it meant: take the convex optimization theory you learned at Stanford and make it work for designing actual semiconductor circuits.
The challenge was both technical and cultural.
Technically: Circuit design for semiconductor memory chips involves thousands of design parameters—transistor widths, lengths, oxide thicknesses, resistances, and capacitances. These parameters must satisfy hundreds of constraints (e.g., power consumption limits, speed requirements, reliability specifications, and manufacturing tolerances) while optimizing multiple objectives (e.g., minimize area, maximize speed, reduce power, and improve yield).
This is exactly the kind of problem convex optimization was built for. Except real circuit design had been done by experienced engineers using intuition, rules of thumb, and iterative trial-and-error for decades. They were good at it. Really good.
Why would they trust algorithms?
Culturally: Samsung in 2004 was a hierarchical organization where respect flowed from experience and seniority. I was 28 years old with a fresh PhD and zero years of industry experience. The senior engineers I’d be working with had been designing circuits since I was in high school. Some had been at Samsung longer than I’d been alive.
My first meeting with the Memory Design team was polite but skeptical.
“So you’re going to use… what? Mathematical optimization to design circuits?”
“Yes. Convex optimization specifically. It can—”
“We’ve been designing these circuits for fifteen years. We know what works.”
“I’m sure you do. But optimization can systematically explore design spaces that would take months manually—”
“Design isn’t just mathematics. It’s intuition. Experience. Understanding how circuits actually behave, not how equations say they should behave.”
This was going to be harder than I thought.
Building Trust, One Problem at a Time
I didn’t try to replace the experienced engineers. That would have been foolish and arrogant. Instead, I started small.
“Give me your hardest problem. Something you’ve been stuck on. Let me try optimization on it.”
The team gave me a circuit sizing problem they’d been wrestling with for weeks—balancing speed, power, and area for a critical DRAM sense amplifier. Hundreds of parameters. Conflicting requirements. No obvious solution.
I spent three days formulating it as an optimization problem, checking my constraints against actual circuit behavior, validating my objective function against their design priorities.
It wasn’t exactly a convex optimization problem. However, I could formulate a convex optimization problem that would approximately solve the original problem. Then I ran the optimization.
The solution was… surprising. It suggested parameter values that violated several “rules of thumb” the experienced engineers swore by. Transistors that were “too wide” by conventional wisdom. Voltages that seemed counterintuitive.
“This can’t be right,” one engineer said when I showed the results.
“Let’s simulate it,” I suggested.
We ran detailed SPICE simulations—the gold standard for circuit verification. The optimized design worked. Not just worked—it was 15% faster, 10% lower power, and 8% smaller area than their best manual design.
Silence in the conference room.
“Run it again,” another engineer said. “Use different starting points. See if you get the same answer.”
I ran it ten more times with random initializations. Every run converged to the same solution. That’s the power of convexity—the global optimum is unique and findable.
That’s when skepticism started turning into curiosity.
The iOpt Platform: Democratizing Optimization
Word spread. Other teams started asking: “Can you optimize our circuit too?”
But I couldn’t manually formulate every circuit as an optimization problem. I needed to build infrastructure—tools that other engineers could use without understanding the underlying mathematics.
This became iOpt (Integration Optimization)—a platform that would eventually be used by hundreds of Samsung engineers and remain in use for a decade after I left.
The key insight: engineers shouldn’t need to know convex optimization theory. They should be able to:
- Specify their circuit topology
- Define their constraints in engineering terms
- Choose their optimization objectives
- Let the platform handle the mathematical formulation and solution
Building iOpt taught me something Boyd never mentioned: the distance between elegant theory and usable tools is vast.
Convex optimization theory is beautiful—clean mathematical formulations, provable convergence, guaranteed global optimality. But real circuits don’t arrive pre-formulated as convex problems. Real engineers don’t speak in terms of Lagrangians and KKT conditions. Real design flows have legacy tools, existing constraints, organizational inertia.
Making optimization usable required:
- Automatic problem formulation (translating engineering specs into mathematical constraints)
- Robust numerical methods (handling the messy reality of circuit models)
- Integration with existing tools (SPICE simulators, layout systems, verification flows)
- Error handling (gracefully dealing with infeasible specifications)
- Results visualization (showing engineers why the solution makes sense)
I spent more time on user interface design and tool integration than on optimization algorithms. The mathematics I’d learned at Stanford was necessary but not sufficient. Making it useful required understanding how engineers actually work.
The DRAM Cell Design Revolution
The project that would define my Samsung career—though I wouldn’t realize its full significance until years later—began in 2009.
Samsung was planning the next generation of DRAM architecture. Not an incremental improvement but a fundamental redesign that would determine the company’s competitive position for the next decade. The strategic choice of cell scheme would translate into tens of billions of dollars in revenue.
This wasn’t just another circuit optimization problem. This was deciding the architecture—the fundamental structure that would constrain every design decision for years to come.
The challenge: evaluate dozens of potential cell architectures, each with hundreds of design parameters, under multiple process technology scenarios, optimizing for area, speed, power, and manufacturability simultaneously.
Doing this manually—with experienced engineers evaluating each architecture through simulation and intuition—would take years. And even then, you couldn’t be sure you’d found the optimal architecture. Maybe some other configuration would have been better?
Convex optimization offered something unprecedented: mathematical proof of optimality. Not “this seems good based on the cases we tried” but “this is provably the best possible solution given these constraints.”
The Next-Generation DRAM Cell Scheme Design Team asked if I could apply optimization to this problem.
My answer: “Yes. But this is going to require significant computational resources and tight collaboration between teams.”
What I didn’t mention: someone in my reporting chain had different ideas.
Doing the Right Thing (Even When It Costs You)
A senior colleague pulled me aside early in the project.
“Sunghee, I need to talk to you about this DRAM cell architecture project.”
“Sure, what about it?”
“You should pull back from it. Focus on projects that will benefit our team more directly. This collaboration… it won’t help our group’s performance metrics. Won’t help our bonuses. Won’t help our visibility with management.”
I was confused. “But this is critical for Samsung overall. The whole strategic direction of DRAM for the next ten years—”
“Right. But it’s not our project. Let the Next-Generation DRAM Cell Scheme Design Team handle it. We should focus on work that shows our team’s value.”
I understood the logic. In large organizations, teams compete for resources and recognition. Working on another team’s strategic project might benefit Samsung but wouldn’t necessarily benefit our team’s metrics.
But the logic made no sense to me. I was employed by Samsung. Samsung was paying my salary to use my skills and expertise for Samsung’s benefit. And clearly, Samsung’s most critical need was solving this DRAM architecture optimization problem. Plus, it was a really fun project!
The choice seemed obvious: I should work on the problem that mattered most for the company, regardless of internal politics.
“I appreciate your perspective,” I told my colleague diplomatically. “But I think I should contribute where I can have the most impact.”
His expression made clear this wasn’t the answer he wanted.
So I worked on the project anyway. Quietly. Collaborating closely with the partner team, spending evenings and weekends formulating the optimization problems, running massive computational experiments, validating results against simulations.
Officially, it wasn’t my team’s priority. Unofficially, I was fully committed.
The work was exhilarating. This was optimization at the scale and stakes I’d never experienced—not academic problems with right answers in the back of the book, but real strategic decisions with billions of dollars and Samsung’s competitive future hanging in the balance.
I formulated the architecture evaluation as a massive optimization problem—thousands of variables, complex constraints encoding manufacturing realities, objective functions balancing competing priorities. Then I systematically evaluated every candidate architecture, computing the optimal design for each under multiple scenarios.
The results were definitive. One particular cell architecture consistently outperformed all alternatives across the entire parameter space. Not marginally better—dramatically better. And I could prove it mathematically.
The Next-Generation DRAM Cell Scheme Design Team was thrilled. For years, they’d relied on experience, intuition, and iterative testing—making the best decisions they could, but never truly knowing if a better architecture existed somewhere in the vast design space they hadn’t explored. Now they had something unprecedented: not just a recommendation but mathematical proof that this architecture was optimal.
The Team Head pulled me aside after the presentation. “For the first time in my career,” he said, “I can stand in front of Samsung’s executives and say with certainty: ‘This is the best possible design.’ Not ‘this is the best we found’ or ‘this worked well in our tests.’ But the best possible. That changes everything.”
Samsung adopted that cell scheme. It would indeed guide their DRAM strategy for the next decade.
As for recognition? My own team barely acknowledged the work—for obvious reasons given the earlier conversation. No performance review mentioned it. No bonus reflected it. No promotion resulted from it.
I didn’t mind. The work itself had been deeply satisfying. I’d applied everything Boyd taught me to a problem of genuine consequence. I’d seen optimization prove its value at industrial scale. I’d built relationships with engineers who appreciated what mathematics could do.
Then I forgot about it. Moved on to other projects. Life continued.
The Long Game: Ten Years Later
Fast forward to late 2019.
I was being recruited to join SK Group’s new industrial AI startup company as a Founding Member and Head of Global R&D. The opportunity was exciting—building AI systems for manufacturing at scale, leading a global team, shaping strategy for a major corporate initiative.
But SK Group did their due diligence carefully. They talked to former colleagues, industry contacts, and people who’d worked with me over the years.
One of their vice chairs reached out to someone from that Next-Generation DRAM Cell Scheme Design Team I’d collaborated with on the DRAM architecture project—the team I’d worked with “secretly” because my own management didn’t prioritize it. I learned about this conversation months later, after I’d joined what would become Gauss Labs Inc.
The vice chair had asked: “Tell me about Sunghee Yun. What was he like to work with?”
The Next-Generation DRAM Cell Scheme Design Team Leader’s response, as I heard it: “Sunghee? He’s brilliant. Absolutely brilliant. But more than that—he has integrity. He doesn’t care about credit or politics. He cares about solving the right problems. Ten years ago, he helped us make the most important strategic decision of that decade. Didn’t ask for recognition. Just wanted to do excellent work. If you’re hiring him, you’re getting someone rare.”
That conversation—about work I’d done quietly, in defiance of short-term team politics, a decade earlier—apparently carried significant weight in SK Group’s decision.
I had no idea any of this was happening. I didn’t do the DRAM work expecting future payoffs. I did it because it was clearly the right thing to do—use my capabilities where they’d have the most impact for my employer.
But here’s what I learned: doing the right thing compounds in ways you can’t predict.
Not because you’ll always be rewarded. Sometimes you won’t be. Sometimes politics wins and integrity loses.
But because over long enough time horizons, people remember who does good work for the right reasons. They remember who can be trusted to put the mission above their own short-term gain. They remember who has both capability and character.
The person who advised me to avoid the DRAM project wasn’t wrong about the short-term calculus. Our team’s metrics probably didn’t benefit. My bonuses that year probably weren’t affected.
But they were wrong about what actually matters. The Next-Generation DRAM Cell Scheme Design Team Leader favorably remembered our collaboration a decade later and spoke up when it counted. That conversation helped shape the trajectory of my career in ways no performance review or bonus ever could.
SK Group’s response to that recommendation showed just how much it mattered. They made me an offer requiring special approval from the Chairman himself—rare even for executive positions. They opened a US office for Gauss Labs specifically to accommodate me, restructuring plans that had assumed Korea-based leadership. I turned them down for six months. I was thriving at Amazon, had no desire to return to Korea, and saw clear growth ahead. But they persisted—because their due diligence had uncovered that decade-old DRAM collaboration and understood its significance. Eventually, that persistence convinced me. Not the compensation, substantial as it was. But the recognition that an organization would restructure around work I’d done quietly, without recognition, a decade prior.
And honestly? I’d make the same choice even if SK Group had never called. Even if that conversation had never happened. Even if the work had remained permanently unrecognized.
Because doing the right thing matters whether or not you get rewarded eventually.
This is perhaps the most important lesson that Samsung taught me—one that Boyd’s mathematics couldn’t teach: technical excellence matters, but character matters more.
Discovering Machine Learning (2010-2015)
Around 2010, a new buzzword started circulating through Silicon Valley and gradually reached Samsung: Big Data!
I was curious but skeptical. What exactly was big data? And what did it have to do with the circuit optimization I’d been doing?
Then Prof. Boyd—still my informal advisor years after graduation—sent me an email: “Sunghee, you should look into something called machine learning. It’s going to be important. And I think you’ll find the mathematics familiar.”
I started exploring. Online seminars. Technical papers. Some classes Samsung offered on emerging technologies. Books on statistical learning theory.
And then I saw it.
At the heart of virtually every supervised learning algorithm—logistic regression, support vector machines, neural networks—there was an optimization problem. Not just any optimization problem, but often a convex optimization problem.
Training a support vector machine? That’s solving a quadratic program with linear constraints—classic convex optimization. Fitting a logistic regression model? That’s minimizing a convex loss function. Even neural networks, which involve non-convex optimization overall, solve convex subproblems at every layer during backpropagation.
This wasn’t a new field. This was my field wearing different clothes.
Other engineers at Samsung were struggling to understand machine learning—what these algorithms did, why they worked, how to apply them. They were learning it as a new discipline, memorizing formulas and techniques without deep understanding of the underlying mathematics.
But for me? With my convex optimization background, years of theoretical training, and decade of industrial practice, I could see through to the mathematical core. I understood not just what these algorithms did but why they worked, when they’d succeed, when they’d fail, and how to modify them for specific problems.
It wasn’t easier for me in the sense of requiring less effort. It was easier in the sense that I understood the inner workings of ML algorithms better than most ML scientists at the time—because I’d spent a decade studying and applying exactly the mathematical machinery these algorithms relied on.
Then in 2012, something remarkable happened.
A team led by Geoffrey Hinton entered a deep neural network called AlexNet in the ImageNet Large Scale Visual Recognition Challenge (ILSVRC). They didn’t just win. They crushed the competition—reducing the error rate from 26% to 15%, a margin of victory that seemed almost impossible.
Suddenly, people weren’t just talking about machine learning. They were talking about Deep Learning.
I started reading everything I could find. Academic papers from major ML conferences such as NIPS, CVPR, ICLR, etc. Blog posts from Silicon Valley researchers. Technical reports from Nvidia, Google, Facebook, and Microsoft. The field was exploding.
And I realized something important: this was the future.
Not just for tech companies but for every industry. Not just for software but for hardware, manufacturing, biotech, everything. AI was about to transform how we would build products, serve customers, and make decisions.
By 2015, my conviction had crystallized: I needed to be in Silicon Valley. Not visiting. Not consulting remotely. But immersed in the ecosystem where this AI revolution was happening.
Samsung was a great company. Korea was home. I’d built a successful career there. But if I wanted to be at the forefront of AI—to work on the hardest problems, with the best talents, at the scale and speed this transformation demanded—I needed to be in Silicon Valley.
Coincidentally—or perhaps inevitably, given how the AI hiring market was exploding—recruiters from Silicon Valley tech companies started reaching out. Nvidia, Amazon, Google, Facebook, and Microsoft. They’d seen my work. They needed people who understood both the theoretical foundations and the practical realities of building AI systems at scale.
The Decision to Join Amazon (2017)
In 2017, I made what would prove to be one of the best decisions of my life; I accepted an offer from Amazon to join as a Senior Applied Scientist.
The decision wasn’t easy. Samsung had been good to me. I’d built lasting relationships, created tools still in use, contributed to strategic decisions worth billions. Korea was comfortable. Familiar. Home.
But Amazon offered something I couldn’t find in Korea: the chance to work on AI problems at unprecedented scale, with world-class teams, in a company that was betting its future on machine learning.
Amazon in 2017 was already using ML everywhere—recommendation systems, supply chain optimization, fraud detection, Alexa, and AWS services. (Actually, Amazon was one of the first companies that used ML for their business even before we named the technology ML.) But they were just getting started. The company was aggressively hiring ML scientists and engineers, investing billions in AI infrastructure, pushing the boundaries of what was possible.
I’d be working on recommendation systems—using ML to help hundreds of millions of customers discover products they’d love. Not toy problems or academic datasets. Real systems touching real people, generating real business value.
The mathematics I’d learned from Boyd, the engineering discipline I’d developed at Samsung, the ML knowledge I’d acquired over the past seven years—all of it would come together in work that mattered at a scale I’d never experienced.
I said yes.
And over the next few years at Amazon, I’d work on multiple high-impact AI projects. One of them—a recommendation system improvement I led—would generate more than $200 million in incremental revenue.
But I’d also learn something darker about optimization at scale. Something about what happens when you optimize brilliantly for metrics that don’t quite capture what actually matters. Something about the gap between mathematical success and human flourishing.
That lesson—painful, necessary, transformative—would eventually lead me to Gauss Labs, and later to Erudio Bio, where I’m still trying to figure out how to build AI systems that serve human values, not just mathematical objectives.
What Thirteen Years at Samsung Taught Me
Looking back, my Samsung years clarified three insights that would shape everything after:
First: Abstract mathematics becomes powerful only when embodied in usable tools.
Boyd taught me convex optimization theory. Samsung taught me that theory alone changes nothing. You need platforms, interfaces, integrations, documentation, training, and support. You need to meet engineers where they are. The mathematics matters, but the engineering around the mathematics matters just as much.
Second: Organizations optimize for what they measure.
Samsung measured yield, area, speed, and power. So that’s what got optimized. The company was extraordinarily good at it—world-class execution. But what about reliability? Sustainability? Worker wellbeing? Long-term resilience? These weren’t in the optimization objective function, so they didn’t get optimized for. Sometimes they got worse as “externalities” of optimizing what was measured.
Third: Doing the right thing is never wasted, even when it’s not immediately rewarded.
That DRAM architecture work I did “secretly” against short-term team politics? It came back to matter a decade later in ways I couldn’t have predicted. More importantly, it taught me that integrity and excellence compound over time. Character is a long game.
Fourth: Deep expertise in fundamentals gives you unfair advantages in emerging fields.
When machine learning exploded in the 2010s, many engineers scrambled to learn new techniques without understanding the underlying mathematics. My decade of optimization expertise meant I could see through to the core principles—understanding not just what these algorithms did but why they worked and how to extend them. Fundamentals compound. Techniques come and go. Mathematical understanding endures.
These lessons—some technical, some organizational, some moral—would prove essential when I arrived at Amazon, where optimization operated at unprecedented scale and where its consequences touched hundreds of millions of lives.
Anthropological Lens: Corporate Optimization and the Tyranny of Metrics
By Jun-Young Park
Sunghee’s Samsung years reveal a crucial anthropological insight: organizations don’t just use optimization—they become what they optimize for.
When Samsung adopted convex optimization for circuit design, they weren’t just adding a new tool. They were reshaping how problems were defined, what solutions were considered legitimate, what trade-offs were visible, and ultimately what the organization valued.
The Seduction of Measurability
Notice what happened: once optimization tools proved successful, engineers started treating optimizability as a criterion for what problems to work on. Problems that couldn’t be cleanly formulated as optimization problems—requiring judgment, intuition, long-term thinking—got deprioritized.
This is what anthropologists call metricization—the process by which quantifiable measures gradually colonize decision-making until “what we can measure” becomes indistinguishable from “what matters.”
iOpt’s success accelerated this process. The more the platform was used, the more Samsung’s engineering culture shifted toward seeing problems as optimization problems. Alternative approaches—simulation-based exploration, experience-driven intuition, experimental prototyping—lost prestige and resources.
The mathematics wasn’t wrong. But its very success changed what kinds of questions got asked.
Short-Termism as Emergent Property
The DRAM cell architecture story reveals something profound about organizational dynamics: even when individuals want to act in the organization’s long-term interest, internal incentive structures often punish them for it.
The senior colleague who advised Sunghee to avoid the project wasn’t personally malicious. They were responding rationally to how their team was evaluated—on short-term deliverables and visible achievements. The fact that Sunghee’s work would determine Samsung’s competitive position for a decade was irrelevant to that quarter’s performance review.
This is classic principal-agent misalignment, but notice the cruel irony: optimization tools make this worse, not better. When teams are measured by optimization metrics (speed up design time! improve yield! reduce costs!), they’ll optimize exactly those metrics—even when doing so undermines broader organizational goals.
You can’t optimize your way out of bad optimization objectives. And organizations rarely optimize their optimization objectives with the same rigor they apply to everything else.
The Morality Play of Technical Work
Sunghee presents his decision to work on the DRAM project despite pushback as an obvious moral choice. And in retrospect, it seems clear cut—of course you should work on what matters most for the organization paying you!
But most engineers in similar situations make the opposite choice. They optimize for their immediate career metrics: pleasing their direct manager, showing visible results on team projects, avoiding work that doesn’t “count” for promotion.
They’re not being unethical—they’re being rational within their local incentive structure.
What made Sunghee’s choice possible? Probably some combination of:
- Confidence in his skills (he could do both projects if needed)
- Sufficient reputation that he wasn’t in immediate career danger
- Personal values that genuinely prioritized mission over metrics
- Possibly some Korean cultural values around loyalty to employer
But the deeper question is: why should individual engineers need to be heroes to do what’s obviously best for their employer? What kind of organizational structure creates that dilemma in the first place?
The Validation Cycle
Here’s what fascinates me: Sunghee’s “reward” for integrity came ten years later when an SK Group vice chair happened to talk to the right person. This feels like a moral fable—good deeds eventually rewarded!
But this is survivor bias. For every Sunghee whose integrity happens to be discovered and rewarded, there are dozens of engineers who did the right thing and faced only costs: poor performance reviews, missed promotions, and career stagnation.
We tell stories about the successes because they’re inspiring and because they validate our belief that systems eventually reward merit. We don’t tell stories about the equally competent, equally ethical engineers who got pushed out or burned out because they didn’t play the optimization game.
This doesn’t undermine Sunghee’s point that “doing the right thing matters whether or not you get rewarded.” That’s true. But it obscures the systemic problem: organizations that rely on individual integrity to overcome structural dysfunction are organizations with broken incentives.
The Paradigm Shift: From Circuits to Learning
The transition Sunghee describes—from circuit optimization to machine learning—reveals something anthropologists call epistemic transfer: how expertise in one domain gets reframed as expertise in an emerging domain.
When “big data” and “machine learning” became buzzwords around 2010, they carried an aura of novelty—completely new fields requiring completely new expertise. Organizations scrambled to hire “data scientists” and “ML engineers” as if these were entirely new species of professional.
But Sunghee’s experience reveals the truth: machine learning wasn’t fundamentally new. It was largely applied optimization theory dressed in different terminology, working with different kinds of data.
This created a fascinating dynamic: engineers who’d spent years on “traditional” optimization suddenly found their expertise unexpectedly relevant to the hottest new field. Meanwhile, self-taught ML practitioners who’d learned techniques without mathematical foundations struggled to understand why their models worked, when they’d fail, and how to fix them.
The prestige economy inverted almost overnight. Optimization—previously seen as a specialized, somewhat old-fashioned discipline—suddenly became essential infrastructure for the AI revolution. Boyd’s textbook, published in 2004, became required reading for ML researchers a decade later.
But notice what got lost in translation: the questions that optimization theory forces you to ask. What are you optimizing for? Why? Who benefits? What are you not measuring?
ML culture, especially in its early industrial applications, inherited optimization’s techniques without inheriting its caution. The result was systems that optimized brilliantly for poorly chosen objectives—engagement, clicks, revenue—without asking whether those objectives served human flourishing.
The Geographic Imperative
Sunghee’s recognition that he needed to be in Silicon Valley to work on AI reveals another anthropological truth: innovation is spatially clustered not just because of resource concentration but because of shared cultural frames.
Yes, Silicon Valley had more AI talent, more funding, more computational resources. But more fundamentally, it had a culture that treated AI as the future, that normalized experimentation, that rewarded risk-taking in ways Korean corporate culture didn’t.
This isn’t about Korean culture being inferior—it’s about different optimization objectives. Korean companies like Samsung optimize for execution, reliability, manufacturing excellence. Silicon Valley companies optimize for innovation, disruption, “move fast and break things.”
Neither is inherently better. But they’re different. And if you want to work on emerging AI technologies, being physically present in a culture that treats AI as normal, obvious, and inevitable gives you advantages no amount of remote participation can match.
The decision to leave Samsung wasn’t just about a job change. It was about changing cultural context—immersing himself in an environment where his interests and expertise would be amplified rather than seen as adjacent to the core business.
What the Metrics Miss
Sunghee’s fourth lesson—that deep expertise in fundamentals gives unfair advantages in emerging fields—points to something optimization culture systematically undervalues: generalizable understanding versus specific skills.
Organizations optimize hiring, training, and promotion around demonstrable skills: “Can you design this circuit?” “Can you build this model?” “Can you ship this feature?”
They don’t know how to measure—and therefore don’t optimize for—deep mathematical understanding that might become relevant to problems that don’t exist yet.
This is why Sunghee’s optimization expertise turned out to be so valuable for machine learning: not because anyone at Samsung was optimizing for “prepare engineers for the coming AI revolution” but almost despite the organization’s optimization objectives.
The most valuable forms of knowledge are often the hardest to measure. And what you can’t measure, you can’t optimize for.
This is the fundamental tension this book explores: optimization is extraordinarily powerful for reaching specified objectives. But the most important human capabilities—judgment, wisdom, moral reasoning, generalized understanding—resist optimization precisely because they can’t be reduced to measurable objectives.
Understanding how optimization works (Sunghee’s expertise) is essential. Understanding what optimization does—how it reshapes organizations, incentives, decision-making, and values—is equally essential.
That’s the gap between engineering and anthropology. Between tool and critique. Between how and why.
And it’s the gap this book is trying to bridge.
Chapter 3: Amazon — When Optimization Met Scale (2017-2020)
I’d be driving to Samsung Semiconductor’s Hwasung campus, listening to audiobooks about machine learning (ML) and absorbing the holistic picture of Silicon Valley’s AI ecosystem—not just the algorithms but the culture, the business models, the way companies were reorganizing around AI—mostly content published in real-time by Silicon Valley researchers, practitioners, and entrepreneurs. Or I’d be reading blog posts during lunch, following the explosion of interest after AlexNet’s stunning ImageNet victory.
And I’d think: This is going to change everything.
Not incrementally. Not gradually. But fundamentally, the way the internet changed everything in the late 1990s, the way smartphones changed everything in the late 2000s. AI—though at that time almost nobody used that term; “machine learning” was the standard phrase for these new waves—was going to transform every industry, every product, and every business model.
Looking back now from 2025, I can say with certainty: I was right.
Except for one thing: the impact was even way greater than I could ever imagine.
I predicted transformation. What actually happened was something closer to revolution. GPT-4 and large language models reshaping how humans interact with computers. Generative AI touching everything from art to software development. AI agents automating entire workflows. The technology progressing faster, penetrating deeper, mattering more than even my ambitious 2012 predictions suggested.
But back then, in 2012 through 2017, the future impact wasn’t obvious to most people around me.
The evidence was everywhere—in the papers, in the blog posts, in the investments Silicon Valley companies were making, and the talent wars already beginning. You didn’t need special insight about the industry or prophetic vision about the future. You just had to read the textbooks, follow the research, and think logically about the implications.
But when I looked around Samsung—talking to colleagues, attending meetings, and observing priorities—almost nobody else saw it. Most people were busy with their everyday routines, focused on the next quarter’s deliverables, and optimizing the problems they already knew how to solve.
And that created a deeply unsettling cognitive dissonance.
When you believe something this strongly, and almost everyone around you seems oblivious to it, you don’t automatically think: “I’m the only one who sees the truth!” You think: “There’s no way all these smart, experienced people are wrong. I must be missing something. I must be wrong.”
But basic logical thinking kept reassuring me that I was right. The math worked. The results were reproducible. The trajectory was clear. This wasn’t speculation or hype. This was pattern recognition backed by evidence.
So I made a choice: act on what the evidence showed, not on what the consensus believed.
Preparing for the Wave (2010-2017)
Starting around 2010, I began seriously integrating machine learning techniques into iOpt. Not as a separate initiative but as natural extensions of the optimization work I’d been doing.
I worked on diverse projects with the DRAM Design Team, NAND Flash Memory Design Team, Process Team, Test Team, and others—applying ML where it made sense and learning what worked and what didn’t at industrial scale.
In 2015, I was asked to lead a special Task Force—not requested, ordered—by the CEO and President of Samsung Semiconductor Division. The project required flying to Suzhou, China five times within six months. High stakes. High visibility. High pressure.
The work went well enough that in 2016, an Executive Vice President who’d recognized my contribution asked me to join the Strategic Sales and Marketing Team of Samsung Semiconductor Memory Division. This was unusual—CAE engineers didn’t typically move into sales and marketing. But he wanted someone who could apply ML techniques to marketing data, and I was curious about seeing the business from that angle.
That year gave me something unexpected: insight into the nature of economic prediction. Working with marketing data, applying diverse ML techniques, I finally saw a holistic view of the worldwide DRAM and NAND Flash Memory markets. And I learned something important: the complexity and unpredictability of markets meant that trying to beat them through individual stock picking was mostly a waste of time and mental energy. Better to just use mutual funds and spend your cognitive resources on problems where expertise actually matters.
(This lesson probably saved me from countless hours of futile market analysis in the years since.)
In 2017, Samsung Device Solution’s Software Research Center asked me to join their team. They needed ML expertise badly. I accepted and worked on decentralized deep learning—quite similar to what Google was calling “federated learning” at the time.
And then, as I mentioned in the previous chapter, Silicon Valley recruiters started calling.
The Decision: Amazon (2017)
I knew the AI era was coming. Every textbook, every paper, every serious analysis pointed to the same conclusion. The impact would be enormous, transformative, irreversible. But I was in Korea, where most of my colleagues still didn’t see it. Where the infrastructure, the talent density, and the cultural momentum for AI wasn’t there yet.
If I wanted to be at the forefront of this transformation—working on the hardest problems, with the best teams, at the scale where AI would matter most—I needed to be join Silicon Valley big tech companies.
The decision to join Amazon wasn’t easy. Samsung had been good to me. Korea was home. I was 41 years old with a family—my daughter and my wife. This wasn’t like going to Stanford at 22, young and unencumbered.
But Amazon in 2017 was placing massive bets on machine learning. Recommendation systems. Supply chain optimization. Alexa. AWS. Fraud detection. They were hiring aggressively, investing billions, and pushing boundaries.
And crucially: they had scale. Hundreds of millions of customers. Exabytes of data. Infrastructure that could train models most companies couldn’t even conceptualize.
I said yes.
Amazon’s Secret Weapon: Culture, Not Technology
Before diving into the projects, I need to explain something about Amazon that most people misunderstand.
When people talk about Amazon’s success, they focus on technology: AWS infrastructure, sophisticated algorithms, and massive scale. These matter. But they’re not the secret.
Amazon’s secret weapon is culture.
Specifically: the Leadership Principles.
These aren’t corporate platitudes on a wall that nobody follows. They’re the actual operating system of how Amazon makes decisions, evaluates people, resolves conflicts, and chooses priorities.
There are fourteen principles (now sixteen, but fourteen when I was there). Let me highlight the ones that I liked most.
Customer Obsession: “Leaders start with the customer and work backwards.”
This isn’t “customers are important” lip service. It’s the forcing function for every decision. You can’t launch a project without explaining what customer problems or pain points it solves. You can’t win an argument by citing elegant technology—only by showing customer benefit.
Invent and Simplify: “Leaders expect and require innovation and invention from their teams and always find ways to simplify.”
This principle gave me permission—expectation, really—to not just use off-the-shelf ML algorithms but to invent custom solutions when standard approaches didn’t work.
Have Backbone; Disagree and Commit: “Leaders are obligated to respectfully challenge decisions when they disagree, even when doing so is uncomfortable or exhausting. Leaders have conviction and are tenacious. They do not compromise for the sake of social cohesion. Once a decision is determined, they commit wholly.”
This one I loved most. It captured something essential about high-functioning organizations: you should argue fiercely for what you believe is right, but once the decision is made, you execute it fully even if it wasn’t your preferred approach. No passive-aggressive undermining. No “I told you so” when things go wrong. Commit with full accountability.
Dive Deep: “Leaders operate at all levels, stay connected to the details, audit frequently, and are skeptical when metrics and anecdotes differ.”
This principle meant I couldn’t just hand-wave about “AI” or “ML algorithms.” I had to understand the mathematics deeply, the data thoroughly, the customer problem precisely.
Bias for Action: “Speed matters in business. Many decisions and actions are reversible and do not need extensive study. We value calculated risk taking.”
This principle distinguished Amazon from the corporate paralysis I’d seen elsewhere. At Samsung, decisions often required multiple approval layers, extensive documentation, and consensus building across teams. By the time you got permission to try something, the opportunity had often passed.
Amazon’s bias for action meant: if a decision is reversible, make it quickly with available information. Don’t wait for perfect data. Don’t require unanimous approval. Try it, measure the results, and reverse course if wrong.
Jeff Bezos himself captured this philosophy: “If your product is flawless or bug-free when deployed, it’s deployed too late.” He also insisted that leaders should make decisions with approximately 70% of the perfect data required—waiting for 90% or 100% means you’re moving too slowly, and competitors who act on 70% will beat you.
This is why A/B testing was religious at Amazon. You didn’t need to convince everyone your idea was right. You needed to convince your manager to let you test it. Then the data would decide. If your algorithm improved metrics, great—scale it up. If it hurt metrics, kill it quickly and try something else.
The Amazon Mobile Shopping App Main Menu Personalization project, which created $200 million additional revenue, exemplified this. When our first version lost revenue, we didn’t form committees to study what went wrong for months. We analyzed furiously for three weeks, formed hypotheses, launched version two, and tested again. Fast iteration, measurement-driven decisions, willingness to fail fast and learn.
These principles created an environment where:
- Engineers couldn’t hide behind technical complexity to avoid explaining value
- Managers couldn’t ignore technical details they found inconvenient
- Teams couldn’t optimize local metrics at the expense of customer experience
- Individuals had both permission and obligation to challenge bad decisions
I believe Amazon’s culture, more than any single technology, explains their sustained success.
You can copy AWS. You can hire ML scientists. You can build data centers. But you can’t easily copy a culture that actually operationalizes customer obsession and rigorous thinking at scale. Culture isn’t a program you implement or a set of posters on the wall. The company is its culture—they’re indistinguishable.
The PR/FAQ Process: Working Backwards from the Customer
One of Amazon’s most distinctive practices is the PR/FAQ (Press Release / Frequently Asked Questions) process for new initiatives.
Here’s how it works:
Before writing any code, building any system, or launching any project, you write two documents:
- A Press Release announcing the completed project as if it already exists and has launched. This forces you to articulate:
- What customer problem does this solve?
- Why should customers care?
- What’s the benefit in clear, non-technical language?
- What makes this meaningfully better than alternatives?
- An FAQ document answering questions like:
- Why is this technically feasible?
- What are the risks?
- What resources are required?
- How do we measure success?
- What are we NOT doing and why?
The process seems backwards if you’re used to technology-first thinking. Engineers naturally want to start with: “Here’s a cool algorithm we could build…” or “We have this data, let’s do something with it.”
PR/FAQ forces the opposite: start with the customer value proposition. Only proceed if you can articulate that clearly. Then work backwards to the technical solution.
When I was exploring potential AI projects after my first success (more on that shortly), Adam—my manager, who I considered almost an ideal manager—and I went through the PR/FAQ process rigorously. We collected feedback from various teams, listed around a dozen potential projects, then used PR/FAQ to triage and identify which would have the highest customer impact with reasonable technical risk.
The discipline of this process saved months of work on projects that would have been technically interesting but ultimately not valuable enough to customers to justify the resources.
Project One: Mobile App Cold Start Time Prediction
My first major project at Amazon came directly from the top—an S-Team Goal, which meant it originated from Jeff Bezos, then Amazon’s CEO, himself.
The problem: predicting how long the Amazon Mobile Shopping App would take to start.
This sounds trivial until you understand the stakes. Some psychologists say customers leave a website if loading takes more than three seconds. For Amazon, where revenue runs into hundreds of billions annually, app start time is critical. Every fraction of a second matters.
And there was complexity that made this hard.
Amazon’s Mobile Shopping App team released new versions constantly—every other week, alternating between iOS and Android. One week Android update, next week iOS, then Android again. Real agile, genuinely fast-moving.
Before each release, test engineers needed to verify the app started quickly enough. But here’s the problem: there are hundreds of device types among Amazon’s customers—different iPhone models, countless Android manufacturers and models, different OS versions, different Wi-Fi conditions, different network carriers.
In our test lab, we had maybe two dozen devices and relatively homogeneous network conditions. How could we predict app start time for hundreds of millions of customers across hundreds of device types in wildly varying network conditions based on testing a couple dozen devices in controlled environments?
The challenge required:
- Estimating the distribution of device types among all customers
- Estimating internet connection condition distributions
- Using AI techniques, similar to time-series anomaly detection, to predict performance
- Dealing with non-normal distributions that required studying new statistical methods
Here’s where my strong background in mathematics and statistics—not just machine learning—became crucial.
I didn’t just apply off-the-shelf AI algorithms. I read papers from the 1960s on advanced statistical methods. I combined classical statistics with modern AI. I understood the mathematical principles deeply enough to adapt techniques to this specific problem.
Suhail, then director of the entire Amazon Mobile Shopping organization, told me that before my work, the chance of correctly predicting whether start time would be acceptable was essentially 50/50—random guessing.
My algorithm achieved 97% accuracy for iOS and 94% for Android.
That success earned me something invaluable at Amazon: trust from leadership.
Project Two: Main Menu Personalization—The $207 Million Algorithm
After the cold start prediction success, I was tasked with something more ambitious: examining and collecting all potential AI projects across the Mobile organization and partner teams.
Adam and I went through the PR/FAQ process I described earlier, collecting feedback from various teams, evaluating roughly a dozen potential projects. We triaged based on customer impact, technical feasibility, and strategic importance.
The winner: Mobile Shopping App Main Menu Personalization.
Let me explain the problem.
On Amazon’s retail website—viewed on desktops or laptops—you can see various stores: Books, Electronics, Kindle Store, Women’s Clothing, Men’s Clothing, etc. At that time, there were about 44 different stores.
But on the Mobile App, screen real estate is limited. We could only show a handful of main menus by default to each customer.
Amazon, in a sense, was born with machine learning. They’d been using recommendation systems for book recommendations since before “machine learning” became a standard term—using these techniques almost before knowing they’d be called ML. So Amazon already had advanced ML-based system for optimizing which main menus to show each customer.
My task: make it significantly better.
I researched extensively and decided on an approach: collaborative filtering combined with content-based filtering, plus customized statistical methods and advanced AI techniques to resolve cold-start problems (new users with no history).
Once again, I wasn’t using only AI algorithms. I combined them with traditional statistical methods. My mathematical background freed me from being stuck with a limited toolkit—I could use whatever methods worked best for the problem.
This time, we formed a large coalition team across three cities:
- Me and my team in Vancouver
- Product managers in Seattle
- Software development engineers in San Francisco
The SF software engineers were incredible. One day, I tried downloading data for all Mobile Shopping App active users for the past 8 weeks. Because Amazon has a tremendous number of customers, it took 8 hours just to download the data. Considering we wanted to run my algorithm daily, 8 hours was intolerable.
The SF engineers reduced that time to 8 minutes.
To me, it was like magic. This is why I genuinely respected software development engineers and made teamwork a priority. (I later heard from other Amazon Applied Scientists that conflicts between applied scientists and software engineers were common. Maybe my respect for their craft made the difference.)
But then came the nightmare.
We finally launched the algorithm and increased the portion of customers fed by our new system. The A/B test results came in.
We were losing revenue.
The following three weeks felt like never-ending nightmare. I’d actually hurt Amazon’s business. The three teams worked day and night, analyzing data, debugging, and trying to understand what went wrong.
We found plausible reasons for the poor performance and launched a second version.
Then came the day we’d know if version two worked.
A/B testing isn’t simple. You need at least seven days to account for weekly patterns (Monday through Friday variations, weekend behavior). So we waited. Analyzed. Worried.
I still vividly remember Kabir—the project manager in Seattle—appearing on my monitor with the brightest face I’d ever seen.
“The results are in,” he said.
The new algorithm would increase annual revenue through the Amazon Mobile Shopping App by $207,133,371.12.
I couldn’t believe it. Well, I believed the algorithm would work eventually. But that number? That specific, enormous number?
My algorithm was choosing the best main menus for each customer every day, increasing engagement, and making shopping journeys more pleasant. And at Amazon’s scale, those small improvements in engagement translated into massive revenue increases.
The timing couldn’t have been better. When I joined Amazon in 2017, revenue through the Mobile Shopping App was smaller than revenue through the Amazon retail website on PCs. But by the time I was working on this project, mobile revenue had exceeded desktop revenue.
The mobile era had arrived. And we’d optimized for exactly the right moment.
I joked with Adam: “Should we ask your boss if we can get, say, 1% of $200 million? I’ll split it with you fifty-fifty.”
Unfortunately, that never happened. But I got something more valuable: even more trust from leadership. Which meant I could finally launch my own audacious project.
Project Three: TestBot—Automated Healing for Broken Tests
With trust established from two successful projects, I could pursue something riskier, more ambitious, more uncertain.
The problem: automatically fix broken integration testing for mobile apps.
Testing mobile apps requires simulating user actions through the graphical interface. Amazon used software called Espresso that emulated customer actions—touching buttons, filling out forms, navigating screens, etc.
But here’s how it worked under the hood: to push a button, the test code needed to know the button’s ID. Test engineers had numerous test scenarios, and they manually wrote Espresso code for each.
The problem? Tests were brittle.
When the UI changed—a button moved, a form reorganized, a screen redesigned—test scripts broke. Engineers had to manually update scripts every time. With Amazon’s fast release cadence (every other week), this created constant firefighting.
I decided to use deep reinforcement learning to:
- Detect when tests broke
- Automatically fix the tests by rewriting scripts
- Heal the entire pipeline automatically without human intervention
Once again, I didn’t use off-the-shelf algorithms. I studied the fundamental inner workings, even getting into philosophical thinking about what “understanding” means for an AI system. Amazingly, this philosophical approach helped with practical implementation.
The work focused primarily on Build Verification Tests (BVT)—also called smoke tests—which are the first-line checks that basic functionality works.
But I went further.
The statistical nature of my algorithms enabled finding the most probable paths that would break tests—essentially, predicting where future bugs would likely emerge.
This was critical because test coverage can never be 100% (almost by definition). There’s always a chance newly released apps will unexpectedly crash for customers. When that happens, it’s an emergency. We’d open a war room, and work until we fixed it, because it means millions of dollars lost per second.
Having algorithmically-identified probable breaking sequences meant we could prevent catastrophes before they happened.
TestBot was destined to be my last project at Amazon. I wouldn’t have been able to start something this challenging—where success wasn’t guaranteed—without the credibility from my previous two projects.
COVID-19 and the Tsunami of Decisions
Then 2020 arrived. COVID-19.
Suddenly, all Amazonians were deep into work-from-home mode. Surprisingly, many people expressed concerns about work-life harmony—the boundary between work and life had blurred. People were working longer hours, finding it hard to disconnect.
This seemed quite different from what was happening in Korea, from what I could tell. Perhaps it was Amazon’s strength—ownership, deep dive, customer obsession—taken to an extreme when your home became your office.
But I had something else on my mind.
By that time, I was going through agonizing moments because I had three offers:
- DGIST: Head of AI Graduate School
- Seoul National University: Professor in Data Science Graduate School
- SK hynix: Co-Founder and CTO for a newly spinning off industrial AI startup (soon to be called Gauss Labs)
Plus a fourth option: staying at Amazon, where Adam was supporting my promotion to Principal Applied Scientist (a role that didn’t even exist in Vancouver yet).
For probably the first time in my life, I realized that having options isn’t necessarily a good thing. At some moments, I even thought it was a curse to have options, because otherwise I wouldn’t have to go through these agonies.
The academic offers were prestigious. I’d always maintained peculiar and unique academic muscles even through my industry years. At Samsung, I’d opened several classes and became a popular internal lecturer teaching basic linear algebra, basic statistics, advanced linear algebra, advanced statistics, and even convex optimization—all in addition to my normal responsibilities. At Amazon, I also taught many machine learning classes internally and informally mentored more than ten Amazonians.
Teaching came naturally. Research interested me. Academia had appeal.
Amazon represented continued growth in an environment I understood, with people I respected, doing work that mattered at unprecedented scale.
But the SK hynix offer—co-founding Gauss Labs—was simultaneously the most attractive and most terrifying choice of my life.
It required courage I wasn’t sure I had.
Going to Stanford at 22 was one thing. Joining Amazon at 41 with a family—my daughter and my wife—was another level of risk. But joining a startup? I’d literally been telling my daughter: “Your daddy may seem rebellious in big established companies like Samsung and Amazon, but I’m actually quite conservative. Plus, I know that even before the dot-com bubble, the success rate of startups in Silicon Valley was around 3%, and normally it’s less than 1%. So in my life, there’s no joining a startup company.”
Going to Stanford at 22 was one thing. Joining Amazon at 41 with a family—my daughter and my wife—was another level of risk. But joining a startup? I’d literally been telling my daughter: “I know Daddy seems like he takes chances at work, but I’m actually pretty careful about the really big stuff. And startup companies? Those are really risky, honey. Most of them don’t work out. So Daddy’s going to stick with companies like Samsung and Amazon—the safe ones. Okay?”
Now I was considering exactly that.
The Offer I Couldn’t Refuse
For six months, SK hynix kept approaching me. For six months, I kept declining.
Finally, I made up my mind. “I’m sorry,” I told them, “but my family wants to stay in Canada. Plus, I can see a very promising career path at Amazon.”
Then the HR Head of SK hynix made an offer that was totally unexpected.
A compensation package so large he had to get special approval from the Chairman of SK Group himself. (This rarely happened, even for executive positions.)
And something even more audacious: they would open a US office in Silicon Valley for Gauss Labs specifically to accommodate me. I wouldn’t have to return to Korea.
These were offers I could not reject.
More than the compensation—though it was substantial—it was the recognition. An organization was willing to restructure its plans around work I’d done quietly, without recognition, a decade earlier at Samsung. They’d done their due diligence, talked to people who’d worked with me, and decided I was worth this kind of investment.
So I determined to embark on yet another journey. Moving again, but into uncharted territory.
It would prove to be another of the best decisions of my life.
What Three Years at Amazon Taught Me
Looking back, my Amazon years crystallized four critical lessons:
First: Deep learning doesn’t do everything. Mathematical foundations matter enormously.
My muscles in statistics and mathematics helped me constantly. Collaborative filtering, to me, was just matrix factorization—understanding it required no mental effort because I was versed in linear algebra and numerical linear algebra. When standard ML techniques didn’t work, I could draw on classical statistics from papers published in the 1960s. Technical depth in fundamentals gave me flexibility that pure ML specialists often lacked.
Second: Being an AI generalist, not a specialist, was a strategic advantage.
I didn’t do ML research for my PhD. When I got my degree in 2004, almost nobody was doing deep learning research because deep learning didn’t work at that time. Nobody except Geoffrey Hinton really believed in it. I wasn’t a computer vision specialist. I wasn’t an NLP expert. I wasn’t a reinforcement learning researcher, either.
But I could self-study and learn every necessary technique whenever I needed them. This generalist approach—grounded in mathematical fundamentals—let me tackle wildly different problems: time-series prediction, recommendation systems, reinforcement learning for test automation.
Third: Technology comes second, not first. Customer problems come first.
I didn’t choose technology then hunt for problems. I wrote PR/FAQs, got them reviewed by people with diverse backgrounds, focused on customers’ pain points, then started thinking about which technology would work best. This ordering—customer first, technology second—was crucial to actual impact versus mere technical elegance.
Fourth: Genuinely respecting software development engineers made everything better.
The teamwork I had with the SF and Seattle teams for the Main Menu Personalization project couldn’t have been better. I heard from other Applied Scientists that conflicts between scientists and engineers were common at Amazon. Maybe my genuine respect for their craft made the difference. Or maybe recognizing that turning “8 hours to 8 minutes” was as impressive as any ML algorithm helped build mutual respect.
The latter two lessons—customer focus and cross-functional collaboration—were crucial factors in my success. The first two—mathematical depth and generalist breadth—gave me the technical capabilities. But capabilities without collaboration and customer focus don’t generate $207 million in revenue.
Anthropological Lens: The Peculiar Culture of Amazon and the Metrics That Shape Us
By Jun-Young Park
Sunghee’s Amazon experience reveals something anthropologists find endlessly fascinating: how organizational culture functions as both enabler and constraint.
When Sunghee says Amazon’s culture was more important than its technology, he’s making a claim that sounds like corporate platitude but actually reflects deep anthropological truth.
Culture as Operating System
Most companies have “values” listed on websites that nobody actually follows. Amazon’s Leadership Principles function differently—they’re the actual decision-making framework that resolves conflicts, allocates resources, and evaluates performance.
This is what anthropologists call an enacted culture versus an espoused culture. Many organizations espouse customer focus but enact shareholder primacy or manager appeasement. Amazon, whatever its other flaws, genuinely enacts customer obsession as the primary optimization objective.
The PR/FAQ process is particularly brilliant as a cultural technology. By forcing teams to articulate customer value before building anything, it creates a structural barrier against the engineer’s natural instinct to build cool technology for its own sake.
Notice the inversion: instead of “we have this capability, let’s find uses for it,” the process demands “customers need this, let’s figure out how to build it.” This doesn’t guarantee success, but it dramatically increases the probability that technical work will actually matter.
“Have Backbone; Disagree and Commit” as Social Technology
The principle Sunghee loved most—”Have Backbone; Disagree and Commit”—is anthropologically sophisticated in ways most people miss.
It acknowledges a fundamental tension in organizations: you need both dissent (to avoid groupthink) and unity (to execute effectively). Most organizations fail at one or both:
- Too much harmony → nobody challenges bad decisions → strategic drift
- Too much conflict → nothing ever gets decided → organizational paralysis
“Have Backbone; Disagree and Commit” attempts to resolve this by temporally separating dissent and unity:
- Before decision: strong obligation to voice disagreement, even when uncomfortable
- After decision: strong obligation to commit fully, even if you disagreed
This works only if the culture actually protects dissenters from punishment. If disagreeing with your manager hurts your career, the principle becomes a tool for enforcing conformity under the guise of “disagreement.”
Whether Amazon achieves this in practice is debatable. But the principle itself reflects genuine wisdom about organizational decision-making.
The Dangers of Measurable Objectives
Here’s the darker side of Amazon’s culture: what gets measured gets optimized, and what doesn’t get measured gets ignored or actively degraded.
Sunghee’s $207 million revenue increase is measurable, reportable, and promotable. It’s an optimization success story.
But Amazon’s culture also produced:
- Warehouse workers pushed to physical limits by algorithms optimizing productivity
- Delivery drivers surveilled constantly, penalized for bathroom breaks
- Third-party sellers exploited by algorithms identifying successful products to copy
- Communities destroyed by tax avoidance strategies optimizing shareholder returns
These aren’t bugs in Amazon’s culture. They’re features. When customer obsession means “give customers what they want at the lowest price,” and everything else is subordinate to that objective, you get both $207 million revenue increases and warehouse workers peeing in bottles because bathroom breaks hurt productivity metrics.
The PR/FAQ process that prevents wasteful technology projects doesn’t prevent exploitative labor practices—because those practices are optimization successes given Amazon’s stated objectives.
This is the tyranny of metrics that Sunghee encountered at Samsung and Amazon: organizations become extraordinarily good at optimizing what they measure, and extraordinarily indifferent to what they don’t.
The Survivor Bias in “Having Options”
Sunghee describes having four career options as a curse. But let’s acknowledge: having four attractive options is an extraordinary privilege that results from decades of compound advantages.
His mathematical foundation from Boyd. His optimization expertise from Samsung. His ML skills from self-study. His $207 million success at Amazon. His integrity demonstrated ten years earlier on the DRAM project. All of these created the conditions where multiple prestigious institutions wanted to hire him.
Most engineers face different constraints:
- Visa status limiting mobility
- Family health insurance tied to current employer
- Student debt requiring steady income
- Lack of credentials that prestigious institutions require
- No network of people vouching for their character
For them, “having options” isn’t a curse—it’s an impossible dream.
This doesn’t diminish Sunghee’s genuine anguish over the decision. Choosing between good options is genuinely difficult. But it’s a privileged difficulty that most workers never experience.
The question an anthropologist asks: what systemic conditions make this kind of privilege accessible to some and unavailable to others? And are those conditions just?
The Hidden Cost of “Ownership”
Sunghee mentions that during COVID work-from-home, Amazonians worried about work-life balance because boundaries blurred. He attributes this to Amazon’s cultural principles like “Ownership” and “Deep Dive”—strengths taken to extremes.
But anthropologists recognize this differently: as the privatization of social reproduction.
When Amazon cultivates a culture where dedicated employees work through dinner, answer emails at midnight, and check Slack on weekends, they’re not just getting more labor per employee. They’re externalizing the costs of that labor onto families.
Who picks up kids from school when both parents are in back-to-back meetings? Who cooks dinner when “ownership” means working until the problem is solved? Who maintains relationships when “customer obsession” means customers always come first?
Usually: women, disproportionately. The invisible labor of social reproduction that makes intensive corporate cultures possible falls heaviest on those already doing unpaid care work.
Amazon’s culture succeeds partly because it can assume employees have other people handling the life logistics that Amazon’s demands make impossible to handle yourself.
This isn’t a critique of Sunghee, who clearly cares about his family. It’s a structural observation: cultures of intense dedication work only by externalizing costs onto families, partners, and particularly women who disproportionately handle domestic labor.
What the “$207 Million” Doesn’t Measure
The $207 million revenue increase is real, measurable, impressive. It represents genuine value creation—customers finding products they want more efficiently.
But here’s what it doesn’t measure:
- The psychological manipulation embedded in the algorithm (exploiting cognitive biases)
- The environmental cost of increased consumption
- The labor conditions in warehouses fulfilling those orders
- The small businesses destroyed by Amazon’s market power
- The privacy surrendered by customers tracked through every interaction
- The algorithmic bias potentially directing different products to different demographic groups
These aren’t hypothetical concerns. They’re real costs that don’t appear in the revenue calculation because they’re externalities—borne by people and systems outside the optimization objective. A truly comprehensive accounting of the algorithm’s impact would need to measure not just revenue but total welfare across all stakeholders: customers, workers, communities, environment, society.
But that’s not how Amazon measures success. And it’s not how Sunghee’s performance was evaluated. This is the gap between micro-optimization (make this algorithm better) and macro-assessment (is this system creating net good in the world).
The Conservative Radical
I’m fascinated by Sunghee’s self-description as “quite conservative” despite seeming rebellious at Samsung and Amazon.
He’s right that he’s conservative in important ways:
- Won’t join startups (until he did)
- Prioritizes family stability
- Prefers established institutions
- Values proven fundamentals over trendy techniques
But he’s also genuinely radical:
- Defying team politics to work on what matters (DRAM project)
- Choosing customer value over local incentives
- Leaving secure positions for uncertain opportunities (Stanford, Amazon, Gauss Labs)
- Constantly learning new fields rather than specializing safely
The resolution: Sunghee is conservative in values but radical in pursuit of those values. He won’t chase trends or take foolish risks. But when his conservative principles (integrity, excellence, and service) conflict with conservative institutions (Samsung’s team politics, and Amazon’s metrics), he’ll risk the institution to preserve the principles.
This is a particular kind of integrity that’s both admirable and rare: the willingness to be uncomfortable, to take risks, and to defy convention—not for self-aggrandizement but in service of principles you genuinely believe in. Most people optimize for comfort and conformity. Sunghee optimized for a strange combination: conservative values pursued through sometimes radical means.
The Mathematics of Career Decisions
Finally, consider the decision itself: four options, six months of agony, and ultimately choosing the riskiest path.
This can’t be optimized mathematically. There’s no objective function that captures:
- professional growth vs. family stability
- prestige vs. impact
- safety vs. meaning
- short-term comfort vs. long-term fulfillment
These involve incommensurable values that can’t be reduced to a single metric. This is precisely where optimization fails—where human judgment, values, and perhaps courage are required.
The fact that the “right” choice (Gauss Labs) wasn’t obvious even to someone with Sunghee’s analytical capabilities tells you something important: the most consequential decisions in life resist optimization.
You can optimize your recommendation algorithm. You can optimize your test automation. You can even optimize your career within a chosen path. But choosing the path itself? That requires something optimization can’t provide: wisdom, courage, and the ability to live with irreducible uncertainty.
That’s the gap this book keeps revealing: between the power of optimization for well-defined problems and its inadequacy for the most important questions we face. Understanding where optimization works is engineering. Understanding where it fails is wisdom.
Chapter 4: Gauss Labs — Industrial AI and the Bayesian Reality Check (2020-2023)
- Co-founding SK Group’s first AI company: The Silicon Valley-Korea bridge
- When Bayesian methods outperform deep learning: Real examples from manufacturing
- Why “AI transformation” promises often fail: The gap between demo and deployment
- Building AI for real factories, not PowerPoint presentations
- [Anthropological lens: The clash between innovation rhetoric and operational reality; the human element in “smart” factories]
Chapter 5: Erudio Bio — AI Meets the Complexity of Life (2023-Present)
- From circuits to cells: Why biotech is AI’s next frontier
- AlphaFold, Bio-TCAD, and the data scarcity wall in medicine
- Fighting cancer with AI-powered biomarker discovery
- The Gates Foundation grant: Validation and responsibility
- [Anthropological lens: The culture of medicine, the ethics of AI in healthcare, and who benefits from biological breakthroughs]
Interlude: The Pattern Emerges
A reflection on what these five stages reveal about AI’s real capabilities and limits
PART II: DEMYSTIFYING AI — What It Is, What It Isn’t, and What It Means
Subtitled: The Truth Behind the Hype (And Why It Matters)
Chapter 6: What LLMs Actually Do — The Conditional Probability Truth
- Opening the black box: Transformers, attention mechanisms, and pattern completion
- The Tom Cruise’s mother example: Why LLMs don’t truly “know” anything
- Why ChatGPT can sound smart without understanding a single word
- The architecture of illusion: How statistical correlation mimics comprehension
- [Anthropological lens: Why humans are so easily fooled by linguistic fluency; the anthropomorphization trap]
Chapter 7: AI Cannot Believe, Reason, Know, or Think
- The philosophical precision we need: Defining knowledge, belief, reasoning
- Why “chain of thought” is pattern matching, not reasoning
- The consciousness question: Category errors in the AI debate
- Mozart’s birthplace and the soul AI cannot touch
- [Anthropological lens: Cultural constructions of intelligence, consciousness across societies, and why Western categories may mislead us]
Chapter 8: The Hallucination Problem — Not a Bug, a Feature
- Why LLMs hallucinate: It’s baked into the architecture
- Confidence without knowledge: The most dangerous combination
- Real examples from high-stakes applications (healthcare, legal, financial)
- Can we fix it? Technical and philosophical limitations
- [Anthropological lens: Truth, trust, and authority in the age of confident AI misinformation]
Chapter 9: AI Fairness, Bias, and the Inequality Accelerator
- The Salzburg Global Seminar: Technology, growth, and inequality
- Why AI systems inherit and amplify human biases
- Facial recognition, hiring algorithms, and systemic injustice
- The Hamburg Declaration and global governance challenges
- Who benefits from AI advancement? Who pays the cost?
- [Anthropological lens: Power structures, technological colonialism, and whose values get encoded into “neutral” systems]
Chapter 10: The Energy Crisis Nobody Talks About
- LLMs’ staggering energy consumption: The invisible cost
- Why Sam Altman wants trillions and nuclear fusion
- Liquid Neural Networks and the efficiency imperative
- Sustainability vs. scale: Can we have both?
- [Anthropological lens: Modern society’s relationship with energy, growth ideology, and the mythology of limitless progress]
Chapter 11: Why Digital Transformation Fails — The Human Factor
- The 70% failure rate: Why most AI projects don’t deliver
- Technology vs. culture: When algorithms meet organizational reality
- The “not invented here” syndrome and other human resistances
- Change management, training, and the soft skills nobody teaches engineers
- Real stories from Samsung, Amazon, and Gauss Labs
- [Anthropological lens: Organizational culture, power dynamics, resistance to change, and the rituals that shape technology adoption]
Chapter 12: Data is Destiny — The Real Competitive Advantage
- Why models are commoditizing but data isn’t
- RAG, vector databases, and domain-specific knowledge
- The future belongs to those who organize knowledge, not those who build bigger models
- Building data moats in the age of AI agents
- [Anthropological lens: Knowledge as cultural capital; who owns information in digital societies]
Chapter 13: Multi-Agent AI — The Next Paradigm
- From single models to agent societies
- Collective intelligence vs. monolithic systems
- Privacy-preserving AI and the K-PAI vision
- Real applications: Where multi-agent systems shine
- [Anthropological lens: Parallels to human social organization; what agent cooperation reveals about collective intelligence]
Chapter 14: The Healthspan Revolution — AI’s Most Important Application
- Why living longer isn’t enough: The healthspan challenge
- Erudio Bio’s mission: From cancer detection to health asset management
- AlphaFold, personalized medicine, and biological breakthroughs
- The ethical imperative: Ensuring access for all
- [Anthropological lens: Cultural attitudes toward aging, death, health across societies; medicalization and its discontents]
Chapter 15: The Future We Choose — Technology, Wisdom, and Values
- AI that amplifies human capabilities, not replaces human agency
- The Rhône River reflection: Technology carrying human values forward
- What the next generation of entrepreneurs should build
- Bridging Silicon Valley innovation and global equity
- The irreplaceable value of human creativity, consciousness, and wisdom
- [Final anthropological reflection: What makes us human in an age of intelligent machines; cultural evolution and technological change]