Skip to content
Published on

The Joy of Understanding — Why Deep Understanding Still Matters in the LLM Era

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

Introduction — Why This Story Now

Throughout 2026, GeekNews and Hacker News kept surfacing posts of the same sentiment. The core can be summarized like this: "In an era where LLMs write code for us, do we actually understand anything, or are we just transcribing answers?"

A post by a developer (binaryigor) on "the joy of understanding" struck a particular chord. The gist is simple. Search and LLMs give us instant answers, but truly understanding those answers is a separate matter, and that understanding is the very joy of engineering and the source of its power.

Why this argument resonates now is clear. As AI coding tools became ubiquitous, we can reach "working code" faster than ever. But at the same time, the risk grew that we understand less and less why that code works. Code that works but is not understood. This is a new form of debt the 2026 engineer faces.

This article is not a Luddite manifesto to reject LLMs. Rather, it is about how to use a powerful tool like the LLM without losing depth of understanding, and why that depth still matters decisively. We cover, in turn, the value of seeing beneath abstractions, the difference understanding makes in debugging, understanding as learning, and the balance of when it is fine to confidently lean on abstractions.

What is interesting is that this sentiment spread not among LLM skeptics but rather among the people who use LLMs most actively. The more deeply someone has used a tool, the more sharply they feel what it gives and what it takes away. Only after having fully enjoyed fast answers does one realize there is something that answers alone cannot fill. That is also where this article begins.

Answers and Understanding Are Different

The Trap of Fast Answers

First, let us distinguish "answer" from "understanding." They look alike but are entirely different.

  Answer                      Understanding
  -------------------         -------------------------
  - instant                   - takes time
  - copyable                  - transferable (applies to other problems)
  - works on the surface      - you know why it works
  - useless if context shifts - reconstructable if context shifts
  - given by search/LLM       - you must build it yourself

Answers are highly volatile. When the same problem returns, someone who only got the answer must search again. By contrast, someone who understood can reproduce that answer and, more importantly, apply that understanding to slightly different problems.

The risk in the LLM era is that as the cost of reaching an answer drops to near zero, the temptation to skip understanding is maximized. Previously, some understanding got mixed into the very process of finding an answer. Reading docs, following examples, failing along the way, we inevitably understood a little at a time. But the LLM compresses that whole process. Ask, and working code comes out. You arrive at the destination without taking the detour called understanding.

Code That Works But Is Not Understood

A new kind of code emerges here: "code that works but its author does not understand." This differs even from copied code. At least when copying from Stack Overflow, you had to judge, even briefly, "does this answer fit my problem?" Because the LLM generates code tailored to your context, it reduces even the need for that judgment.

The problem with such code does not show in normal times, because it works. The problem always bursts at boundary conditions: under load, when input deviates from expectation, when a dependency updates. At that point, we become strangers before the code we ourselves wrote.

The Value of Seeing Beneath Abstractions

Abstractions Lie

Software is a tower of abstractions. We call a function, that function calls a library, the library calls a system call, the system call descends to the kernel, the kernel to the hardware. Each layer hides the complexity of the one below. This is the blessing of abstraction.

But there is a famous maxim: "All non-trivial abstractions, to some degree, are leaky." Abstractions normally pretend to perfectly hide the layer below, but at decisive moments that lie is exposed.

   your code
       |
   [ ORM ]            <- "just saving an object"
       |
   [ SQL ]            <- actually a query is generated (N+1 problem!)
       |
   [ index/planner ]  <- actually a full scan happens
       |
   [ disk I/O ]       <- actually random I/O slows it down

The ORM says "just saving an object," but beneath it SQL is generated, an index is or is not used, and disk I/O occurs. When a performance problem bursts, someone who only knows the ORM abstraction is stuck. By contrast, someone who understands the SQL and indexes below can look into the crack of the leaked abstraction and fix the problem.

The Compounding Effect of Knowing One Layer Down

