When AI Reviews Your C Code, Lessons From a printf Implementation

Introduction

So, as part of my systems programming course, I had to implement my own version of printf in C. The classic stuff, parsing a format string, handling variadic arguments, converting integers to strings, writing to stdout.

But the interesting part of this project wasn’t the code itself. The goal was to submit my codebase to an AI tool (I used Claude by Anthropic) and use it as a code reviewer. Then, instead of just accepting what it says, I had to critically analyze its feedback, figure out what’s actually useful, what’s generic fluff, and what’s just plain wrong.

Focus Area

I picked Format String Parsing & Specifier Resolution as my deep-dive area. It’s basically the core of the whole function; the main loop in _printf where you go through the format string, detect %, look up what specifier follows, and dispatch to the right handler function.

My implementation uses a dispatch table (an array of structs mapping characters to functions), which I thought would be interesting to have reviewed by an AI because there’s real design decisions in there, not just straightforward code.

The Prompt I Used

Here’s exactly what I asked, word for word:

Dans un rapport IA structuré, dans le cadre du projet en cours :

Fais un feedback sur le code que je t’ai envoyé, sur la structure et la clarté du code.

Fais une analyse de la logique : est elle correcte, quels sont les potentiels problèmes, voies d’amélioration ?

Fais une analyse aussi la gestion de la mémoire, niveau sécurité high et low level.

Fais une recherche de cas qui ne sont pas gérés et comportements non définis/aléatoires.

Pour finir fais un point sur l’optimisation du code, son efficacité et son architecture.

It’s in French, and I deliberately asked for feedback only no rewrites, no fixes. Just a review.

What the AI Said (Summary)

The AI came back with a pretty detailed report. Here’s the gist of it:

On structure, it liked the file separation and noted the code follows Betty style consistently. It suggested renaming some variables (count_T, fs[], forms) for clarity and flagged the incomplete doc block on _printf.

On logic, it caught that the formats field in my dispatch struct is a char * but only the first character ever gets compared which is a fair point. It also noticed that I never check _putchar’s return value, so write errors go undetected.

On memory, it pointed out there’s zero dynamic allocation in my code, which it called a safe design choice. It confirmed that va_start and va_end are correctly paired on all paths. It flagged the hardcoded INT_MIN value as potentially non-portable.

On edge cases, it listed all the specifiers I don’t support (%u, %x, %o, %p, etc.) and discussed behaviors for things like % at end of string or NULL arguments.

On optimization, the big one was that _putchar does a syscall for every single character, which is expensive. It also noted the recursion in print_recursive and said a buffer-based iterative approach would be more efficient.

My Take What’s Good, What’s Not

Actually useful stuff

The char vs char observation on the dispatch table — that’s a real catch. My struct says char formats but I only ever look at formats[0]. Using a simple char would make the intent way clearer. I wouldn’t have noticed that on my own.

The write error propagation point is also legit. If write fails, my counter still goes up, so _printf returns a wrong count. That’s a real bug, not a nitpick.

And the syscall-per-character critique is well-founded. Each _putchar call triggers a write(1, &c, 1) that’s a kernel context switch every time. Meanwhile print_string already does a single write for the whole string, so there’s an inconsistency in my own code.

Generic stuff that any reviewer could say

The naming suggestions are fine but… not exactly deep analysis. Telling me to rename count_T to char_count doesn’t require understanding what printf does. Same for the documentation comment yes, my doc block is incomplete.

Listing all the specifiers I don’t support is also pretty surface-level. You can literally just look at my dispatch table and see what’s there and what’s not.

Where the AI got it wrong (or at least misleading)

The INT_MIN portability thing bugged me. The AI said my hardcoded -2147483648 check assumes 32-bit int and would break on other architectures. Technically true, but practically misleading this project targets standard modern systems where int is 32-bit. More importantly, the AI didn’t suggest the obvious fix: just use INT_MIN from <limits.h>. It identified the problem but missed the simple solution.

The % d behavior critique was also off. The AI said my code incorrectly handles _printf(“% d”, 42) because standard printf treats the space as a flag. But my project spec doesn’t require flags at all. The AI applied the wrong standard it reviewed against the full printf spec instead of my actual project requirements. A human reviewer who read the assignment wouldn’t make that mistake.

The AI also didn’t go deep enough on my focus area. It described the parsing flow correctly but never questioned things like: why is the dispatch table a local variable instead of static? What are the implications of the fallback behavior (printing % + unknown char) — could it mask bugs? These are the kind of questions a real reviewer would ask.

Nothing dangerous though

I’ll give the AI credit here, nothing it suggested would introduce bugs or undefined behavior. No unsafe recommendations. That’s a good baseline.

AI as a Code Reviewer — My Honest Take

It’s good at the obvious stuff: file structure, naming issues, missing NULL checks, known patterns like va_list handling. If you need a quick first pass, it does the job.

But it has real blind spots. It doesn’t know your project spec, so it applies generic standards that might not apply. It produces long reports that look complete but often lack depth on any single point. And it states everything with the same level of confidence, whether it’s a solid observation or a context-dependent opinion.

The biggest risk? If you just accept everything it says, you’ll end up “fixing” things that aren’t broken and missing the stuff that actually matters. The report looks so clean and professional that it’s tempting to just accept it.

Conclusion

AI code review is a decent starting point. For catching structural issues, surface-level bugs, and well-known anti-patterns, it works. I’d use it as a first pass before a real review.

But for systems code like printf where you need to understand project constraints, reason about parsing logic, and evaluate design trade-offs it’s not enough. It’s a tool, not a reviewer. The thinking still has to come from you.