code review on Olaf Alders

Publish-Only

olaf@wundersolutions.com (Olaf Alders) — Tue, 13 Oct 2026 21:15:19 -0400

There’s more than one way of delivering a code review, and that’s the topic that got me on this tangent.

"Message in the bottle" by Dasha Bondareva is licensed under CC BY-NC 2.0.

I’ve had code reviews from people who thought it was some sort of a flex to go to great lengths to find any kind of an issue in a pull request. It can take a lot of the joy out of the job and some days I’d dread sitting down at my desk knowing that I would have to deal with this kind of largely meaningless back and forth. I’ve toned down my own code reviews a lot after being on the receiving end of meaningless pedantry.

It may sound silly, but I had a colleague who would use emoji in code reviews and it was always kind of fun to see which ones he could jam into the review.

Dependency bump? 📦 ⬆️
Fixing a flaky test? 🎲 🚫
Performance improvement? 🐢 ➡️ 🐇
Deleting code? 🔥 🪓

What eventually happened is that other people started doing this and it became kind of a fun game to see if you could express the intent of a PR with emoji. When you get this kind of feedback, you know that whatever else is in there isn’t going to be harsh. It sets a fun tone for what can actually be an enjoyable exercise: you get to learn something from a colleague and sometimes what you learn is that your work is okay to merge without changes.

Contrast that with the reviews that are a laundry list which send the message “what are you even doing here?” and you pretty quickly get to know whom you enjoy working with. Making a code review not feel like being hit with a hammer is not hard. It just takes a bit of effort. You will give up some economy, but you’ll also retain more humanity.

On a slightly related note, one of the funniest things I ever saw at this workplace was a chat message where one developer announced they were going “afk (away from keyboard) for 20 minutes” only to have a teammate attach the “📰🚽” emoji to the message. Obviously you’d need to tread lightly with this kind of jocularity.

"1947 advertisement for Lux Toilet Soap" by Matthew Paul Argall is marked with Public Domain Mark 1.0 .

Now, depending on the culture of your workplace, you may need to put up with this kind of thing at work, but you do not have to grin and bear it everywhere else. The same types are on social media. Depending on where I’m sharing something, I may treat it as a publish-only space. For example, I find some people on Reddit can have a pretty hefty capacity for trying to ruin someone else’s day, so I often just won’t read the comments there. (That’s not to say Redditors are inherently cruel, but that the platform often doesn’t disincentivise bad behaviour.)

Your mileage may vary, but that’s what I’ve found helps me better enjoy my day. I accept that people who lash out exist, but I also accept that I don’t need to engage with them.

I could also just say I’m not going to share posts on Reddit, but the truth is that it can drive a significant amount of traffic. So, depending on how I’m feeling on a particular day with Reddit, I may just throw something over the wall and not stick around to find out what happened. If I feel I have a thick enough skin on a different day, I may engage fully. I don’t have a blanket ban on commenting there.

My one other caveat about Reddit is that I have to make sure there’s not even a whiff of an em-dash in my writing for fear that people start getting their LLM pitchforks out. I had one post removed from r/programming for being “mostly LLM-generated”. Spoiler alert: it wasn’t. My feelings on that are that I like em-dashes and I have for a lot of years, but I’ll probably need to use some other kind of punctuation in their place if there’s a chance a post gets arbitrarily removed. That’s currently not a hill I’m willing to die on.

Publish-only is a valid choice, in the same way that I don’t engage with someone who flashes me their middle finger from their car in traffic. If communication feels like a fool’s errand, I don’t have to default to playing the fool.

Code Review Is the Hard Part

Read on website

Who Handles Your Security Reviews?

olaf@wundersolutions.com (Olaf Alders) — Wed, 09 Sep 2026 00:00:00 -0400

Door handle designed by Jasper Morrison by JT at JMLtd, licensed under CC BY-SA 4.0.

I’ve had a closer look at what’s happening in the world of OSS security these past few months, and I’ve seen firsthand where vulnerabilities are turning up. What I find particularly surprising is that it’s not just in legacy code. CVEs are also turning up in brand new code that’s being uploaded right now. Just because we now have more tools at our disposal doesn’t mean that security issues are a solved problem.

How do we solve this problem? Probably via review. But review by whom? Maybe you use an LLM. Or a friend who is interested in security. Possibly your ecosystem already has a program with engineers you can request reviews from. It could be all of the above.

#LLMs cut both ways