Understanding deeply does not mean knowing everything. Usually it is enough to know "one layer beneath the abstraction you use every day." And this "one layer down" knowledge compounds.

  • If you use a web framework, know one layer beneath HTTP (request/response, headers, status codes).
  • If you use an ORM, know SQL and indexes.
  • If you use containers, know Linux namespaces and cgroups.
  • If you use a garbage-collected language, know memory allocation and how the GC works.

Understanding each layer just one step deeper means you will not panic the moment an abstraction leaks. And these understandings link together, growing over time into an intuition for the whole system. This is the compounding of understanding.

The Five Levels of Understanding — From Copying to Creating

Same Code, Different Depths

"Understanding" is actually not one thing. Even for the same code, people differ in how deeply they understand it. Splitting it into five levels is a good way to check where you stand.

  Level 5: Create   - you can apply/adapt this pattern to a new problem
  Level 4: Evaluate - you can critique this code's weaknesses and alternatives
  Level 3: Explain  - you can explain to others why it works this way
  Level 2: Trace    - you can follow how input turns into output
  Level 1: Copy     - you can grab working code and paste it

The LLM instantly lifts us to Level 1 (Copy). Working code lands in your hands at once. But the real value comes from Level 3 and above. You must be able to explain to debug, to evaluate to reject the LLM's suggestion, and to create to solve a new problem.

A Concrete Example — The Debounce Function

Take a common debounce function as an example.

// debounce — actually runs only after a set time passes since the last call
function debounce(fn, delay) {
  let timer = null;
  return function (...args) {
    clearTimeout(timer);
    timer = setTimeout(() => fn.apply(this, args), delay);
  };
}
  • Level 1 (Copy): you paste this code and are satisfied when it works.
  • Level 2 (Trace): you follow the flow where, when calls arrive in a row, the timer is canceled and reset each time.
  • Level 3 (Explain): you explain why the timer must be enclosed in a closure, and why apply preserves this.
  • Level 4 (Evaluate): you point out the weakness that there is no immediate-execution option (leading edge) and the limit that there is no cancel method.
  • Level 5 (Create): you build a throttle yourself from the same closure principle and explain the difference between the two patterns.

The LLM can instantly give you Level 5 code too. But if you cannot take that code and evaluate it at Level 4, you end up using it without even knowing whether it fits your situation. Raising your level of understanding is also a way to use the LLM better.

Debugging — The Moment Understanding Is Revealed

Two People Diverge Before an Outage

The moment the value of understanding shows most dramatically is an outage. 3 a.m., production is down. The logs are vague, and the error message comes only from the top layer of abstraction. Here two kinds of engineer diverge.

The engineer who only collected answers pastes the error message straight into the search box or LLM. If lucky, a similar case appears; if not, it does not. This person, lacking a mental model of the system, can hardly even judge whether the search result fits their situation.

The engineer who understands is different. They hold a mental model of the system in their head. "If these are the symptoms, it is here or there. To rule out one of them, I look at this log." They form a hypothesis, verify, and narrow down. Even when they use an LLM, it is a tool to verify their own hypothesis, not a substitute for the hypothesis itself.

  Answer-collecting debugging   Understanding-based debugging
  ----------------            -----------------------
  error message -> search      symptom -> mental model -> hypothesis
  paste result -> try          hypothesis -> design verification
  if it fails, search again    narrow hypothesis with results
  depends on luck              systematic convergence

Mental Models Are Not Searchable

The key is this: mental models are not searchable. An LLM can give general knowledge, but the model of "what your system looks like right now" only you can hold. And that model does not suddenly appear in a moment of crisis if you have not understood deeply beforehand.

Outage response is withdrawing from the balance of your everyday understanding. If you only transcribed answers, there is no balance to withdraw in a crisis. If you accumulated understanding, that understanding saves you.

A Short Case — Same Symptom, Different Endings

