TL;DR - My definition of good code changed once AI became part of how I build. It's not cleverness. Good code is code you can understand fast, that you change in one place, and that's documented consistently enough that an AI can extend it in the same style everywhere.
1. You can understand it quickly
Good code can be visualized and understood fast, especially now, when you and your AI read far more code than you write. If I can open a file and grasp what it does quickly, it's good. If I have to untangle it, it isn't. Legibility beats cleverness, because the real bottleneck is comprehension, not typing.
That's why I like DDD so much. The codebase is shaped like the business, so you always know where things live.
2. You change it in one place
Good code is code you rarely have to change. When you do, you change it in one place and it propagates everywhere it should. Single source of truth. If a change forces you to hunt down ten scattered copies, the code is telling you the abstraction is wrong.
3. It's documented so the AI can follow the style
This is the new criterion. Good code is documented and structured consistently enough that an AI can add to it in the same style, everywhere. When the patterns are clear and written down, the agent extends your codebase coherently instead of bolting on a different style each time. The codebase stays uniform as it grows, even when most of the new code is AI-written.
The throughline
In the AI era, good code optimizes for comprehension and consistency, not for how impressive it looks. Understand-fast, change-in-one-place, documented-so-AI-can-follow - those three keep a codebase fast to work in, for you and for the agents working alongside you.