While LLMs are very good at finding exploits, they are also really good at creating them — just like humans. The cynical approach to this says that of course vibe-coded software will be riddled with errors, but to be fair, the vibe coders also have defensive tools at their disposal. They’re either not using them consistently or stuff is just getting through — in the same way that you can get a security review from your very annoying and brutally thorough colleague and they will likely still have missed something.

#Make security review a habit

If you use LLMs, one way to improve your odds is to get into the habit of invoking a specialized security reviewer on your new code. Here’s my standard security-review.md which might give you a starting point if you’re looking for inspiration. At the end of the day it’ll come down to what your LLM skills are directing the agent to look for but also which model you are using to implement the skill.

Depending on which model you are using, you may want to avoid doing things like asking for a proof of concept. Certain Claude models have been known to deny the request or even lock you out of your account. (I have that as first-hand anecdata). If you’re serious about doing security research and you use Claude, you may want to look at Anthropic’s Cyber Verification Program.

#Scan the code you already have

As an interesting exercise, try pointing an LLM scanner at your existing code. You may be surprised at what you find, and maybe you can even ship fixes before the security researchers find them. For example, just a few days ago I found security hardening worth doing in diff-lockfiles while making unrelated changes.

#Ask for help

Your ecosystem may already have a program you can turn to:

If you’re involved with one of these ecosystems or already know a security researcher, ask them to scan your code and send you the results. Or ask a human to review it the old-fashioned way — that has worked for decades and is still a fine choice.

Read on website

Code Review Is the Hard Part

olaf@wundersolutions.com (Olaf Alders) — Sun, 26 Jul 2026 00:00:00 -0400

There is currently some recognition of the fact that with code creation having become cheaper, the burden of code review has not necessarily become easier. This is especially the case for people who get LLM-written pull requests who don’t use LLM tools for review. I can only imagine how exhausting it must be. I have only seen one complete waste of time pull request on one of my projects, but it was pretty irritating. Having said this, for some of my projects, review has been the hard part for many years already. It’s often easy to send a drive-by pull request but it can be much harder to find a competent, careful reviewer who is familiar with a whole bunch of RFCs, some superseding the others, who can say “this is correct and probably won’t break a bunch of legacy code you don’t know about”.

Add to this the fact that you don’t get much credit on GitHub for “spent X hours in careful review of brittle pull request that had Y sharp edges that the contributor never considered”, but you do get kudos for every one of the low effort pull requests that you send (I’m looking at you, Hacktoberfest).

"Using a Magnifying Glass and Driving" by Mike "Dakinewavamon" Kline is licensed under CC BY 2.0.

If you’re doing it for the likes, then code review is not the way to go, even if it’s equally as important as writing the code.

I don’t have an actual solution for this. I’m just saying that the gatekeepers in my universe seem to be in short supply.

Do I use LLMs for code review? I do, but while I might trust the LLMs to find a lot of the problems in a pull request, I don’t trust them to find all of the problems and I certainly don’t trust them to be the final arbiter of code correctness. For any non-trivial change to Open Source code that actually matters, I don’t see a good way to keep a human out of the loop. I write a lot of Open Source that doesn’t matter, but if it’s actually something that people use, I feel a responsibility to make a best effort not to explode whatever they’re working on.

Read on website

GitHub Copilot Chat: First Impressions

olaf@wundersolutions.com (Olaf Alders) — Thu, 29 Feb 2024 00:00:00 -0500

Recently I got access to GitHub’s Copilot Chat. I had seen a demo of it back in December and was very impressed with what it can do. Since getting access, I have been trying to figure out how (and if) Copilot can help to improve my productivity.

Nota bene: This article is not an advertisement for AI. I am aware of many of the caveats when it comes to AI, but in the short term I am interested in seeing how I can get a genuine positive result from it.

Initially I did not think yet another article on AI would have any point. If you read Hacker News, you may be of the opinion that everyone is using AI already, but that’s not the case. Many smart, competent software developers do not use AI (yet?). Some of them may not be aware of how they can leverage AI and some may simply be wary of all the hype.

My plan is to share some practical examples. This won’t be a “how to” article, but rather a higher level overview of what might be possible. I won’t be going into details about exactly which prompts I used to get my results. I will leave that as an exercise for the reader. It is my hope that I’ll give you enough information that you can judge for yourself if it is worth your time to play around with this.

#My Setup

I have been using Copilot for completion for a few months now. My setup is neovim + nvim-cmp with the following plugins:

