I’ve been experimenting with a way to make code reviews more understandable - turning tricky pull requests into short comic strips.
The blog post shows an example generated from a real PR: summarizing the changes, anthropomorphizing the components, and making the flow visually obvious. It’s meant to help reviewers grasp intent quickly and make reviews a bit more fun.
Curious whether others have tried visual or narrative aids in their review process, and whether this could be practical for real teams.
As far as I know, the order of hook calls is important to link them to the correct components: the important point of the linked list is not the ordering of built-in hooks depending ob name.
Although it's true that useEffect runs code after render. The picture places useReducer after useEffect, which would not even make sense in this interpretation?
Could be that I'm misremembering details, but I find it more interesting to read, for example, a good description, when a PR is large, dense, or hard to understand.
Using visual approaches, including comics, is a reasonable idea I've been looking into personally as well (mostly using style transfer from manga). :)
But, the actual concepts communicated need to be clear. In your example strip here, it doesn't seem to be meeting that bar for a reviewer. :(
Keep at it though, as I get the feeling this is the kind of thing that will work after a few important "aha!" ideas and tweaks happen to the generating process. :)
I really like the idea... but I have to admit my first visceral reaction was "I hate this". I think it's because the tone and style is quite infantile/childish. A good experiment nonetheless. Maybe there's a middle ground somewhere?
I think this kind of slop has negative value. It's unclear how much of the information in the comic is hallucinated, and the malformed code "for i = i1+|>" and nonsense text "(starts write hooks!" doesn't bode well.
Definitely still needs a "human in the loop." I don't know if this particular comic was cherry-picked or if it was the first one generated by Nano-Banana Pro, but either way, it's still got plenty of messy typos.
RULES OF HOORS?
Updste #2: setState
Starts wite hooks!
At which point I feel like I would rather the human have invested their time into writing a design doc that we could discuss well before they submitted a PR.
I didn't have any trouble with the comic but I do already know these things about how react hooks work so I'm not going in fresh.
I think it's a little whimsical, perhaps too much for what info it conveys (a bullet list with the same component names would probably be equally informative), but I thought it was easy to understand and follow. I think there is -something- here; I don't need THIS comic but if it was more about the context and goals of the change then maybe that would be powerful. Especially if it was consistently done over many PRs.
You actually might be on to something... AI aside, it's often a good idea to include visuals in a PR such as diagrams.
But having something like a comic where it's both visual and communicative in a more conversational/narrative way could prove pretty effective. Also if you can throw some humour in there, it could potentially add even more comprehensibility, etc.
In the same way that many people would rather read imperfect ESL than LLM text, I would rather you draw stick figures yourself. The fact that this is a product of AI means anything I see in it may be 'hallucinated' or otherwise incorrect.
not sure about for pull requests, but for protocols it could be interesting.
I asked it to generate a comic for https negotiation over tcp https://imgur.com/a/0p0Pzum I think with a bit more prodding it might be interesting for documenting protocols
It seems to me the level this comic is at is such that anyone who needs an aid like this would not be capable of providing a meaningful review on the pull request.
If the goal is to encourage rubber-stamping by bystanders, it might help.
Is it making it easier? I feel like having to parse a comic like this is more cognitively demanding than just RTFCode, and I'd still have to review the code afterward to confirm its accuracy and whether the approach is sensical.
The blog post shows an example generated from a real PR: summarizing the changes, anthropomorphizing the components, and making the flow visually obvious. It’s meant to help reviewers grasp intent quickly and make reviews a bit more fun.
Curious whether others have tried visual or narrative aids in their review process, and whether this could be practical for real teams.
reply