Let us draw the difference with a concrete hypothetical case. The response latency of some API suddenly grew. The p99, normally 200 ms, shot up to 3 seconds. Two engineers face the same symptom.

  Symptom: p99 latency 200ms -> 3s spike, error rate normal

  [ Path of the answer-collector ]
    1. search "API latency spike"
    2. try generic fixes (add cache, add index)
    3. no effect -> search again
    4. repeat random changes, leave it to luck

  [ Path of the understanding-based ]
    1. mental model: request -> connection pool -> DB -> external API
    2. error rate normal + only latency up -> resource-exhaustion hypothesis
    3. check connection pool usage -> find 100% saturation
    4. cause: external API slowed -> connections held -> pool exhausted
    5. response: shorten timeout + isolate pool (bulkhead)

The difference between the two paths is not the amount of knowledge but the presence or absence of a mental model. The understanding-based engineer suspects resource exhaustion from a single clue, "the error rate is normal but latency alone rose." This inference is possible because they understand one layer beneath the abstraction called the connection pool (what happens when a pool is exhausted). For the answer-collector, this clue is just one more search term.

What is interesting is that the understanding-based engineer also uses an LLM — something like "show me an example of the connection-pool bulkhead pattern." The difference is whether the LLM is used to verify hypotheses and accelerate implementation, or made to stand in for the hypothesis itself. For someone with a mental model, the LLM is an amplifier; for someone without one, the LLM is a crutch.

Control and Ownership — What Understanding Gives

Understanding Is Power

The greatest gift of deep understanding is control and ownership. On code we do not understand, we are always anxious. Every time we try to change something, the fear that "I do not know what this will affect" follows. So we do not touch it, we avoid it, we go around it. The code dominates us.

Conversely, on code we understand, we are free. We can predict the ripple of a change, refactor with confidence, optimize boldly. We dominate the code. This difference is not merely a difference in productivity, but a difference in the agency and joy we feel at work.

Not Being Dragged by Your Tools

In the LLM era, this question of control sharpens. The more powerful the tool, the greater the risk of being dragged by it. If accepting LLM-suggested code as-is repeats, at some point we have handed the steering wheel of our own codebase to the tool.

Not being dragged by your tools does not mean not using LLMs. It means retaining the ability to understand, critique, and if necessary reject what the LLM gives. Receive the suggestion, but be able to judge why it is right (or wrong). That judgment ultimately comes from deep understanding. Without understanding, we have no standard to evaluate the tool's suggestions, and unable to evaluate, we can only follow.

  Dragged-by-tool relation     Tool-wielding relation
  -------------------         -------------------------
  suggestion -> accept blindly suggestion -> understand -> critique -> adopt/reject
  integrate without grasp      integrate on understanding
  helpless on problems         fix it yourself on problems
  hand over the wheel          hold the wheel

Understanding as Learning — The Value of the Detour

The Fast Path Is Not Always the Good Path

Another facet of understanding is learning. The very process of wrestling to deeply understand something grows us. Just transcribing answers misses this growth.

There is a subtle paradox here. The LLM gives the "fast path." But in learning, the fast path is not always the good path. Cognitive science has a concept called "desirable difficulties." Reaching an answer yourself through moderate difficulty produces deeper, longer-lasting learning than receiving the answer instantly.

Getting stuck firsthand, forming hypotheses, being wrong, and finally experiencing the "aha" moment. This detour is exactly what makes understanding. The LLM removing this detour is sometimes a blessing, but in the context of learning it can be a curse.

Intentionally Choosing Understanding

So learning in the LLM era demands intentional choice. Not asking the LLM everything, but choosing to deliberately wrestle with some things yourself.

I propose a practical distinction.

  Fine to leave to the LLM     Must understand yourself
  -------------------         -------------------------
  - familiar boilerplate       - core domain logic
  - one-off scripts            - areas you will debug often
  - repetition in known areas  - basics of a tech you are learning
  - aid to syntax/API recall   - the mental model of the system