That mostly works for me. Sometimes the completion is a bit funky. Opening up related files to give Copilot more context is helpful. For me, Copilot is a net positive, but it can be a bit of a slog sometimes.

In order to use Copilot Chat, I opted to set up VS Code with the following plugins:

GitHub Copilot
GitHub Copilot Chat

This means that I need to live in VS Code when using Copilot’s Chat features. This is not ideal, but so far I accept the trade-off as necessary and I am not grumbling about it. I am still in neovim when VS Code is not required, but with all of the file reloading, they are playing nicely together for the most part.

I should note that CopilotC-Nvim/CopilotChat.nvim does exist. I haven’t tried it as I wanted to get up and running in a hurry. neovim purists may prefer it.

#Building a New Jekyll Site

As you may be aware, I am looking to pick up some freelance work right now. I have had some success, but there is still room in my schedule. I have not actively looked for work in some time. My web site did not look very modern and the listed skill set was dated – I have not written an iOS app in years.

My site was deployed using a web application framework, but I no longer need to do anything dynamic. Time to find a static site generator. Jekyll is a very mature site builder with lots of available themes, so I started there.

First, I settled on a theme.

I like the look of it. It has a lot of GitHub stars and a small number of open issues and pull requests. I extrapolate wildly from this that people are using it and not having a great deal of problems. That’s good enough for right now. It’s going to be a huge improvement.

#Installing rbenv

I needed ruby to run my Jekyll build locally. I’ll want to be able to edit my site on more than one machine, so I quickly wrote an installer script to install rbenv if needed and then to install an arbitrary version of ruby if needed. I used is, which is a command line tool which I recently wrote. I am quite happy with how simple and readable this script turned out to be. If you’re curious about is, I have written an introduction to is not so long ago.

#Replacing Google

As I was exploring what I needed to do, I used Copilot Chat as a Google replacement, asking it the kind of things I normally would have searched Google for. That went very well. I got good information without having to wade through a top result from W3Schools followed by lots of mediocre Medium posts and dated Stack Overflow answers.

Using Copilot as my search engine has the added benefit of not requiring me to leave my editor. Once the response has been generated, being able to directly replace code with Copilot’s suggestion is a nice little productivity feature as well.

Aside from not needing Google for good information about how to set up Jekyll, I have found Copilot to be powerful when doing mundane things like scaffolding config files. I can say something like “Give me a best practice eslint configuration” and I might see an answer like this:

{
 "env": {
 "browser": true,
 "es6": true,
 "node": true
 },
 "extends": ["eslint:recommended", "plugin:react/recommended"],
 "globals": {
 "Atomics": "readonly",
 "SharedArrayBuffer": "readonly"
 },
 "parserOptions": {
 "ecmaFeatures": {
 "jsx": true
 },
 "ecmaVersion": 2018,
 "sourceType": "module"
 },
 "plugins": ["react"],
 "rules": {
 "indent": ["error", 2],
 "linebreak-style": ["error", "unix"],
 "quotes": ["error", "double"],
 "semi": ["error", "always"],
 "no-console": "warn",
 "no-unused-vars": "warn"
 },
 "settings": {
 "react": {
 "version": "detect"
 }
 }
}

We can argue about whether or not this really is best practice, but I do not have strong opinions on this. At the end of the day I just want code that is consistent and this gives me a starting point, since it’s in my nature to fiddle with settings. Also, VS Code tells me what the config file should be called. That may seem trivial but on more than one occasion I have struggled with figuring out why some tool is not working only to realize the file needed to start with a dot.

Looking back on this, I could have refined the prompt to say that I’m not using React, which should have pared down the file a bit, but for an 80/20 approach where I try to get the main things done now and I get to fiddle with it later, superfluous settings in a config file aren’t going to keep me up at night.

#Front End Design

As I was working on the layout, I asked Copilot for help in tweaking the layout. It helpfully gave me advice and generated CSS to go with it.

#Asset Upgrades

As I took a closer look at the theme, I saw that some included assets were very old.

Bootstrap (3.2.0, released in June 2014)
jQuery (1.11.0 from January 2014)

Everything still worked, but this seemed like a fun chance to experiment with Copilot. Could it do the right thing or would I be stuck in a world of find and replace? Time to find out. I upgraded the Bootstrap assets and asked Copilot to upgrade the CSS usage to Bootstrap 5. To my surprise, that mostly just worked.

As for jQuery, I asked Copilot to convert it to pure JavaScript. That worked very well, requiring very little intervention from me. I even eliminated a third-party library in the process. jQuery was not bringing much to the table here and I was able to eliminate a pretty large dependency. So far, so good.

