This is the second article in a series about using AI efficiently. In the first article we built tools to measure AI productivity with real session logs.

This time we'll look at a concrete case study: modernizing a 15-year-old homemade PHP blog in a single afternoon, with the help of Claude Code.

The blog you're reading right now was the guinea pig.

This is the first article of a series about using AI efficiently, with a focus on actionable and practical advice backed by real data.

In this first installment we'll look at how to actually measure the time you gain (or lose) when working with AI, using real session logs from actual work.

The twist?

This article is partially being written by the very AI system it's documenting, while working on the tools to measure its own productivity.

Meta enough for you?

My team of tester friends have been reporting issues for the last few weeks, and I've been busy fixing them.

Nothing impacts more a project than wasted time, and nothing impacts more the quality of the work than the iteration time between when something is changed and when you finally see it in the final game.

When it comes to text adventures and point-and-click games, less is often more. In this article I look at how adventure game interfaces evolved from complex natural language parsers to simple contextual actions, and why I chose a minimalist approach for Encounter.

When I started playing adventure games back in the 80ies, there were basically two types of game implementations:

• Games written as actual programs
• Games using some portable virtual machine or database
  

For some reason, people tend to think that creating multi-threaded applications in C++ is a very difficult thing to do.

It is in fact not that difficult, but there are basically two main issues to consider: How to make the code correct (it should not crash, deadlock, corrupt data, etc...) and how to make it efficiently use as many cores as possible.