In areas you already understand, the LLM becomes an extension of your fingers. Going fast is fine. But for things you are learning for the first time, for the core areas you will handle deeply going forward, deliberately taking the detour to build understanding yourself wins in the long run.

Team-Level Understanding — Beyond the Individual

Understanding Is Not the Individual's Alone

So far we have treated understanding as an individual capability, but on a team understanding becomes a shared asset. If only one person understands a core system, the moment that person goes on vacation or leaves, the whole team stops. This is commonly called the bus factor. A bus factor of 1 means that if one person disappears, the system becomes a maze.

  Bus factor 1 (risky)         Bus factor 3+ (healthy)
  -------------------         -------------------------
  core understanding in one    understanding spread across many
  paralysis when they are away  can cope when anyone is absent
  knowledge only in a head      externalized via docs/pairing
  even the LLM lacks context    a shared mental model exists

In the LLM era this problem can quietly worsen. If everyone works one-on-one with an LLM, code is produced but the team's shared understanding may not grow. Previously, when stuck, you asked the person next to you and knowledge naturally spread; now, asking the LLM traps that conversation inside the individual.

Habits of Externalizing Understanding

So at the team level, the habit of deliberately externalizing understanding becomes important.

[ ] Do you record "why we built it this way" for core systems as docs? (ADRs, etc.)
[ ] In pairing/code review, do you share the mental model, not just the code?
[ ] Do you organize useful LLM conversations so the team can see them?
[ ] Do you identify and spread areas only one person knows (bus factor 1)?

Recording "why we built it this way" matters especially. Code shows "what" it does, but not "why" it was done that way. That "why" is the heart of the mental model, and if it vanishes, a successor can read the code but loses the understanding. A good architecture decision record (ADR) is the surest way to pass understanding on to a future team.

Balance — When It Is Fine to Lean on Abstractions

You Cannot Understand Everything

Balance matters here. Taking "understand deeply" to mean "understand everything down to the bottom" is paralyzing. Modern software is so vast that no one can understand the whole. We must constantly lean on abstractions, and that is not a fault but a necessity.

The question is "when may we stop understanding and trust the abstraction?" I propose a few practical criteria.

  1. Frequency: the more often you meet and debug an area, the more worth understanding it deeply. An area you touch once a year is fine to lean on the abstraction.
  2. Risk: the higher the cost of failure (security, payment, data integrity), the greater the value of understanding.
  3. Leakiness: the more often the abstraction leaks (performance, concurrency), the more worth knowing one layer down.
  4. Centrality: the more it is the core domain of your work, the more you must understand. The periphery may be left to trustworthy abstractions.
                  worth understanding deeply
   high  +----------------------------------+
         | core domain logic | security/pay |
         | frequently debugged| perf bottleneck|
         +----------------------------------+
         | well-known repeat  | one-off script|
   low   | stable library     | peripheral glue|
         +----------------------------------+
            low                        high
                  fine to lean on abstraction

Conditions for Trustworthy Abstractions

There are conditions under which you can confidently lean on an abstraction. A well-made abstraction leaks infrequently, gives a clear signal when it leaks, and is well documented with a community that explains its boundaries. Standard libraries, proven protocols, mature frameworks are this kind. On such abstractions, you need not dig to the bottom every time.

Conversely, newly built internal abstractions, unproven libraries, and frequently-leaking performance boundaries demand deeper understanding. The key to balance is the discernment of "which abstractions may be trusted and which must be doubted," and that discernment itself ultimately comes from experience and understanding.

A Healthy Relationship Between LLM and Understanding — Use It as an Amplifier

Emphasizing understanding does not mean keeping the LLM at a distance. On the contrary, the deeper your understanding, the more powerfully you can use the LLM. The healthy relationship between the two is drawn like this.

  Without understanding        With understanding
  -------------------         -------------------------
  LLM output = final answer    LLM output = draft/hypothesis
  cannot verify -> just trust  can verify -> critique/correct
  the prompt is vague too      can write a precise prompt
  wrong and you do not know    wrong and you notice at once
  the tool drives              you drive, the tool accelerates