#Asset Creation

I then used Microsoft Image Creator to come up with some artwork.

Again I was quite happy with the result. The image creation has some limitations. It seems to want to give me blue eyes, even when I ask for brown. It also makes my White Shepherd look more like a Husky, but that feels like quibbling. In real life she often gets called a Husky, occasionally even by Husky owners.

#Responsive Design

The only remaining issue was that the layout did not work consistently across various device resolutions. Copilot could not help me with this, partly because I lacked the vocabulary to describe the problem. Luckily a very generous friend gave me the help that I needed to get this little problem sorted out.

#The End Result

Over a few hours on a Saturday and Sunday, I was able to switch to a brand new site, run by a static site generator. When I push my commits, the Jekyll site rebuilds and publishes via GitHub Pages. It all requires very little intervention from me. As someone who does a bit of web hosting, it might seem weird that I am not dogfooding my web site, but at this point in my career I am more interested in the right tools for the right job. Occasionally I enjoy an overly complicated hobby project, but this ain’t it.

#Lessons Learned

Now that I’ve used AI to kick-start a rapid web site replacement, what have I learned?

#Trust, but Verify

Copilot will tell you things with such confidence that it can be jarring when it is clearly wrong. I recently gave Copilot a bit of Ansible config which updates a system configuration file. I asked for this to be converted to an equivalent bash one-liner. Copilot was more than happy to do this. The caveat was that the resulting code was set up to blow away the original multi-line system file and replace it with the one line I was trying to add. I did not get caught by this bit of misinformation, but caveat emptor.

I haven’t been using Copilot in anger on really gnarly or convoluted code. Copilot cannot get context from all of the code in a really large project. The bigger and more complicated your project is, the greater the possibility that you’ll get less than helpful output from Copilot. Just as you would not blindly copy/paste a Stack Overflow answer into production code, you don’t want to ship Copilot suggestions without proper scrutiny.

#Copilot Can Tidy Things that Tidiers Possibly Can’t

I love tidiers and tidying. I talked about this a bit in my post about typos. I have long been frustrated by the lack of tidiers which are template-aware. Copilot did a great job of respecting Jekyll template syntax when I asked it to reformat the HTML in the files. I am hopeful it is equally good at Go and Perl HTML templates. Even if it is currently not, I am confident that this is on the horizon.

#Mundane Tasks Become Less Soul-crushing

I recently wrote two Playwright tests in TypeScript which were largely similar, but with important, subtle differences. Copilot not only refactored these to allow them to share common code, but it actually created table-driven tests for me. The result was so much cleaner and more maintainable than what I had started with. The practical benefit is that I hope I am in a position where I do not always have to write code with the inevitable refactor in mind. I liken this to the fact that I rarely format my own code these days. I just write something that’s mostly readable and I rely on a tidier to enforce style.

The wider implication is that if I am asked, in the parameters of a code review, to do some tedious task that I really do not want to do because “why are you asking me now when you could have saved me a bunch of time by mentioning this earlier”, I can ask Copilot to implement the request for me. If it works, everybody wins. If it does not, then I still have the choice to punt on the change if I think it can wait or to dig in and try to refactor the code myself.

What that means to me is not having to spend mental energy on things that do not matter that much. I can lose a lot of time dealing with code review nitpicks that I often do not have the energy to argue against. Now I have a chance to see if my new toy can implement the request for me.

#Legacy Projects Get New Life

I recently realized that the landing page for the Perl Advent Calendar looked quite dated. If you looked at it you would be forgiven for thinking the calendar was possibly abandoned. We published a full calendar of articles in 2023 and 2022, so it’s anything but abandoned.

I asked Copilot to modernize the design and it did so quite happily, giving me a workable result on the first try. I then asked it to add some JavaScript to redirect to a different page in December and January of any given year. These are all things which I could have done myself, but I did not want to.

You can argue that this kind of work isn’t hard. It’s not really, but it was onerous enough that nobody did it for many years. I liken this to taking on a task myself or having an intern do it. If the intern does it, I still need to explain the problem and check the work, but it frees me up to do something else in the meantime. If the intern is effective, it’s a time saver. If the intern needs a lot of help, then I haven’t gained much at all. I need to figure out what the intern can handle and then assign appropriate tasks.

With refactoring and modernising of code becoming easier to handle, the burden of maintenance decreases. Perhaps projects which have fallen into disrepair can more easily be revived.

