Software

In general, I’m in favour of disclosing AI-generated or assisted code in commits. In recent months, I’ve been seeing more and more of them across various open source repositories, and it’s a good indicator to me on how the project was developed and is being maintained. I want to actively avoid using, relying on, or contributing to repositories that are AI-generated or heavily AI-assisted. Disclosing these tools, or at the very least mentioning they were used, in a commit message allows me to judge the work that was done. If the AI use is excessive, it’s a signal that any contributions I make would be insignificant to the overall project, or would be overrun by agents. It’s also a signal that the author might not care much for the project. Read more...

There are scripts that are designed only be run a handful of times, or maybe even once under rare circumstances. They are usually tested a lot of more times than they are intended to be executed, or when they are executed, their actions could be detrimental, this is where --no-dry-run option comes in. In my career, I seem to have worked on a lot of system, or application migrations. I’m not sure if this is very common outside of the places I’ve worked at or if I’m just a harbinger of change. Depending on the migration the approach changes but there usually comes a time when a cut over to the new solution needs to be done. The steps leading up to, during and after the migration are typically crucial with rollback procedures in place in case something goes wrong. These steps would have been tested thoroughly before hand by mocking the system in various states. But here’s the thing, the actual cutover happens once. To prevent prematurely executing the script it’s nice to have a second layer of acknowledgement, the --no-dry-run option. Read more...