[HN Gopher] On The Need For Understanding
       ___________________________________________________________________
        
       On The Need For Understanding
        
       Author : zdw
       Score  : 59 points
       Date   : 2026-03-12 00:53 UTC (4 days ago)
        
 (HTM) web link (blog.information-superhighway.net)
 (TXT) w3m dump (blog.information-superhighway.net)
        
       | abstractspoon wrote:
       | I can't imagine programming without understanding aka vibe
       | coding. Hence I will never vibe code.
        
         | amelius wrote:
         | -- me, two months ago
        
           | kykat wrote:
           | After vibe coding: I can't understand how I could deal with
           | coding before.
        
         | avilay wrote:
         | The two don't have to be mutually exclusive. You can let the
         | agent code and you review it, or vice versa. No different from
         | being a team lead where you don't write all the code, or even
         | review each and every line of code, but you have a very firm
         | grasp of the code base.
        
           | em-bee wrote:
           | on the contrary, reviewing LLM code and human code is very
           | different. LLMs don't learn. if a human makes a mistake i can
           | teach them to avoid that mistake in the future. if an LLM
           | makes a mistake, all i can do is fix it over and over again.
           | the dynamics are fundamentally different. some people may
           | prefer to work with a machine, but i don't, i prefer to work
           | with humans.
           | 
           | for me this is similar to the difference of using FOSS vs
           | closed source software. if there is a problem on my linux
           | machine, i can potentially fix it, on windows or mac i just
           | can't.
           | 
           | both closed source software and working with LLMs make me
           | feel helpless. whereas using FOSS or working with humans is
           | empowering.
           | 
           | i get that not everyone feels that way, and that's fine. for
           | my part i'll just stay away from LLM generated code.
        
         | zby wrote:
         | What do you do to learn new programming construct? What did you
         | do to learn programming - didn't you write
         | #include <stdio.h>            int main() {
         | printf("Hello World");         return 0;       }
         | 
         | while having no idea what 'stdio.h' is?
        
           | irishcoffee wrote:
           | Choosing not to know what stdio.h means is willful ignorance,
           | an LLM has little to do with said chosen ignorance, that is a
           | choice because "hey it works on machine!" and when I pushed
           | it, nobody seemed to mind.
           | 
           | What a time to be alive. Actively choosing to rebuke
           | knowledge because "what the fuck does it matter anyways"
        
           | nice_byte wrote:
           | no. it was the first question I asked and was given a
           | satisfactory explanation (along the lines of, "this adds
           | things to your program that help it write text to the
           | screen.")
        
             | Almondsetat wrote:
             | That's not even remotely satisfactory if we're talking
             | about understanding what we're doing
        
           | bitwize wrote:
           | Funny you should mention hello world. Kernighan and Ritchie
           | presented it in TCPL as a little anatomical diagram of close
           | to the smallest possible functional C program with the
           | different parts labelled. The first line is labelled "include
           | information about the standard library". What this means in
           | detail is explained in that chapter. Furthermore, if you were
           | compiling on a Unix system, stdio.h was readily available as
           | /usr/include/stdio.h. Curious people could open it up using
           | more or vi and see what was inside. There was no shortage of
           | curious people back then.
           | 
           | The process of "going through the motions" of writing and
           | compiling a program without even a small understanding of
           | what it all meant was a later innovation, perhaps done as a
           | classroom exercise in an introductory CS course for impatient
           | freshmen or similar.
        
       | tines wrote:
       | In the world that the AI bros want for us, understanding has
       | become a hobby.
        
         | awesome_dude wrote:
         | The problem with that is - AI isn't a developer.
         | 
         | By that I mean, it's fabulous for taking the input I give it,
         | processing it, and returning a collection of tokens that it has
         | found in its training data that do what is being asked.
         | 
         | It's regurgitating fragments of prior work - I have zero
         | complaint about that, just as a developer you now need to
         | understand what those fragments combined do, and whether that
         | really fits with your actual desire - or not.
         | 
         | To put it into old people's terms "You got the answer from
         | Stack Overflow? Was that the code from one of the answers....
         | or the question?"
        
         | markus_zhang wrote:
         | Yep. It is a luxury. Nowadays I use AI for work, and my
         | productivity increases. However, I don't learn much from the
         | tasks, because I get more tasks since the team went down half
         | size. Understanding is a luxury now.
        
       | awesome_dude wrote:
       | Interesting piece - reading it I found myself skimming, the point
       | being made was being made repeatedly, albeit showing that as the
       | author grew as a developer so did the complexity of the software
       | they were using.
       | 
       | There was one thing that screamed in my head, though, whilst
       | reading it, was, yes we can have a look at the library being
       | used, read the code, and understand what its actually doing (this
       | is one of the reasons I like Go so much, no matter who the
       | upstream author is it's generally clear what they're doing
       | [caveat: there are always going to be authors that obfuscate the
       | f*ck out of code, no matter the language], the one thing, though,
       | is systems like Netflix, hundreds of microservices running
       | together in ways that people have NFI what it's all doing.
       | 
       | It just doesn't fit into one person's head anymore.
       | 
       | So, a single head can manage the data pathways for some subset of
       | the system overall, and they might even get right down to the
       | metal, the sheer size of the system means they only have a
       | partial view, and abstractions (in the form of C4 diagrams) only
       | show how complex the beast has become.
        
         | xg15 wrote:
         | > _It just doesn 't fit into one person's head anymore._
         | 
         | True, but I think it doesn't have to, at least not everything
         | at the same time.
         | 
         | You can still usually understand the ins and outs of a specific
         | component/service/module/etc with some time - e.g. if you have
         | to develop or maintain that component.
         | 
         | Alternatively, you can also try to understand certain data or
         | action paths throughout all components of the system - that's
         | what OP did with the layout bug: They were trying to understand
         | how Android's relayouting logic worked, so they managed to get
         | a mostly complete picture of all the pieces that are involved
         | in that specific functionality. But they probably didn't bother
         | to learn the rest of Android's UI renderer or other unrelated
         | components with the same thoroughness.
         | 
         | I think this kind of "selective understanding" where make
         | conscious decisions which parts you want to understand and
         | which you treat like a semi-predictable black box works well in
         | practice.
        
       | dabedee wrote:
       | It's pleasant to read an article that genuinely seems written by
       | a person; warts and all. It doesn't matter that it repeats some
       | of its points. Actually maybe that's the point. I hope more
       | people try this.
        
       | Karrot_Kream wrote:
       | I think as an industry LLM assisted programming is largely
       | amplifying an existing gap: commercial software is often under
       | much higher speed constraints and much lower correctness
       | constraints than the sorts of software that can be created by
       | deeply understanding a software system.
       | 
       | Obviously this depends on the industry; aviation software that
       | runs in regulated environments is probably under even _higher_
       | correctness constraints than that which Sussman discusses.
       | Accounting software too needs to balance books correctly or risk
       | fines. But most software needs to be mostly correct. New features
       | and better UX is more useful for the users of many systems than
       | fixing tail frequency bugs.
       | 
       | Personally I do hobby code on systems I understand from scratch.
       | Writing for older, well documented retro hardware for example is
       | very fun. Writing things from simple abstractions is also fun.
       | But my speed in doing this is something I know is not
       | commercially viable and that's fine by me.
       | 
       | Many fields have a commercial aspect of them that has a much
       | lower quality bar and a much higher output speed bar than their
       | hobby equivalents. Wedding photography, voice acting, the
       | quotidian demand for these things is far lower than appreciating
       | an Ansel Adams piece in a museum.
        
       | 01HNNWZ0MV43FF wrote:
       | The Android example is a bummer. After this many years and
       | generations of GUI frameworks, you should not have to experiment
       | nor dig into source code to learn how to do something as simple
       | as laying out your widgets.
       | 
       | The docs should have examples for that kind of thing.
        
       | matt_daemon wrote:
       | There are a few emotional trigger points that LLMs seem to cause
       | in programmers and this is a common one -- the need for deep,
       | first-principles understanding that LLMs make obsolete.
       | 
       | One thing that gets me in a lot of pieces like this is they kind
       | of assume people have no agency, that now that these tools exist
       | we won't be able to help ourselves but use them despite our
       | better judgement.
       | 
       | The broader topic which I don't see discussed so much are
       | _values_. If you value deep understanding, well you should
       | continue programming and learning in such a way. In some cases
       | you may just want to use a language model to spin up a quick tool
       | or PoC. And there is an entire grey area in between. It 's a
       | value judgement to decide what you use LLMs for, as much as what
       | you don't.
        
         | p1necone wrote:
         | Idk, as someone who has done LLM driven development of fairly
         | complex things (type systems, memory allocation gymnastics etc)
         | I don't think the need to understand what's going on from first
         | principles has really gone away. If I just want some isolated
         | thing to work I can vibe code with no understanding, but
         | there's no way to get coherence between behaviour, performance
         | characteristics, purity etc without fully understanding the
         | problem space. The LLM just saves (a shitload) of time on grunt
         | work.
         | 
         | Of course if you're building some crud app it's all already
         | tread ground, and you probably can just throw a prompt at an
         | LLM and get something acceptable out.
        
           | hnthrow0287345 wrote:
           | >Of course if you're building some crud app it's all already
           | tread ground, and you probably can just throw a prompt at an
           | LLM and get something acceptable out.
           | 
           | This is what I think most people who haven't had boring CRUD
           | jobs just don't get - the impact of having some deep
           | technical knowledge goes to waste if all you're struggling
           | with is dumb stuff like bad database design and basic
           | security vulnerabilities everywhere. This was all done by
           | people who are no longer there and were just in it for the
           | paycheck. But also no one who is good is doing these jobs
           | because the pay is too low compared to what they can get.
           | 
           | I'm sure all of this is true if you are teaching at MIT or
           | are working anywhere near people who have gone there though.
        
         | keybored wrote:
         | Feelings aside[1], a large part of it is about having
         | management above you. Take that plus the ever-present online
         | nagging about productivity. If the _latter_ is true then, well,
         | it's not like there is a choice.
         | 
         | [1] https://news.ycombinator.com/item?id=47362178
        
       | andai wrote:
       | This article helped me understand something I've been grappling
       | with for a while.
       | 
       | I've been looking for the optimal game development environment
       | for a while.
       | 
       | That basically boils down to having batteries included. (I have
       | the opposite of Jonathan Blow's situation, I need to be able to
       | get up and running in a few hours for game jams.)
       | 
       | But there seems to be this tension between convenience and
       | control. Either APIs are low level or they are high level.
       | 
       | (A notable exception is the canvas API, which leaves both groups
       | dissatisfied :)
       | 
       | The article basically made me realize, those are basically two
       | separate groups of people. There's people who want total
       | understanding and total control. And there's people who want to
       | Do Thing With Computer.
       | 
       | I am not sure if it's possible to design one system they would
       | both be happy with.
       | 
       | But that made me realize, I had the same idea about GUIs 20 years
       | ago.
       | 
       | On Mac you usually don't get many options. On Windows you usually
       | get too many options.
       | 
       | A rare few applications let you switch between two modes. "Just
       | Do Thing" and "airplane cockpit". There's usually a gear icon or
       | something like that which shows you all the extra options.
       | 
       | I wonder what that might look like for an API.
        
       | keybored wrote:
       | I was relieved to read (skim) through all of that without it
       | reaching some LLM conclusion like, "of course we have a better
       | vantage point to understand now than thirty years ago... the LLMs
       | can understand for us".
        
       ___________________________________________________________________
       (page generated 2026-03-16 23:00 UTC)