#Creating Tabular Content

I love Markdown tables, but boy do I not enjoy creating them. Let’s try it with Copilot.

Create a markdown table of the names of the 12 months of the year. Each row represents one month. The columns are the month names in Latin, Italian, Spanish, French and German

Surprisingly, we get what we asked for.

| Latin | Italian | Spanish | French | German |
| ---------- | --------- | ---------- | --------- | --------- |
| Ianuarius | Gennaio | Enero | Janvier | Januar |
| Februarius | Febbraio | Febrero | Février | Februar |
| Martius | Marzo | Marzo | Mars | März |
| Aprilis | Aprile | Abril | Avril | April |
| Maius | Maggio | Mayo | Mai | Mai |
| Iunius | Giugno | Junio | Juin | Juni |
| Iulius | Luglio | Julio | Juillet | Juli |
| Augustus | Agosto | Agosto | Août | August |
| September | Settembre | Septiembre | Septembre | September |
| October | Ottobre | Octubre | Octobre | Oktober |
| November | Novembre | Noviembre | Novembre | November |
| December | Dicembre | Diciembre | Décembre | Dezember |

Will we double-check the spelling before using this in anger? You bet we will, but if we had typed this by hand we would have checked it anyway.

If we want this table in HTML, we say “convert the table to HTML” and it is done. Likewise, we can ask for a CSV:

"Latin","Italian","Spanish","French","German"
"Ianuarius","Gennaio","Enero","Janvier","Januar"
"Februarius","Febbraio","Febrero","Février","Februar"
"Martius","Marzo","Marzo","Mars","März"
"Aprilis","Aprile","Abril","Avril","April"
"Maius","Maggio","Mayo","Mai","Mai"
"Iunius","Giugno","Junio","Juin","Juni"
"Iulius","Luglio","Julio","Juillet","Juli"
"Augustus","Agosto","Agosto","Août","August"
"September","Settembre","Septiembre","Septembre","September"
"October","Ottobre","Octubre","Octobre","Oktober"
"November","Novembre","Noviembre","Novembre","November"
"December","Dicembre","Diciembre","Décembre","Dezember"

Of course you can already do this with bash/sed/awk/jq or what have you, but not everyone views command line data transformation as a rewarding hobby. Now you have the option of getting arbitrary tabular data just by asking for it. It’s one more tool in your toolbox.

#Code Review

Looking to the future, I see how Copilot could be useful when it comes to code reviews.

#Ask Copilot to Explain Code

If I check out the branch I am reviewing and select some code with a language feature I do not quite understand, I can ask Copilot to explain it to me. (If I am asking it to explain some convoluted code, that’s a red flag for the review, but it can still help me get from A to B). I see this as potentially a significant time saver, but not a replacement for an in-depth review by a human.

The same pattern can be applied to SQL. If you’re dealing with a lot of nested subqueries, CTEs (Common Table Expressions) or someone who treats SQL as their favourite programming language, then Copilot can help you untangle the logic. It’s no replacement for trying to understand the code yourself and it’s not always going to be 100% correct, but it’s nice as a second opinion. I expect this functionality will also improve with time.

#Ask Copilot to Suggest Improvements

On a similar note, I can select some code and ask Copilot to suggest improvements. This may bring up some points which I had not previously considered. Again, it is not a replacement for the human review, but I imagine this could find issues which may get glossed over otherwise, based on who is reviewing the code.

Taking this one step further, I can ask Copilot for code suggestions before submitting my own code for review. This can catch issues before we start the code review feedback loop. The more I can prevent a lot of back and forth in a code review, the better placed I am to get it merged quickly. So this could be a time saver as well.

#Improve Copy

Copilot can suggest improvements to documentation or even plain web site copy. When I tried this, the suggestions were a clear improvement, turning awkward turns of phrase into something more easily readable. This can be useful in the proofreading phase, especially for non-native English speakers. (I have no idea how it performs in other languages.) I do often come across technical blog posts where the author’s language skills get in the way of the point they are trying to make. This could be a very useful tool in that case.

#That’s a Wrap

There is a lot of concern about the explosion of AI and I think that these discussions are generally good to have, even if I am not going to get into that here. As far as some of my other successful experiments, there are still a number I did not even get to today. One of my most positive experiences has been with using AI to sell items on Kijiji, but there is too much to explore there. Maybe that’s a subject for another day.

If you’ve made it this far, thanks for sticking with me on this meandering journey – it has been an enjoyable ride.

Read on website