- DRY principle violations, multiple definitions of the same helpers or utilities.

- Changes that deviate from existing patterns and architecture already in the code, especially in nearby and related code

- Comments that add no context or simply restate the field name.

- Naming violations (enterprise factoryfactoryabstraction stuff, excessively long names, overly technical names, banned words like “seam”, “durable”, and no-value-qualifiers like “SaveGame” -> “Save”).

- Tests that check implementations instead of correct business behavior.

- Overly backwards-compatible unless asked for (this one is incredibly hard to keep under control, as AI loves to guard everything even if the previous code was never deployed and thus there is no contract break)

- Un-necessary guard code (this is hard to control, most common case is the AI not relying on the serializer error handler and instead adding guards that the library already handles)

- Changing public API contracts without express permission to do so (depends on the code, eg a library JAR or versioned REST service)

- Meta references to previous code versions, to tasks or todos, or to instructions and other non-code context (e.g you tell the AI the adder should ignore negative numbers and that meta fact enters the comments or code)

I usually hand review all changes myself but it’s incredibly tedious so I try to first pass with the review agent until it comes back clean. I hate wasting tokens on it though.

Everyone should be doing regular code reviews and this helps a lot.

This has bitten me a couple of times, and it’s surprisingly annoying to nudge agents into good/resilient patterns or identify situations that should fail loudly, at least in my experience. The retry mechanisms they come up with on their own are often pretty terrible as well.

I’ll note, though, that I have seen this from human engineers plenty of times, and at least the AI usually adds some logs rather than just totally silently absorbing an exception!

This made me chuckle.

Cool tool, the dead code checks can be very helpful. I’ve seen Claude leave unused functions when iterating which always frustrates me.

One real bug tho:

> [ERROR] Imports "mdast" but it's not declared in package.json

A type-only import like `import type { Blockquote, RootContent } from 'mdast';` is actually acceptable if `"@types/mdast": "^4.0.4"` is included in the package.json.

I'd love for it to have flags for Pi and Crush too :)

One funny thing I see it doing is deleting seemingly random comments lines, for example if a file has a comment that spans multiple lines but doesn’t use a multi line comment syntax. It just chooses one at random transforming the once useful comment into slop.

Concentrate on code quality, and whether it does what it needs to do. Not whether it was written by AI or not.