Syntax, Struggle, and Expertise

A follow-up to Review-First Programming

For decades, programming expertise came out of syntax struggle: write it, break it, fix it, repeat. LLMs just tore that pipeline out of the wall. Nobody knows what gets built in its place.

What the Struggle Was For

A developer who spent three hours debugging a busted list comprehension walked away with a lot more than bracket placement. That time bought pattern recognition, the sense of when to think in transformations instead of loops, plus a gut feel for what a given construct costs in memory. Every breakage fed a mental model of how things fail. The idioms soaked in too, one embarrassing code review at a time. The friction itself did the teaching. For most of us, learning Python syntax and learning to think in Python were the same activity, because the struggle was the mechanism.

What LLMs Knock Out

LLMs eliminate that whole training pipeline. A developer who prompts their way to a working list comprehension may never build the pattern recognition that came from writing and breaking a few hundred of them by hand. Which leaves a genuinely open question. Can review-first development build the same expertise that write-first development did?

I want to believe it can. Film directors who can't operate a camera still develop visual judgment by reviewing take after take, and plenty of editors learned narrative structure from other people's drafts without ever beating the blank page themselves. Maybe reviewing thousands of LLM-generated functions builds better pattern recognition than hand-writing hundreds ever did, especially since the learner gets to put everything into architectural judgment while the syntax is handled somewhere else.

Maybe It Was Never About the Syntax

My pet theory is that the expertise lived in the ability to articulate intent all along, and syntax was just the transcription. When you write if x is None instead of if x == None, the operative knowledge is the concept "check identity, not equality." That concept already lives in English, in your comments, variable names, test descriptions, and PR threads. Call it the English layer wrapping the code.

If that's right, the training pipeline inverted. You used to struggle with syntax until mental models formed and hardened into muscle memory. Now you articulate the understanding in a prompt and check whether the LLM translated it faithfully. The mental models come from the mismatches.

LLMs might even be the better teachers here, because they force explicit articulation. Telling one "check identity, not equality" is clearer than typing is from habit. The prompt documents itself. The concept transfers too: it means the same thing in JavaScript or Go, while the bracket-level knowledge was always trapped inside one language.

There's a catch, and it's a big one. This only works if you already know identity and equality are different things. Whether you can learn that distinction from prompting and review, or whether you have to earn it by making the wrong choice and debugging the fallout, is exactly what nobody knows yet.

The pessimist's rebuttal stings. The film directors in my analogy mostly trained behind a camera before they earned the review chair. Maybe expertise has to be built through struggle even if it's later exercised through review. We're running an uncontrolled experiment on an entire generation of developers, and some of them are going to plateau at surface-level pattern matching without ever knowing what they missed.

Where You Still Can't Fake It

Even if review-first development works out, some contexts still demand syntax knowledge in your own head. Reviewing authentication logic without knowing that Python's is checks identity while == checks equality is malpractice, because the LLM will happily hand you syntactically perfect, semantically dangerous code.

Performance work is the same story. A list comprehension materializes an entire new list while a generator expression streams its values, and when the input is measured in gigabytes, that syntax choice is the performance characteristic.

Then there's corrupted output. Anthropic's September 2025 postmortem described infrastructure bugs that corrupted Claude's tokens: right syntax, wrong characters. Catching that took developers who knew what valid code should look like.

Legacy systems round it out, since interfacing with code written before LLMs means reading syntax no model will read for you. That one can't be delegated.

So syntax knowledge lands in a strange spot. You barely need it to generate code anymore, yet verification leans on it harder than ever. And fewer people are building it. Assembly programming went through the same squeeze decades ago: rarely needed, irreplaceable when it is.

Perfect Syntax, Wrong Program

Recent studies map exactly where "perfect syntax" fails. A November 2024 analysis of GPT-4 and Gemini found seven categories of non-syntactic errors, the mistakes that survive flawless syntax. Conditional logic that drops edge cases inside perfectly formed if-statements, and semantic misalignment, like implementing addition when the prompt asked for XOR. Averages computed as (n+m+1)//2 instead of (n+m)/2. Confident calls to methods that don't exist. Deprecated APIs, like reaching for Azure's old OpenAIClient instead of AzureOpenAIClient (February 2025).

A September 2024 study that analyzed 12,837 errors found AssertionError to be the most common failure. The code compiles and runs. It just returns the wrong answer.

GPT-4 posts the highest overall accuracy of the models studied and the largest deviations when it misses. Fixing its mistakes means substantial logical revision. A syntax tweak won't save you. Catching these failures takes exactly the expertise syntax struggle used to build, a deep sense of what the code should do.

The Honest Uncertainty

The old path built expertise reliably and slowly, four decades of write, struggle, learn, master. Whatever the prompt-and-review loop builds, it builds fast, and we don't yet know whether it's the same expertise or a different capability wearing its clothes. Maybe review-first development produces architects who think in systems. Or it produces developers who can't debug past the first stack frame because the muscle memory never formed. Probably both, depending on the person and how they use the tools.

This is both the power and the risk of review-first programming. LLMs took over syntax generation, which frees developers to concentrate on architecture and verification, but that concentration draws on expertise that used to get built through syntax struggle. Unless the English-layer theory is right, and articulating "check identity, not equality" builds a cleaner conceptual model than reflexively typing is ever did. Then the kids come out ahead of us.

Can expertise grow from explicit articulation and verification the way it grew from struggle and discovery? Does "explicit from the start" go as deep as "discovered through pain, then made explicit"? We're finding out.