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, do it again. LLMs yanked that pipeline out of the wall, and nobody knows what gets bolted in where it used to be.

What the Struggle Was For

Spend three hours chasing a busted list comprehension and you walk away with more than bracket placement. That time buys pattern recognition, the sense of when to reach for a transformation instead of a loop, a gut read on what a construct costs you in memory. Every breakage feeds a mental model of how things fall over. The idioms soak in too, one mortifying code review at a time. For most of us, learning Python syntax and learning to think in Python were the same activity, because the struggle was the only way any of it went in.

What LLMs Knock Out

LLMs pull that whole training loop out from under you. A developer who prompts their way to a working list comprehension might never grow the pattern recognition that came from hand-writing and wrecking a few hundred. So here's the question I keep circling. Can review-first development grow the same expertise that write-first development did?

I want it to. Film directors who can't operate a camera still develop real visual judgment reviewing take after take, and plenty of editors learned narrative structure hacking through other people's drafts without ever staring down a blank page of their own. Maybe reviewing thousands of LLM-generated functions builds sharper pattern recognition than hand-writing hundreds ever did, since you get to pour everything into architectural judgment while the syntax happens somewhere off to the side.

The English Layer

My pet theory is that the expertise lived in being able to say what you meant all along, and syntax was just the transcription. When you write if x is None instead of if x == None, what you actually hold in your head is "check identity, not equality." That concept already lives in English. It's in your comments, your variable names, your test descriptions, the back-and-forth on a PR. Call it the English layer wrapped around the code.

If that holds, the training loop just turned inside out. You used to wrestle syntax until the mental models formed and set into muscle memory. Now you say the understanding out loud in a prompt and check whether the LLM heard you right. The mental models come from where it mishears.

LLMs might make the better teachers here, since they drag the articulation into the open. Telling one "check identity, not equality" beats typing is out of reflex. The prompt writes its own documentation. And the concept travels. It means the same thing in JavaScript or Go, where the bracket-level knowledge stayed locked inside one language its whole life.

There's a catch, and it's a fat one. This only works if you already know identity and equality are two different things. Whether you can pick up that distinction from prompting and review, or whether you have to earn it the hard way by making the wrong call and cleaning up after it, is exactly the part nobody's figured out.

The pessimist's version stings a little. The directors in my analogy mostly logged years behind a camera before they earned the chair with the monitor. Maybe expertise has to get built through struggle even if you spend it later through review. We're running an uncontrolled experiment on a whole generation of developers, and some of them are going to stall out at surface-level pattern matching and never find out what they walked past.

Where You Still Can't Fake It

Even if review-first development pans out, some jobs still want the syntax living in your own skull. Review authentication logic without knowing that Python's is checks identity while == checks equality and you're committing malpractice. The LLM will cheerfully hand you code that's syntactically spotless and semantically loaded.

Performance work runs the same way. A list comprehension builds an entire new list in memory while a generator expression trickles its values out one at a time, and once the input is measured in gigabytes, that little syntax choice becomes the whole performance story.

Then there's corrupted output. Anthropic's September 2025 postmortem walked through infrastructure bugs that scrambled Claude's tokens. Right syntax, wrong characters. Catching that took developers who already knew in their bones what valid code should look like.

Legacy systems close it out. Interfacing with code written before LLMs means reading syntax no model will read for you. That one you can't hand off.

So syntax knowledge ends up in a weird spot. You barely reach for it generating code now. The verification step leans on it harder than ever, and fewer people are logging the reps to build it up. Assembly went through this same wringer decades back. Hardly anyone writes it day to day, and the few spots that still demand it have nothing else that'll do.

Perfect Syntax, Wrong Program

Recent studies pin down exactly where "perfect syntax" comes apart. A November 2024 analysis of GPT-4 and Gemini turned up seven categories of non-syntactic errors, the ones that sail right through flawless syntax. Conditional logic that drops edge cases inside perfectly formed if-statements. Semantic misalignment, like coding up addition when the prompt asked for XOR. Averages computed as (n+m+1)//2 instead of (n+m)/2. Confident calls to methods that were never real. Deprecated APIs, like grabbing Azure's old OpenAIClient when the current one is AzureOpenAIClient (February 2025).

A September 2024 study that combed through 12,837 errors found AssertionError sitting at the top of the pile. The code compiles. It runs. It just hands back the wrong answer.

GPT-4 posts the best overall accuracy of the models studied and the biggest blowouts when it whiffs. Fixing what it gets wrong takes substantial logical revision, not a syntax tweak. Catching those failures takes the exact expertise syntax struggle used to build, a lived sense of what the code should be doing.

The Honest Uncertainty

The old path built expertise slow and dependable, 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 animal wearing its coat. On a good day it turns out architects who think in whole systems. The bad version is a developer who loses the thread past the first stack frame because the muscle memory never set. Probably some of each, depending on the person and how they hold the tools.

This is the power of review-first programming and its risk at the same time. LLMs took over syntax generation, which frees you up to sink into architecture and verification, and that concentration draws on expertise that used to get built through syntax struggle. Unless the English-layer theory is right, and saying "check identity, not equality" out loud builds a cleaner conceptual model than reflexively typing is ever managed. In which case the kids get for free the thing that cost us a decade of busted brackets.

Whether expertise can grow from saying what you mean and checking the result, the way it grew from struggle and discovery, is the open question, and my read is that starting explicit doesn't hand you the same depth as clawing your way to it. But I'm not sure. Nobody running this experiment on themselves right now is sure, and that includes me.