
# The Reviewer

Lately, I've been experimenting with agent loops, and I added a reviewer to the mix. I was getting frustrated having to review and point the agent in the right direction for obvious mistakes or omissions. That got me wondering: could AI do the reviewing for me? So, I created a reviewer agent. 

I've already put effort into getting my coding agent to follow a process and stick to my standards. (I wrote more about that in ["My AI Writes Code. Yours Can Too."](/blog/my-ai-workflow)).

This greatly improves the end result. But I still find myself reviewing the code and nudging the AI to fix style issues. Sometimes the agent writes three tests where one would do. Or it gets excited about a solution and charges ahead, forgetting standards we discussed earlier. A bit of a puppy brain.

A reviewer agent can catch these issues before I have to. 

## The agent

With AI coding, you have to manage your context window. Once it's full, the system compacts it, and you lose information. So you want to keep it lean. Sub-agents are perfect for this. They run in their own context, do their thing, and just report back the results. No pollution of the main agent's context. Another perk of sub-agents: I can pick the model per role. This allows me to code with Claude Opus 4.5 but review with GPT 5.2. GPT 5.2 is very good at reviewing. The feedback is thorough and actionable. 

This is a small piece of the content for the reviewer agent.
```md
When invoked:

1. Run `git diff` to see all changes
2. Read the **code-review** skill for methodology
3. Identify file types: code, configuration, infrastructure
4. Apply appropriate review strategies from the skill
5. Begin review with heightened scrutiny for configuration changes

## Important Questions

For every change, answer:

- Is the change as simple as possible?
- Are there any hidden side effects?
- Does the code comply with best practices and project standards?
- Does this contain breaking changes (API, database, configuration)?

## Output Format

Use the output format from the **code-review** skill:

- 🚨 CRITICAL - Must fix before deployment
- ⚠️ HIGH PRIORITY - Should fix
- 💡 SUGGESTIONS - Consider improving
```

You can change this to your heart's content. Add whatever checks matter to you. I also have a code review skill with more detailed rules for different types of changes, because I want configuration changes checked differently than database changes or code changes.

For example, just yesterday the reviewer agent came back with:

![Reviewer example output](/images/reviewer-example.png)

This is exactly what I used to catch during my own reviews. Now I don't have to.

## The loop

At first, I did this manually: delegate to the coding agent, then ask the reviewer agent to check it, then pass the feedback back to the coding agent to fix. That got old fast. So I automated it into a loop. The coding agent does its work, and the reviewer agent checks it. If there are issues, they go back to the coding agent. This repeats until the reviewer agent gives a pass, then we commit. 

```mermaid
flowchart TD
    A((Start)) --> B[Select Task from OpenSpec Proposal]
    B --> C[Delegate to Coding Agent]
    C --> D[Delegate to Reviewer Agent]
    D --> H{Is Code Good Enough?}
    H -- Yes --> I[Mark Task as Done & Commit]
    H -- No (max 5x) --> C
    I --> J((End))
```

> [!NOTE]
> I cap it at five iterations. If it hasn't figured it out by then, something's fundamentally wrong and I need to step in.

This works really well, and the quality is way better. To even take it a step further, I usually ask to do this for all the tasks in OpenSpec in one go. So it keeps churning through the list until the entire OpenSpec proposal is complete. 

## Go slower to go faster

Is this slower than generating just the code? Yes, it's way slower. But the results are better on the first try. I still do a final review before it goes in, but now I review less often, and what I do review is already high quality. The reviewer agent catches most issues before I even see the code.


How I stopped reviewing bad code and started building better software with AI assistance.

The Reviewer


# Technical Deflation: Why Your "Clean Code" is a Bad Investment

In an economy, deflation is terrible. When prices drop, consumers stop spending because they know things will be cheaper tomorrow. The economy comes to a halt.

