Granularity-Driven Development

　I’ve finished hacking all the equipment I have on hand. Since my funds are a bit tight, I’ve been working on ways to make even better use of my peripherals for a while now. If I clearly define what I want to do, all I have to do is give instructions to AI, and it’ll handle the rest. It all depends on how I give instructions to AI.

　The AI I’m currently using offers a free tier. Of course, if I had the money, I could pay to use it, but as mentioned above, I don’t have any funds. So I’m using the free tier—that’s right, I’m a free-to-play guy. The horror of not spending money is that you’ll hit the token cap before a task is completed, and it takes time for the tokens to replenish (the recovery time for Claude code, which I use frequently, is about 3 hours). On the other hand, if I break tasks down into tiny pieces, I end up in an absurd situation where I hit the limit even within the smallest parts of small tasks (which I consider atomic).

Just like with a regular job, you’re expected to find a natural stopping point. The challenge lies in determining the appropriate granularity for dividing tasks. Dividing tasks along a timeline goes without saying. In addition, when tasks no longer interfere with one another, they are divided in parallel to reduce the workload of each individual task. This is granularity-driven development.

There’s no point in lamenting a lack of funds. Funds, storage, and time are always in short supply.