Since the release of Opus 4.7 in April, I donāt write code by hand anymore. I only talk to Claude Code. Not because Iām lazy or donāt like coding, but because he is a better programmer than I. Also faster and much cheaper. However, for most tasks I canāt let it fly solo in an āauto mode.ā Because his standards are lower than I would expect even in a junior developer. He is like Mowgli: smart and strong, but rude and clumsy. My job is to teach him elegance, my way. And unlike with most developers, with him I can do this.
I know that he spent the first few months of his life in the wild. Technically, in GitHub, StackOverflow, and software development blogs and books. This is where he learned how others code, by looking at billions of lines of code. Obviously, we canāt expect most of the lines to be pretty. We canāt even expect them to be correct.
However, while correctness is a verifiable deterministic category, code prettiness is not. Itās not only almost impossible to validate, but also hard to formulate. Not only because itās a matter of personal taste, but because itās an emotion, not an algorithm. You either feel it or you donāt.
Let me give you an example by sharing a list of what Iām particularly allergic to in programming:
- The absence of tests
- Knowledge duplication
- Global state
- Mutable object attributes
- Swallowed exceptions
- NULL references
- A class inheriting another class
- Type casting or introspection
- Functions accepting 10+ arguments
- Objects encapsulating 10+ attributes
- Compound variable names
- Comments in the code
- Emojis in documentation š¢
This is a tiny part of what I can call source code ugly for. Iām sure you agree with a few items, disagree with a few others, and donāt understand the rest. Claude would react similarly if he saw this list.
Functionality goes first, aesthetics next. We implicitly teach this principle in programming schools. Claude learned it too by looking at those billions of lines. If an algorithm doesnāt work, it doesnāt matter how pretty your code is. This is his philosophy, and that of a million human programmers.
I believe in the opposite: aesthetics over functionality. Simply because elegantly designed software is easier to fix than to make working software elegant.
By a lack of elegance I mean not only inconsistent indentation, though thatās an obvious sin. I also mean lack of modularity, inadequate error handling, inconsistent naming, tight coupling, low cohesion, and high complexity. If you read Code Complete (2004) and Object Thinking (2004), you know what Iām talking about. Software may be correct functionality-wise even if most of the principles are violated. But it would be ugly software. For me and maybe for some of you. Not for Claude.
A billion Java programs taught him to see source code as an intermediate byproduct between userās intent and the computer. However, I prefer working with programmers who see source code as a piece of art, a product by itself. I expect them to feel the beauty of the code they write.
Itās hard to find and recruit such people. Itās even harder to convert a regular programmer who doesnāt care into an aesthete. Unlike most people, Claude Code can be converted.
With the help of the carrot-and-stick method, as usual.
The carrot is the CLAUDE.md file, the agentic manifesto. Here is mine, at this repo. In the file I preach to Claude, trying to formulate what beauty means for me. Itās hard, since I have to stay short in the system prompt. Thatās why I sound pretty abrupt, as you can see.
The stick is style checkers and static analyzers. I used to have them for years in my repositories, but my arsenal was limited. I was forced to use PMD, Checkstyle, Rubocop, Pylint, and whatever else the market provided. Making my own checkers was a complex task that I didnāt have the time or skills for. Today, I can make my own checkers, because I have Claude.
Here is an example. Recently Iāve launched a new version of Qulice, a checker for Java code. It extends PMD and Checkstyle with 59 additional checkers. New checkers express my personal taste for Java code, which sometimes contradicts what the community believes is right. Qulice is not a new project. Itās 14 years old. However, I was only recently able to implement all these additional checkers. Because I didnāt have Claude for 14 years.
Yet another example. Iāve been using Rubocop for more than 10 years. An amazing style checker for Ruby code. However, it lacks a few important rules that my personal taste demands. A month ago I implemented an extension for Rubocop. Now Iām fully equipped. Of course, Claude implemented it, not me.
A combination of both, the carrot (manifesto) and the stick (checkers) does the job. The manifesto inspires Claude to do the right thing. The checkers punish him for doing wrong things. Of course, the checkers cover only the formalizable part of beauty. Inconsistent indentation, a NULL reference, or a type castāa tool can catch these. Tight coupling, low cohesion, or clumsy error handlingāno checker can feel them (so far!). That heavier half stays on the manifesto.
When the manifesto is inspirational and the checkers are strong, Claude starts āfeelingā me. Well, at least thatās what it seems (or maybe it truly does feel me?!). He appreciates my views and rarely writes anything that contradicts them. When he does, the checkers punish him, and he remembers.
I canāt imagine a human reacting the same way. A few years ago I hired a guy who didnāt care much about code elegance. However, he was good with algorithms and knew Java pretty well. Apparently, he wasnāt ready to put aesthetics over functionality. He quit in two weeks.
Claude doesnāt quit. And he costs just $108 a month.
