I have seen the same story play out several times: the organisation suffers a major incident or security breach, and it is decided that to prevent it happening again, all systems must check a list of boxes that are considered good. A few unlucky employees are then tasked with reaching out to everyone else to ensure that their software adheres to the established dogma. A dead giveaway of checkbox engineering is the dreaded spreadsheet with systems on one axis and desired behaviour on the other. ...

My dear friend Markus once said something that resonated with me: “I don’t want to be blocked”. I appreciate framing blockers as a choice because it emphasises progress and places the responsibility of shipping squarely on me. Virtually all projects eventually run into blockers. Perhaps a different team needs to add a new field to their API response, or the internal synthetic monitoring tool doesn’t support MCP servers yet. Whatever it may be, I find there are three ways to react: ...

I am afraid of accepting AI-generated code without reviewing it. Why? I suspect this fear stems from an inability to automatically verify the correctness of the code’s behaviour. Style and obvious errors can be tested with linters and unit tests, but there is a host of advanced failure modes that are much harder to capture: race conditions1, memory leaks and subtle performance regressions. These types of issues are why I am compelled to manually review code. ...

One of my favourite things is learning new terms. When my brother introduced me to the Overton window the other day, I knew I had to shoehorn it into a blog post. I have always been a strong proponent of code review; I enjoy receiving a thorough review, and I have taken pride in my ability to deliver high-quality feedback too. Had you asked me a year ago, I would have been adamant that all changes must go through human code review, which also seemed to be the prevailing sentiment in the industry at the time. Now, I am not so sure. ...

Throughout my time working with complex distributed systems, I have learned that consistently detecting systemic issues is surprisingly difficult and a bit of an art. The canonical way to do this is to set up alerts that notify an engineer when something is wrong. I have personally written many terrible alerts and regret having subjected myself and colleagues to the pain of such useless alerts. Core Tenets My opinions on alerting revolve around three tenets. ...

Since the start of my career, I have found it important and feasible to unplug completely when I take time off from work. The speed with which the AI space moves is making it more difficult than ever to truly unwind. There is a torrent of information and news released every day about exciting new developments in the field. In the past, I was not concerned about missing a killer new Postgres feature or the latest version of Go while on vacation, but with AI, it feels like I genuinely might fall behind if I go offline for a few weeks. In an informal poll, 70% of my colleagues responded that AI is making them feel more stressed. The issue is exacerbated by the fact that I am fascinated by AI and enjoy learning new things about it; I want to keep up. I feel a slight dopamine rush when I see a blog post about some cool new way to apply skills or the release of a feature like agent teams. ...

One of my least productive traits is my propensity for getting caught up in YouTube binges. Every once in a while, a scene from Moneyball will pop up in my recommendations, and I have no choice but to tumble down the rabbit hole. For the uninitiated, the movie is based on the book Moneyball: The Art of Winning an Unfair Game and chronicles the Oakland Athletics baseball team’s journey to build a competitive roster using sabermetrics. There’s just something about this movie that makes its scenes endlessly rewatchable. I have only watched Moneyball from start to finish once, but the amount of time I have spent watching snippets online would make one think it was my favourite movie of all time1. Ironically, I don’t even understand the rules of baseball and have no particular interest in the sport. ...

These are some of the opinions I have formed through years of working with CI/CD pipelines. I have worked primarily with GitHub Actions, so that is what I will focus on. My philosophy on pipelines revolves around these core principles: Developer experience is king. Optimise accordingly. Engineers follow the path of least resistance. Given the same input, a pipeline run that succeeds today must also succeed in a year. Pin Dependencies When specifying dependencies in an action, pin them to a specific version. This goes for not only downstream actions, but also the runner itself as well as any packages manually installed: ...

A topic that concerns me at the moment is keeping agentic AI workflows both secure and productive. Over the past few months, I have been using Claude Code as my terminal agent of choice, and I have found it difficult to balance security with productivity. The ultimate goal is to remove all permission prompts without compromising security. The exact amount of security one is willing to trade for productivity will vary across companies and industries. As in many other areas, it is not possible to have both perfect security and perfect productivity, but we should still strive to optimise for both. ...

Working in an enterprise as vast as Maersk, much of my time is spent gathering information from a myriad of different sources. Recently, I have been making a determined effort to document organisational processes and tribal knowledge in my agent instructions file. How do I get access to a new Kubernetes cluster? How do I consume an API via our common gateway? Where do I find the credentials for our git bot? I figured that even if the agent couldn’t put this knowledge to good use, it would at least serve as a useful reference for me. This concern turned out to be unjustified; modern agents are great with this kind of information. ...