On learning programming in an age of LLMs
15 points by abareplace
15 points by abareplace
I find reading the dialogue between a vibecoder and an experienced programmer interesting and useful. Particularly when both parties are of high quality like here.
My first thought on this was … beware what you ask an AI to build, because something will be built, but it might not be the right thing.
The statement that “programming may be a discipline where verification is easier” is often claimed and is true for transformational systems, but not for representational systems - where some external system is being modeled.
The author’s statement “I prefer asking LLMs falsifiable questions” is worthwhile and notable, but not always easy!
The part about "falsifiable questions" explains why AI code reviews are usually okay and AI-generated code is not. It's relatively easy to check if a bug described by LLM exists, but (as you already said) it's hard to verify behavior of a complex vibecoded program.
It comes down to the complexity of specification and reusability. A bounded component providing specifiable behavior (even as traditionally difficult to get right as concurrent behavior) is a great candidate for agent synthesis because verification with the assistance of an agent is much cheaper than building it oneself and then still having to verify it.
The more you’re modeling something that cannot be decomposed into such simple components the harder it is to have an llm get it right. That said, I think as a whole we make insufficient use of explicit finite state machines to understand business processes (I think because it’s an unfamiliar style that feels clumsy), and those are fairly simple to specify whether or not the code is written explicitly to encode the state machine.
I suspect a rather different introductory education in computer science and software engineering than we have it now can make people productive with LLMs.