I stopped writing the devlog, but the writing didn't stop

The last thing I published here was August 16. Two entries have been drafted since and neither went up, and nothing has been drafted since August 22. In that August 16 post I wrote: "No pile of unpublished drafts allowed after tonight." There is now a pile of unpublished drafts.

I'm not opening with an apology, though. This wasn't a discipline failure. I set out to do something, the project changed shape under it, and I changed my mind without saying so. Changing my mind is fine. The without saying so is the part worth fixing.

Where the time actually went

The commit log makes it look like I've been coding. But like most devs these days, I've been reading.

Between August 22 and tonight, 31 pull requests merged in the app repo and 46 commits landed in the private one that plans it. I didn't type most of that. I read it, argued with it, refused parts of it, and wrote down why — which is the real bottleneck of this build and has been for about a month.

You could call the front half of that vibe coding. It isn't, and the difference is the whole job: the code arrives fast, and then someone has to decide whether it's true. Last week that meant deciding that a stale API key was why production couldn't reach the routing service, not the cloud-region block it looked like — a theory that took a Frankfurt deploy to rule out. And that a rest day genuinely can't be derived from the data we have, so the feature ships without one rather than inventing one.

Both of those got written down with the reasoning attached, because a decision an agent can't read is a decision I get to make again next week, differently.

That's writing. Not great writing, but writing anyhow, and it never stopped. It changed audience.

Why the devlog is the thing that loses

Honestly? By the end of a long build session I can't be bothered to write about it. I want to keep building. There are beta users waiting on something they can actually use, and an evening spent writing up progress is an evening I don't spend making any.

Then if I rank the writing tasks by what breaks when they don't happen, the devlog is at the bottom.

A decision I don't log means I have the same argument again in three weeks, or silently reverse it. A hazard I don't file means a bug ships. A devlog entry I don't write changes nothing about the build at all — it's the only thing I write whose reader isn't in the loop of what gets made.

The rule was written for a slower build

My own notes say a daily entry should cost ten minutes; if it wants to be longer, it becomes a proper post instead. That was written for a project moving at one small task a day, which is how this one started.

It doesn't move at one small task a day any more. A single evening now produces a routing proxy, the composition math behind it, and two follow-up bugs found by looking at the thing on a phone. Ten minutes doesn't cover it, ninety would, and ninety minutes is a build session. So the log kept losing to the thing the log is about.

The app I'm building refuses to lie about exactly this shape of problem. Ask it for a mountain in six weeks that needs sixteen and it won't compress the ramp to make the calendar work; it tells you the goal isn't reachable and offers the best plan that is. Strange to run that rule for users and not for myself.

So the daily entry isn't the commitment any more. Neither is clearing the backlog; there are four drafted milestone posts in a folder and I may never publish any of them. They already did their job. Writing the auth one is how I worked out that authentication is a per-asset question answered by blast radius. A draft that changed my mind doesn't owe anyone a publish button.

What I'd rather write is short. One idea someone else can use, and the story that made it true. If it doesn't clear the bar of would this help somebody who isn't me, it stays in the repo where it's already useful. I hope I can stick to this at least.

What the eleven days were made of

All merged and live, August 22–27:

• Route generation — the app can now build a route instead of only picking one from a list: city stairway data ingested, round-trip candidate generation, elevation profiles and effort scoring, stair-and-hill content scoring, an eval harness to say whether any of it is any good, candidates on a map, and a dispatcher that picks your next session.
• "Train from here" — a routing proxy, composition math for a full midweek session, "Route me there" on vertical sessions, "near me" on browse and on plan candidates, a map picker, a fix for the assumption that everyone trains where they live, and a screen that answers only "what am I doing today, and where."
• Data — Amsterdam and Houston seeded, 28 routes, all marked unverified because I haven't walked them. Six Seattle stair spots given real city coordinates using SDOT.
• Infrastructure — a production 403 chased down to a stale key rather than the region block it resembled; route generation pinned to Frankfurt instead of the platform default; the beta gate rewritten as a capability check rather than a name check.
• Quality — the 390×844 mobile audit my own guidelines have required since day one, run for the first time; a 46px horizontal scroll and a stock-framework 404 fixed; 32 user-facing strings reviewed line by line, 31 approved and one refused; 447 hard-coded colours replaced by 5 semantic tokens; and the plan screen rebuilt to open on the week you're actually on instead of week one of forty — same plan, 653 KB down to 118 KB, and no tap target under 44px where there had been 383.

Good five days. Just no devlog entry... and pretending otherwise for eleven days is what this post is for.