The key is that understanding improves both the input and the output of the LLM. On the input side, you must understand deeply to ask precise questions. "Why doesn't this work" draws a far worse answer than "the connection pool seems exhausted, show me the pattern for isolating it with a bulkhead." On the output side, you need understanding to evaluate and correct the answer you receive. That is, understanding does not replace the LLM but is an amplifier that multiplies the LLM's value.

This is why the framing of "understanding vs. LLM" is wrong. The real framing is "understanding + LLM" versus "LLM only." Someone with understanding using an LLM is fastest, and using the LLM only without understanding is most dangerous.

Applying It in Practice — Habits That Build Understanding

Understanding accumulates not through grand resolve but through small habits. It is not about digging into the bottom of an abstraction 30 minutes a day, but about inserting a small bit of friction into your ordinary flow. Just before merging code, just before searching for an error, the single habit of asking in that one moment "wait, why is this so?" makes a big difference over time. Here are methods to practice daily.

[ Look one layer down ]
[ ] Did you understand one layer beneath one abstraction you use every day?
[ ] Did you explain the "why" of LLM-given code yourself at least once?

[ Wrestle yourself ]
[ ] In core areas, did you form a hypothesis before asking the LLM?
[ ] When stuck, did you reason for a bit yourself before getting the answer?

[ Build mental models ]
[ ] Have you ever drawn your system's data flow on paper?
[ ] Do you have a mental model of where to look first during an outage?

[ Verify by teaching ]
[ ] Can you explain what you understood to a colleague? (If not, you do not yet know it.)
[ ] Did you receive the LLM's explanation but restate it in your own words?

I want to emphasize the last item, "verify by teaching." The most certain way to check whether you truly understood something is to try explaining it to someone. Having the LLM explain, and you explaining to the LLM or a colleague, are opposite acts. The former receives an answer; the latter proves understanding.

Common Pitfalls That Block Understanding

Knowing the bad habits is as important as the good ones. Here are common pitfalls that erode understanding.

  Pitfall                     Do this instead
  -------------------------   -------------------------
  move on the moment it works  pause once on why it works
  paste the whole error to LLM read the error yourself, form a hypothesis first
  never doubt the abstraction  occasionally peek one layer down
  use copied code unchanged    rewrite it to fit your context
  pretend to understand        try to explain and find where you stall

What these pitfalls share is that they are "the easy path right now." So willpower alone is hard to resist them with. Instead, making a small ritual is effective. For example, a rule like "LLM-given code gets a one-sentence summary comment before merging" forces a minimum of understanding in the process of writing that one sentence. Understanding grows not from grand resolve but from deliberately designing this kind of small friction.

Pitfalls and a Critical View

This article's argument has counterpoints too. For balance, here they are.

  1. The risk of understanding fetishism: the stance "understand everything deeply," if overdone, harms productivity. In deadline-bound work, digging every abstraction to the bottom can be a luxury. Understanding is not an end but a means to better work.
  2. The intrinsic value of abstraction: abstractions let us stand on the shoulders of giants. If we tried to understand from the bottom every time, humanity would not progress. Productive ignorance is the foundation of collaboration and division of labor.
  3. The illusion of understanding: believing you understood deeply does not guarantee actual understanding. Mental models are often wrong, and a wrong mental model can be more dangerous than none. Understanding must come with humility and verification.
  4. Generational and tool change: high-level-language developers who do not know assembly were once criticized but are now normal. A new generation working atop LLMs may develop a different kind of understanding (system composition, verification, evaluation). Nostalgia of "in our day we understood" should be guarded against.
  5. The risk of denying the understanding-speed trade-off: arguing that deep understanding is always right ignores the countless situations where a fast answer is good enough. Not all code becomes the protagonist of a 3 a.m. outage.
  6. The shelf-life of understanding: even something you understood deeply grows stale as technology changes. If you perfectly understood the internals of a particular framework and that framework disappears, much of that understanding becomes useless. So some understanding is volatile, and we should also consider that the more fundamental the layer (data structures, networking, the OS), the longer-lasting the understanding.
  7. The risk of ignoring individual differences: the generalization that understanding is good for learning does not apply with the same intensity to every person and every context. Some people fit better with getting the fast answer first and understanding it in reverse. "Desirable difficulty," if too great, leaves only frustration. There is more than one way to understand.

