I had an epiphany the other day that changed how I think about code review forever.
I was staring at AI-generated code, reviewing what OpenCode had just written. The syntax was perfect: no compilation errors, no typos, the formatting was impeccable. The AI had done exactly what it was supposed to do: write syntactically correct code.
But something was wrong. I couldn't focus. My eyes were darting across the screen, distracted by a rainbow of colors. Keywords in purple, variables in orange, functions in blue, strings in green, comments in gray. Every line was a festival of syntax highlighting.
And then it hit me: AI writes syntax. I need to read semantics.
The game has fundamentally changed. When we wrote code ourselves, syntax highlighting helped us navigate the code we were creating. But now? AI agents generate the syntax. Our job isn't to verify the syntax; it's to verify the meaning. The logic. The architectural soundness. The edge cases.
And suddenly, I realized why I'd been feeling so overwhelmed reviewing AI-generated code. My development environment was designed for the old world: the world where I wrote code and needed help navigating syntax. It wasn't designed for the new world: the world where AI writes syntax and I need to read it.
I had the right tools for the wrong era.
The problem AI code review creates
Here's the reality of working with AI coding agents today: we're reviewing more code than ever before.
I personally review dozens of AI-generated files every day. My workflow is split between two windows: on the left, I have my terminal running OpenCode, my AI coding assistant. On the right, I have Sublime Text open, reviewing everything the AI has generated.
This is the new normal for developers working with AI agents. And it creates a fundamentally different cognitive challenge than the code reviews we did just a few years ago.
The scale has exploded. Before AI, code reviews were occasional events: a few files here and there. Now, with AI generating entire features and refactors in minutes, we're reviewing code at unprecedented speed and volume.
The problem has shifted. AI coding agents excel at syntax. They know the language keywords, the standard library, the conventions. They generate code that compiles, that follows patterns, that looks syntactically correct. The errors that slip through are semantic errors: logic bugs, architectural issues, missing edge cases. The kind of errors that you can't catch by looking at whether the syntax is right.
But our tools haven't adapted. Our color themes were designed when humans wrote every line of code. They highlight the things that were hard to track manually: keywords, variables, function calls. Syntax, syntax, syntax.
But now that AI handles the syntax? Our colorful themes are highlighting the wrong things. They're distracting us from what actually matters.
My discovery moment
I was sitting at my desk, eyes burning from staring at screen after screen of rainbow-colored code. I'd been reviewing AI-generated code for hours, and I couldn't shake the feeling that I was missing something. That the code was fine, but I wasn't really seeing it.
On a whim, I started reading about minimalism in development tools. That's when I found it: an article by Nikita "Tonsky" Prokopov titled "I am sorry, but everyone is getting syntax highlighting wrong."
As I read, everything clicked. Tonsky was talking about exactly what I'd been experiencing: the cognitive overload of too many colors, the way that highlighting everything means nothing stands out.
He made a point that stopped me cold: "If everything is highlighted, nothing is highlighted."
I realized that my rainbow syntax highlighting was acting like a distraction filter. It was drawing my attention to the very things AI gets right, syntax, while burying the things I needed to focus on: semantics.
So I tried something. I installed Alabaster, Tonsky's minimalist color theme for Sublime Text.
The difference was immediate.
Suddenly, I could actually read the code. The noise was gone. I could see the structure, the logic flow, the actual meaning of what the AI had written. My eyes stopped darting around searching for patterns and started following the semantics.
It wasn't that the code had changed. It was that I could finally see it.
Why colorful themes fail for AI review
Here's the problem with traditional colorful syntax highlighting in the AI era:
Everything is highlighted, nothing stands out
Look at a typical modern color theme. You've got a unique color for everything: variables, functions, classes, constants, keywords, strings, comments, operators... sometimes fifteen or twenty different colors splashed across every file.
Look at a typical modern color theme. You've got a unique color for everything: variables, functions, classes, constants, keywords, strings, comments, operators... sometimes fifteen or twenty different colors splashed across every file.
But here's the thing: most of your code is just variables and function calls. If you highlight those, you're highlighting 75% of what's on your screen. Everything is bright and shiny, and instead of standing apart, it all blends together.
Tonsky demonstrates this perfectly with a simple test. In a rainbow theme, try to find where a function is defined. You can't. Everything is so highlighted that nothing catches your eye. But in a minimalist theme, the definition stands out because almost everything else is plain text.
The same problem applies to AI code review. When everything is highlighted, you can't quickly scan for the things that matter: the semantic patterns, the logic flows, the potential bugs.
Colors are meaningless decoration
Here's a test Tonsky proposes that will make you think: close your eyes and try to remember what color your current theme uses for class names.
You probably can't.
And here's another: if someone swapped the colors in your theme, would you even notice?
Most people can't answer yes to either question. And that's the problem: if you can't remember what colors mean, and you wouldn't notice if they changed, then your color theme isn't a tool: it's decoration. It might make you feel like you're looking at "properly highlighted" code, but it's not helping you work.
In the AI era, where efficiency and focus are paramount, decoration is a luxury we can't afford.
Highlights syntax, hides semantics
This is the core issue. Colorful themes were designed to help with syntax. They highlight keywords, operators, variables: all the syntactic elements of code.
But here's what AI coding agents do: they handle the syntax.
The AI knows where the keywords go. It knows the operator precedence. It gets the syntax right almost every time. What it doesn't always get right is the semantics. The logic. The meaning.
And yet, our colorful themes are highlighting exactly the things AI gets right, while burying the things we need to review. They're drawing our attention away from the semantic errors and toward the syntactic correctness that we should take for granted.
It's like having a highlighter that highlights all the words spelled correctly in an essay. Sure, it tells you something, but it doesn't help you find the argumentative flaws.
Designed for writing, not reviewing
When we wrote all our code ourselves, syntax highlighting served a different purpose. It helped us navigate the code we were creating. It helped us spot typos. It made it easier to see the structure of the code we were actively building.
But now we're in a different mode. We're not building: we're reviewing. We're not writing syntax: we're reading semantics.
And the cognitive demands of reviewing are different from writing. When you write, you're generating ideas. When you review, you're evaluating ideas. You need to see the big picture, follow logic flows, spot inconsistencies.
Rainbow syntax highlighting, designed for the writing process, actively interferes with the reviewing process.
Practical implementation guide
So here's what I did to fix my workflow, and how you can do it too.
Complete setup walkthrough
Step 1: Install Alabaster in your editor
I use Sublime Text, so I went to the Alabaster GitHub repo and installed the theme. It's available for most editors: VS Code, JetBrains IDEs, Vim, and many others have ports or similar themes.
Alabaster defines just four classes:
- Strings: Green
- All statically known constants (numbers, symbols, keywords, boolean values): Purple
- Comments: Yellow
- Global definitions: Light blue
That's it. Four colors you can actually remember and use.
Step 2: Find a terminal theme
I wanted my terminal to match my editor, because my workflow splits between them. I have OpenCode running in iTerm2 on the left, and Sublime Text on the right. Constantly switching between different color schemes was jarring.
Alabaster has an official theme for Alacritty, but not for iTerm2. That's okay: I just went to the Alacritty theme repo, opened the .toml file, and manually copied the color definitions into iTerm2's color profile settings.
Step 3: Set up both light and dark variants
This was crucial for me. I mostly work in light mode because I'm often in brighter rooms and it reduces eye strain and screen glare. But sometimes, especially at night or in dim environments, I find dark mode more pleasant.
Alabaster has both variants, and I wanted my terminal and editor to match in both. So I created two iTerm2 color profiles: Alabaster Light and Alabaster Dark, matching the Sublime Text themes.
Now I can switch between light and dark modes seamlessly, and my entire development environment stays consistent.
Step 4: Set up workflow switching
The final piece was making it easy to switch between light and dark modes. In Sublime Text, I use the theme switcher. In iTerm2, I've got keyboard shortcuts set up to toggle between profiles.
One command, and my whole environment flips between modes. No jarring mismatches, no cognitive dissonance.
Addressing skepticisms
I know what you might be thinking. I had the same thoughts myself.
"But I'm attached to my current theme"
Valid concern. Change is hard, especially when you've spent years customizing your development environment to feel like home. Your current theme is comfortable. It's familiar.
Here's what I'd suggest: don't commit forever. Try it for a week.
Install a minimalist theme. Use it for your AI code reviews. See if it feels different. See if you catch bugs you might have missed before. See if your eyes feel less tired at the end of the day.
There's an emotional attachment to "pretty" themes: I had it too. Colorful schemes feel professional and feature-rich. Minimalist themes can feel stark, even boring.
But here's the thing: if your theme is decoration instead of a tool, it's not serving you. In the AI era, where we're reviewing more code than ever, efficiency matters more than aesthetics.
"Aren't colors supposed to help comprehension?"
Yes, absolutely. Syntax highlighting can be an incredibly powerful tool: when it's done right.
The key insight from Tonsky's work is that colors should highlight what's rare and meaningful. Not everything.
When you have fifteen different colors for everything, your brain can't actually use those colors as a tool. You can't remember what they all mean, you can't quickly scan by color, and nothing stands out because everything is highlighted.
But when you have a small set of colors: four or five, that you can actually remember and use, then highlighting becomes a genuine tool. You can scan for strings in green. You can spot comments in yellow. You can identify top-level definitions in light blue.
The difference between decoration and tool is intentionality. Colors should serve a cognitive purpose: helping you navigate and understand the code. If they don't, they're just pretty patterns.
Here's the test: if someone swapped two colors in your current theme, would it impact your ability to work? If no, your colors aren't tools: they're decoration.
Conclusion: an invitation
AI writes syntax. We read semantics.
It's a simple shift, but it has profound implications for how we work. Our development environments were designed for an era when humans wrote every line of code. They're optimized for a task: syntax navigation, that AI now handles automatically.
But our job hasn't disappeared; it's evolved. We're now reviewers, auditors, architects working at scale. We need to evaluate meaning, not syntax. We need to spot logic errors, not typos. We need to understand semantics at speed.
Our tools need to evolve too.
Since I switched to Alabaster, the difference has been tangible. My eyes feel less tired at the end of the day. I can review more code with better focus. I'm catching issues that I would have missed before.
But the biggest change is in how I feel when I work. Instead of being overwhelmed by the scale of AI-generated code, I feel equipped to handle it. Instead of being distracted by a rainbow of colors, I can see the code itself.
Here's my invitation: try it for a week.
Install a minimalist theme. Use it when you review AI-generated code. See if it changes your experience. See if you feel more focused, less overwhelmed, better able to do the job that AI has created for you.
The right environment amplifies your ability to work effectively with AI coding agents. Don't let an outdated color theme sabotage your code reviews.
AI writes the syntax. Your job is to read what actually matters. Make sure your environment helps you do it.