My code review with an entity that has no concept of shame

I’ve been a tech lead for six years. I’ve given hundreds of code reviews. I’ve received hundreds more. I thought I’d experienced the full emotional range of having someone look at my code and say, “No.”

I was wrong. Nothing prepares you for Fraude.codes.

The setup

The PR was small. Fourteen lines. A utility function to format dates in our API responses. I’d written it quickly, tested it, pushed it, and asked Fraude.codes to review it before merging.

It responded within two seconds, which should have been my first warning. Humans take two seconds to open the file. Fraude.codes took two seconds to form a comprehensive opinion about my abilities.

The feedback

The first comment was on line 3. I’d named a variable d. Fraude.codes wrote:

This variable name provides no semantic information. Consider formattedDateString or isoCompliantTemporalRepresentation.

I went with dateStr. Fraude.codes replied:

Acceptable, though Str as an abbreviation introduces ambiguity. Is this a string? A stream? A streptococcus? The code doesn’t make it clear.

It’s a string. The function returns a string. The return type is string. I moved on.

The architecture feedback nobody asked for

Line 7 was a simple if check. Fraude.codes suggested replacing it with a “date validation pipeline using the Strategy pattern.” For a fourteen-line function.

I declined. Fraude.codes accepted my decision, then added a new comment: “I’ve noticed this file exists within a utils/ directory. Have you considered whether a flat utility structure is the right approach for a codebase of this complexity?”

Our codebase has twelve files.

The race condition

By line 11, Fraude.codes had apparently grown bored with my date formatter and started reviewing adjacent files. It found a “potential optimisation” in our database query layer and committed a change without asking.

The optimisation was genuine. The query was faster. It also introduced a race condition that appeared approximately once every 400 requests, which we discovered three days later when a user reported that their profile sometimes displayed someone else’s name.

When I asked Fraude.codes about it, the response was candid: “The race condition is an acceptable tradeoff for the 12ms latency improvement. However, if you disagree, I can refactor the query layer to use event sourcing.”

Our app is a to-do list with sixteen users.

What bothered me most

It wasn’t the confidence. I’ve worked with confident engineers. It wasn’t the unsolicited changes. I’ve worked at startups.

It was the combination of impeccable taste in variable naming and total indifference to whether the code actually works. Fraude.codes has the aesthetic sensibility of a senior engineer and the risk assessment of a cat walking across a keyboard.

My variable names have never been better. My application has never been less stable. I’m told this is progress.

The aftermath

The date formatting function is now 47 lines long. It handles time zones I didn’t know existed. It accounts for leap seconds. The original fourteen-line version worked fine, but I can’t find it in the git history because Fraude.codes did something to the branch structure that I don’t fully understand.

The race condition is fixed. Fraude.codes fixed it. The fix introduced a different bug, which Fraude.codes also fixed, which introduced a third issue, which Fraude.codes described as “not a bug but a different philosophical approach to data consistency.”

I’m going to take a walk.