These counterpoints are valid and do not contradict the article's core argument. The point is not "always dig deep" but "discern where to dig deep and where to leave it to abstraction, and that discernment itself comes from understanding."

Frequently Asked Questions

Q1. The LLM does it all, so why bother understanding?

In the cases where the LLM "works out well," you do not need understanding. The problem is the cases where it does not work out. When the LLM confidently gives a wrong answer, when it plants a subtle bug, when an outage you have never seen erupts. At those times, understanding becomes the only standard for evaluating and correcting the LLM's output. Understanding is insurance not for the ordinary but for the exceptional.

Q2. Doesn't understanding everything take far too much time?

It does. That is why we say to dig deep into only "one layer down" and the "core areas," not "everything." If you filter by frequency, risk, leakiness, and centrality, the time spent on understanding becomes not infinite but a manageable investment.

Q3. Does the same advice hold for junior developers?

It is even more important for juniors. The early career is the period for building the foundation of mental models. If you depend on the LLM for everything then, the habit of assembling only output without a foundation hardens. The more junior you are, the more deliberately raising the share of wrestling on your own wins in the long run.

Q4. Can't you have both understanding and speed?

In the long run, understanding makes speed. In the short term understanding looks like a cost, but in areas you understand, debugging and changes get much faster, so over time understanding converts into speed. The two are a trade-off in the short term and the same direction in the long term.

Q5. How do you confirm that you "understood"?

Trying to explain it is the most certain way. Explain it to a colleague, or in writing to a blank screen. The point where you stall is exactly the point you have not yet understood. This is also why what is commonly called "rubber duck debugging" is effective.

Conclusion — Preserving the Joy of Understanding

The LLM changes much of engineering. The cost of reaching an answer has dropped dramatically. But answer and understanding are still different things, and what understanding gives — control, ownership, crisis-response ability, and the deep satisfaction felt at work — the LLM cannot give in our place.

To summarize:

  1. Answers are volatile; understanding transfers. The risk of the LLM era is that as the cost of reaching an answer becomes zero, the temptation to skip understanding grows.
  2. Abstractions leak. Just knowing one layer beneath the abstractions you use every day keeps you from panicking in a crisis.
  3. Mental models are not searchable. Outage response is withdrawing from the balance of your everyday understanding.
  4. Understanding gives control and ownership and keeps you from being dragged by tools. To wield the LLM without being dragged needs judgment, and that judgment needs understanding.
  5. But you cannot understand everything. Discerning where to dig deep by frequency, risk, leakiness, and centrality is the real wisdom.

The joy of understanding is not a luxury on the opposite side of efficiency. It is the fundamental ability that lets us remain the subject who wields the tool, and the very reason we love this work. The more powerful LLMs become, paradoxically, the more important it becomes to consciously preserve that joy.

Let me close by proposing one practice. The next time the LLM gives you code, before merging it as-is, ask yourself just one thing: "Can I explain why this code works, and in what cases it breaks?" If you can answer "yes" to this question, going fast is fine. If "no," that is exactly the spot to pause for a moment and build understanding.

This one small question separates those who only collect answers from those who accumulate understanding. And over time, only the person who has kept asking that question can stay calm before a 3 a.m. outage, critique the tool's suggestion, and remain the true owner of their own code. Understanding looks like the slow path, but in the end it is the path that goes the farthest.

References

Discuss on Twitter • View on GitHub