Last updated on

Fragments: October 10

I’m trying out a new format with this post inspired by Martin Fowler’s fragments.

I’m currently reading How Linux Works by Brian Ward. There were two chapters I found particularily interesting today.

The first one was on file systems and how the way we see file systems as users is a tidy illusion. Files aren’t really neatly organized together in a tree of directories in the storage medium. Their data instead reside somewhere on the medium and are linked to each other via inodes (index nodes). When you create a hard link on a GNU/Linux system, there’s just one inode that describes both files, because they really are the same file, even though they reside in two different directories.

The other interesting chapter talked about how the Linux kernel boots. The first thing that starts is the BIOS/UEFI, which in turn starts the boot loader. The latter looks for the Linux kernel on the machine and starts it by putting it in memory. The linux kernel starts the init process, which is often systemd. What blew my mind is that, obviously, the boot loader itself has its own kernel, just to start the actual Linux kernel. It’s kind of a chicken and egg problem.

I was working on a big PR at work this week and I wrote the first part by myself, but for the second I used AI, in part to try out Kepler by GitKraken. I’m still figuring out the best way of using AI for myself and I kind of messed it up with that PR.

The amount of code and complexity grew very fast as soon as I started using an agent. It was also code in an area of the codebase that I hadn’t worked with yet. At some point I thought I should split the PR in half, but it was too late then, because the Git history had advanced too much. I ended up with a big PR that I had to review myself first and that I still don’t completely understand.

I’m trying to use this as a lesson. There are three rules I want to obey in the future:

  1. Let the AI agent generate the code only if you know what the code is going to look like and how it’s going to work.
  2. Break down AI tasks into chunks that can be understood and reviewed easily.
  3. Always have the AI agent tell you its plan before letting it generate any code.

My mentor at work recommended I lean in more into Matt Pocock’s skills, because he’s trying to achieve exactly what I’m looking for, which is a reproducible framework for working with AI agents.

I noticed that AI agents write very weird and useless tests sometimes and often the tests are too close to implementation details. In the same way that an agent clutters codebases with comments that only make sense if you were part of the session in which it implemented that part, agents like to write tests when you correct them in a session just to prove that whatever you asked for is now working the new way, which is completely dumb.