I’ve never taken cocaine or any other similar drug, but I imagine it like something that makes you a lot more productive at the cost of destroying your body and making it impossible to stop. I sometimes wonder if Claude Code works a bit the same.

I’ve been actively using LLMs at work for ~6 months. We didn’t want to stay stuck with one model maker, so we tried various ones: one month with Claude Code, then one month with Codex, then another with another one, then back to Codex, then in June back to Claude — initially to test Fable, but they cut it out (yes, I use em dashes but I’m still a human).

Both GPT 5.5 and Opus 4.8 are pretty good, but I find Opus 4.8 easier to work with: it’s slower, but more accurate. In my experience, GPT is a yes man that almost never pushes back, and is always eager to add “a small helper” here and there to patch symptoms rather than spend time thinking about the right architectural solution. Also, I very rarely have to correct Opus: it does the thing right, with little code and useful comments, where GPT would add a ton of useless code with random comment stating the obvious.

The main question with this is: is this thing destroying me? Am I becoming dumb? Sure, I review all the code it produces, but nowadays I rarely code by hand; only when I know I’ll be faster. Could I work without it? “Of course!” I think, but in practice the last time it went down I was lost. Not that I don’t know how to code, how to think about architecture, patterns, deployments, pipelines and stuff, but I’m getting used to the pace of development with Claude and I don’t want to come back to my normal pace.

I’ve felt this in the past when I switched from vim to IntelliJ as my main code editor. It was 10 years ago; I still use vim for little things, but in any project larger than a few files I prefer to fire up IntelliJ. However, this only changed the tool I use to write code; it didn’t replace me. I’m at this point where I’m a bit afraid of how it’ll change me and at the same time I don’t want to stop using it.

There is no conclusion to this post; it’s still open: how will it affect me? Let’s see.

When I started this blog 13 years ago*, I went with Octopress, a framework built on top of Jekyll with nice defaults. It had some features built-in that would have required various plugins in Jekyll, and I remember being quite happy about it.

Unfortunately it didn’t last long, and its maintainer quickly abandoned it: the last commit is from February 2016. I kept it for a while because it still worked, although I had more and more issues due to several dependencies not supporting the latest versions of Ruby.

In the meantime, Jekyll continued to evolve while I was stuck forever with Octopress. I wanted to move to Jekyll, but nowadays I have little time for side-projects, and I’d prefer to work on ‘useful’ things rather than spend a lot of time migrating the blog from one stack to another, adapting plugins and custom code.

Well, nowadays painful migrations are not a problem anymore: I asked Claude Code to do it, and less than five minutes later it was done. Something that would have taken me various evenings was done in a few minutes. I do want to understand the code I generate with Claude Code or Codex, but in the present case the goal was to actually remove as much code as possible to use Jekyll’s defaults.

Will this be a new start for this blog? Maybe, let’s see.

(*): It was not my first blog; before that I wrote a few posts in French in 2011–2012.

In 2023 I wrote only one article on this blog, but a few more on the tech blog of the company I currently work for, Bixoto:

• Deploy Mattermost on Dokku
• Add Let’s Encrypt SSL Certificates on Private Domains with Dokku
• Always encode your Requests payloads in Python
• Install avifenc on Ubuntu 20.04
• How does Bixoto.com work?

This explains why the present blog might look abandoned. It’s not, it’s just that over the years I’ve reduced the time I spend on side projects and now 95% of my time doing technical stuff on a computer is during work hours.

March 2025 update: more posts:

• Monitor anything with Telegraf, InfluxDB, Grafana and Python
• Remove the expiry date on self-hosted Gitlab personal access tokens
• How we eliminated almost all the Cumulative Layout Shift (CLS) from our website
• An obscure intermitent SSH connection issue with Coolify

January 2026 update: even more posts:

• Mooving away from Coolify
• Migrating commands from Poetry to uv
• Proxying internal website traffic to a developer’s local machine for faster iteration
• Upgrade Mattermost Enterprise Edition to Team Edition
• Debugging iOS Safari from Linux

In 2023 I wrote only one article on this blog, but a few more on the tech blog of the company I currently work for, Bixoto:

• Deploy Mattermost on Dokku
• Add Let’s Encrypt SSL Certificates on Private Domains with Dokku
• Always encode your Requests payloads in Python
• Install avifenc on Ubuntu 20.04
• How does Bixoto.com work?

This explains why the present blog might look abandoned. It’s not, it’s just that over the years I’ve reduced the time I spend on side projects and now 95% of my time doing technical stuff on a computer is during work hours.

When using any library for Google Cloud you can specify a service account with GOOGLE_APPLICATION_CREDENTIALS, but unfortunately that doesn’t work when using gsutil in shell scripts. The documentation suggests to use gcloud auth activate-service-account, but that “activates” the service account for all gsutil invocations, and doesn’t work if you installed a standalone version of gsutil —without gcloud.

I wanted to have one service account per project so that each project has access to the relevant resources only. The solution I found is to use a Boto file: this is a ini-like file format used for AWS configuration, but gsutil also supports it. You can tell gsutil to find such file with BOTO_CONFIG or give it a list of paths to look in with BOTO_PATH.

In a simple project where the main code is a shell script, the setup would look like this:

$ ls -a
.boto
script.sh
service-account.json

In .boto:

[Credentials]
gs_service_key_file=/app/service-account.json

In script.sh:

#!/bin/env bash -e
export BOTO_CONFIG=/app/.boto
gsutil ...

This is a bit cumbersome compared to GOOGLE_APPLICATION_CREDENTIALS but it works well.