But what if the same logic applied to code? This is what Dan Shapiro describes in his blog [Technical Deflation](https://www.danshapiro.com/blog/2025/12/this-is-a-time-of-technical-deflation/). The cost of producing and modifying code is dropping fast. And it will be even cheaper next month.

For decades, we’ve created code with the following rule in mind: *code is read ten times more often than it is written*. So we invested heavily in readability. We debated variable names. We refactored until our functions were small and pure. We've "gold-plated" our code because we take pride in it and argue that the investment is worth it, because maintaining code is expensive.

**That rule is breaking.**

## The New Math

The technical debt you have today is cheaper to fix than ever. It will even be cheaper tomorrow. If it's not actively slowing you down or causing bugs, why fix it now? You'll pay less later.

And when writing new code, technical debt can be used to your advantage. As Shapiro puts it:

> You are borrowing expensive human hours today, and you will get to pay them back with cheap AI hours tomorrow.

This isn't an excuse for writing garbage or [AI-slop](https://en.wikipedia.org/wiki/AI_slop). It's a shift in the economics of software development. If the end-of-year refactoring sprint isn't removing real friction, it's an investment with a negative return. You're paying premium prices today for maintenance work that will cost pennies in the near future. However, the cost of fixing a badly architected data model will deflate slower than code-shape debt like a messy class or naming.

Different types of tech debt deflate at different rates.

## The Swiss Watch Moment

We are in the [Quartz Crisis](https://en.wikipedia.org/wiki/Quartz_crisis) of software development. For centuries, Swiss craftsmen built mechanical movements by hand. Then quartz arrived. Many watchmakers "thought that moving into electronic watches was unnecessary". They were wrong, and the Swiss watch industry plunged into a crisis.

The handmade watch became a luxury. It didn't tell the time any better than a quartz watch.

I wrote about this in [2026: The Year the IDE Died](/blog/the-death-of-the-ide). Creating code is becoming a commodity. The developer's value isn't in writing code anymore. It's in making sure the correct code gets generated.

[The Purist (Level 0)](/blog/the-ai-coding-ladder/#level-0-the-purist-no-ai) worries about syntax. [The Architect (Level 6)](/blog/the-ai-coding-ladder/#level-6-the-architect) is concerned about whether we're solving the right problem.

## The Objections

**"AI won't understand my spaghetti code any better than a developer would."**

Consider this: Today’s AI is the worst you'll ever use. It gets better every month. Messy code is less expensive for an AI agent than for us humans, and the gap is growing. The things that make messy code expensive for humans (cognitive load and context-switching) don't apply to an LLM the same way. *What's messy for us isn't necessarily messy for the AI agent.* But keep in mind that we still pay a price. Missing tests, unclear boundaries, flaky builds, and unstable contracts make both humans and agents slow and error-prone. This is friction which makes you slower and needs to be fixed.

**"What if we end up with a mess? Developers will need to fix that."**

That argument denies the whole point of Technical Deflation. It's essentially betting that AI will go away and we'll have to start hand-coding everything again. Remember the watchmakers?

The real question isn't whether your code is clean. It's whether your code is **blocking you right now.** If not, move on. The cleanup will be cheaper when you actually need it.

## The Uncomfortable Conclusion

In a deflationary environment, the smartest move is to delay spending. For code, that means: **ship the feature, defer the polish, fix problems when they become problems.**

This feels wrong. It violates everything we were taught. But the developers who understand this will ship faster. And in a world where code is cheap, the only thing that remains expensive is **time.**

Your clean code repo might be a museum piece. Beautiful, maintainable, and months behind the competition.

---
*Remarks:*

1. *[Alef Arendsen](https://www.linkedin.com/feed/update/urn:li:activity:7409493456089272320?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A7409493456089272320%2C7409501926263898112%29&dashCommentUrn=urn%3Ali%3Afsd_comment%3A%287409501926263898112%2Curn%3Ali%3Aactivity%3A7409493456089272320%29) rightfully pointed out that the terminology in the title is not entirely correct. It's the work that is getting cheaper, not the technology.*
2. *Some people seem to take this blog as an advice to no longer think about the quality of the code. An advice to create a "mess". That's not the point. It's about code getting cheaper, how does that affect our choices?*

Changing code tomorrow is cheaper than doing it today.

Technical Deflation


# Why Java Might Be Better for AI Coding

I love Kotlin. It is concise, expressive, and null-safe. It saved us from the boilerplate hell of Java versions of the past. Java has been catching up quickly and is getting better and better. But [Kotlin](/blog/unraveling-the-code-kotlin-edge-over-java-streams) still has some major advantages over Java. For years, "Java vs. Kotlin" was a settled debate: Kotlin was simply better for developers.

But recently, as I shifted my workflow to be [100% AI-generated](/blog/my-ai-workflow) (reaching Level 6 on the [AI Coding Ladder](/blog/the-ai-coding-ladder)), I started thinking about how AI works with my codebase. It essentially searches for and replaces text, then checks whether it works. This was the workflow in the early days of programming. Relying on text manipulation via search-and-replace does not seem like the best idea.

Maybe in the age of AI, the "better" language might not be the one with the nicest syntax. It might be the one with the best **LSP**.

## The IntelliJ Lock-in

Kotlin was born at JetBrains. It was designed *for* IntelliJ IDEA. Coding inside IntelliJ is excellent. But it doesn't easily transfer to other editors. Mainly, because there is no good LSP for Kotlin. Coding Kotlin on other IDEs is a bad experience. 

As a developer, I was perfectly happy with IntelliJ, and therefore ignored how unpleasant it is to use in other IDEs like VS Code, Vim or others.

## Enter AI

Today, most AI agents work without using an LSP. Some mention the possibility of using an LSP, for instance OpenCode, but in my experience, it does not seem to work yet. If asked, OpenCode simply denies that it knows how to use an LSP. Even if it would work, on their site they state that it can only use the diagnostics from the LSP, not the full features.

![OpenCode LSP](/images/opencode-lsp.png)

However, in the future, to understand your code, they will rely heavily on the **Language Server Protocol (LSP)**.

> [!INFO]
> The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server-protocol/) is a standard that allows editors to communicate with language servers. Ideally, it provides features such as auto-complete, go-to-definition, find all references, refactoring, and more, regardless of the editor you use.


Without a good LSP, the AI is just working with the code like a developer would work with code in Notepad. Just search and replace, change the code, and then compile it to see any errors. LLMs are fantastic in this and do a very good job, an amazing job even. But imagine if we gave them a good LSP and they knew how to use it. They would essentially get the same powerful tools you have when using IntelliJ—being able to refactor code and immediately see when there is an error. They would stop guessing based on text patterns and start understanding the *structure* of your code.

## The Problem

Here lies the problem:

*   **Java**: Has the Eclipse JDT LS. It is mature, battle-tested, and robust. It exposes deep insights about the code structure to VS Code.
*   **Kotlin**: The LSP situation is... bad. There is a community-driven server, and recently JetBrains released an experimental one (which they call "Pre-alpha"). But at the current state, it's barely usable.

## The Paradox

This leads to a weird conclusion for the future: **If you want the best AI agent, you might be better off writing Java.**

Currently, AI tools do not make much use of LSPs yet. But going towards the future, they may more and more. And hopefully in 2026, they will be better integrated into the tools I am mostly using, like OpenCode.

When LSPs really find their place in AI coding, it may feel like coding with Java is like you're fully connected, while with programming Kotlin it's like going back in time. It will possibly be slower and more expensive because doing search and replace will cost more tokens than doing a call to the LSP.

## Conclusion

For the last decade, many people migrated to Kotlin to escape Java’s "noise". We wanted clean syntax because humans have a limited bandwidth for boilerplate. We chose Kotlin because it made us better coders and helped us enjoy coding more.

By moving away from the nicer language and back towards a language with a robust, open-standard LSP like Java, we are making a trade-off that feels wrong but yields right:

- If you are on the [AI Ladder Level 0-3](/blog/the-ai-coding-ladder): You write the code. You need the language to be concise.\
**Winner: Kotlin**.
- If you are moving towards the higher levels [Level 4 and up](/blog/the-ai-coding-ladder), the verbose syntax of Java matters less (since you aren't typing it), and the deep understanding the AI will get from the LSP matters more.\
**Winner: Java**.

## The Choice for 2026

If you are a purist who enjoys the craft of manual coding, stay in IntelliJ with Kotlin. It remains the gold standard for human-centric development.

However, if you are moving toward an Agentic Workflow, where you act more as an architect than a typist, you have to ask yourself: Am I writing this for me, or for the AI? We may be entering an era where we intentionally choose "worse" languages to get better results. It’s counter-intuitive, it’s frustrating, and it’s a total paradox, but in the age of AI, the best code might be in a language that you didn't even want to write yourself.


Kotlin may be a nicer language, but Java might be the best choice when paired with AI. Here is why.

Jeroen Gordijn

Latest Articles

The Reviewer

Technical Deflation

The Kotlin Paradox

Ready to Develop Faster with AI?