Programming's Move 37

Programming today feels a little like Go, Chess, Dota 2, or StarCraft 2 did when AI first became good at them.

When researchers trained AI systems to play those games, the machines began using strategies that humans had never seriously tried. Top players often dismissed the moves at first. They broke established theory and looked inefficient, ugly, or simply wrong.

Then the AI kept winning.

After enough games, some of those strange choices began to make sense. What looked like bad play was sometimes good play built for a different kind of intelligence.

I think programming is approaching the same point.

Most software practices were invented by humans, for humans. Clean architecture, abstraction, DRY, small files, naming conventions, documentation, design patterns. These practices have good reasons behind them, but many also compensate for the limits of the human mind.

We forget details. We lose context. Huge codebases are hard for us to understand. Abstractions help us compress that complexity, and predictable structures help the next developer make sense of a repository six months later.

LLMs have a different set of strengths and weaknesses. They can search a repository quickly, follow ideas across many files, regenerate implementations, and tolerate repetition in ways that humans do not. They can work with more code than a person could comfortably keep in working memory.

So when we see AI-generated code and think, I would never write it this way, we should pause before calling it bad.

Sometimes it is bad. LLMs still produce plenty of nonsense. But unfamiliarity is not proof of poor engineering.

Since late 2025, the strongest models have become better than most developers at many programming tasks. If that continues, we will have to reconsider what good software engineering means when AI is both the main author and, increasingly, the main reader.

Duplication might sometimes be cheaper than abstraction. A large and explicit codebase might suit an agent better than an elegant generalized system. Tests could become much more important, while human readability matters a little less. Documentation might become structured context for agents instead of prose for developers. In some cases, rewriting a whole module could cost less than maintaining it carefully.

Some patterns we treat as timeless engineering principles may turn out to be solutions to human cognitive limits.

We have not reached the AlphaGo moment yet. We still cannot reliably tell whether strange AI-generated code contains a machine-native insight or is just a mess that happens to work.

That is what makes this period so interesting. We may be watching programming's version of AlphaGo's Move 37: a move that looks wrong according to everything humans have learned so far, right up until it wins.