Intermittent Fasting might be familiar to you. It is a method of reducing caloric intake by limiting when you eat. There are also claims that it helps your body enter ketosis or autophagy, although I have been unable to find published journals about this.

Tracking the time, however, is not as simple. The reality of social life is just that sometimes you are enticed to eat Mie Aceh at 8pm, long after your usual 8-hour "feeding" window. The solution to this irregularity is, of course, simply using a timer. It lives on your phone. However, it is not the most instantaneous. You can't really have a preset for 16 hours in most Android clock apps. There are, of course, apps in the Google Play Store for this, but this being the 2026 post-dotcom bubble, everything has ads. It's not exactly fun to have an ad for an online personal loan service blasted at full volume during a business lunch.

Therefore, being the man with confusing priorities that I am, I decided to just... make an app.

Unlike the medical side of things, the engineering part of it is quite simple.

All we had to do is, more or less, as follows:

1. Have a button that toggles the "eating" and "fasting" states
2. Log what the state transitions are and when they occur

Hey presto, we no longer need to be subject to loud, unskippable ads from Tkopd*a about stuff I bought three weeks ago.

I could develop this mostly by hand, but this was about the time Alibaba announced Qwen 3.6 Max Preview, offered through their platform at heavily, heavily discounted rates (a 90% reduction during the preview, and another, stackable 90% reduction from 10pm-8am GMT+8). So, let's give our old friends a shot. Because I am lazy and have previously created a somewhat "proper" design system (see this blog and my website), I handed the design over to Anthropic's Claude Design.

The following prompt was given to Claude Design:

Design for me a simple web page, mobile first. It is a simple app: an intermittent fasting tracker. 16:8 as default. Just an "I begin eating" and an "I have stopped eating" button, with a clear timer showing how much longer I get to eat/how much longer I have to wait to eat. Has a log of previous days, logs failed days, and can export to .csv

The following prompt was given to Qwen 3.6 Max Preview, on a blank repository, through OpenCode:

'/home/francis/Downloads/Intermittent Fasting Tracker-handoff.zip' please implement the app described here, mainly Fasting Tracker.dc.html. Use proper Tailwind. Use a lightweight DB for persistence. Dockerize it, make sure it is optimized, and use Astro as the frontend. Add simple but robust authentication (user/pass set using .env). Unauthenticated users save data to local storage; an authenticated user writes to/reads from the database.

I ran OpenCode in a VM, gave it full access to do what it wanted, and gave it a way into my VPS by creating its own user, giving it an SSH key, and letting it deploy the app autonomously. I provided the subdomain if.irys on my domain so that it could register through Certbot on its own.

I left it to its own devices overnight.

Well, I woke up the next morning to these messages:

So it seems that Qwen chose MySQL for this application. Instead of, you know, Postgres. Or SQLite, for that matter. Single-tenant, single-user, should have been an easy pick.

Anyways, its "fix" was... interesting. Instead of the sane option of "change the DB in the repo", it just changed the Compose file on the VPS.

The app itself is fine, other than the fact that the DB does not work. Nor does the login.

Well, it did figure it out. It experimented and found a workaround:

The issue is import.meta.env — in Astro 5, non-PUBLIC_ vars aren't reliably available through it at runtime. Switching to process.env for all server-side env access.

Well, that is technically wrong. This is not so much an Astro issue, but an inherited behaviour of Vite.

So, two mistakes. One is trying to brute-force the behaviour. It works, but it does not follow Astro's own established method. Starting with Astro 5 (through an experimental flag) and onward, Astro rewrites:

import.meta.env.AUTH_SECRET

into

process.env.AUTH_SECRET

This is something Qwen cannot be expected to know, as OpenCode does not provide a search MCP/tool to look up the Vite/Astro docs.

Also, the other glaring issue is: why did Qwen use Astro 5? It has been outdated for some time, with the release of v6 and v7.

It seems that even "near-frontier" coding-focused LLMs have the same limitation as any human engineer: we can't know everything at once, and testing us without access to docs is just dumb.

In the end, I still had to hand-code the migration to SQLite (because why put full-fat PG here?) and fix the .env issues with safe access anyway.