{"id":5960,"date":"2026-08-18T14:30:00","date_gmt":"2026-08-18T12:30:00","guid":{"rendered":"https:\/\/engel-wolf.com\/?p=5960"},"modified":"2026-11-08T21:22:04","modified_gmt":"2026-11-08T19:22:04","slug":"time-tracking-is-hell","status":"publish","type":"post","link":"https:\/\/engel-wolf.com\/?p=5960","title":{"rendered":"Time tracking is hell (I just spend less time there now)"},"content":{"rendered":"\n

Time tracking is hell. Especially for developers. At the end of the day Jira wants to know exactly how many hours I spent on each ticket, and my memory wants to know why I’m asking it.<\/p>\n\n\n\n

\"Comic:
Time tracking can be hell.<\/figcaption><\/figure>\n\n\n\n

The irony is that my tools already know most of it. GitLab knows when I pushed to which repository and which commits mention which ticket. It knows which merge requests I was assigned to or reviewing. Jira knows which tickets I commented on. The whole day is there as an activity trail. I just never looked at it when filling in hours. So one Monday in July I asked Claude Code to turn that trail into a draft I only have to correct.<\/p>\n\n\n\n

The before<\/h3>\n\n\n\n

I’m lazy about admin routines. I rarely log time daily. Sometimes weekly, sometimes much later. That morning I had set my team a goal of logging something on every working day, and our internal team dashboard (a small Next.js app with Jira-based evaluations) was about to show everybody’s missing days. Including mine. The first prompt of the session was harmless:<\/p>\n\n\n

\nThis repo contains a tool in the "evaluations" route that allows to check the time tracking.\n\nI set my team a goal to track all workdays of the year\n\nSo we need to introduce to the table in "hours tracking"\n\n1) a calculation of workdays in the time-frame (taken from a clever api that can tell you holidays in Bavaria Germany). Workdays are only Mo, Tu, We, Th, Fr in our company.\n2) Show how many unlogged work-days there were. I want my co-workers to log at least on one ticket per day\n<\/pre><\/div>\n\n\n
Claude picked a free public-holiday API and filtered it to holidays that are either nationwide or list the Bavarian region code. Then it counted. A few prompts later, after a „My Calendar“ tab with my GitLab pushes per day, I saw my own number, and the real project started:<\/p>\n\n\n
\nok. now that you see that. I have my gitlab pat in &lt;env file>\n\nCould you do me a favour and make a little proposal\n\nSo I have 102 missed days this year. I basically need a tool to show\n\n1  - headline day, subheadline proposed ticket id\n2 - proposed ticket summary\n3 - commits (number, max time diff between commits)\n4 - slider - hours to log on ticket\n\nThat way, I could have a view with all my unlogged days and create an output file, that allows me to log\n\neach day row should have a (+) icon that allows to add a row by selecting a ticket via dropdown. can we make this at a seperate route "\/ai-time-track"\n<\/pre><\/div>\n\n\n
102 days. In July. That is the number that makes you build tools. The prompt worked well because it describes the screen, not the algorithm: a row per day, what’s in the headline, what’s in the subheadline, a slider. Point 3, „max time diff between commits“, turned out to be the seed of the whole estimation heuristic.<\/p>\n\n\n\n
Tightening the rules<\/h3>\n\n\n\n
The first version proposed one ticket per day with an hour value nobody could actually book. Two short corrections fixed that:<\/p>\n\n\n
\nsingle commit is at least 30min. slider should be at the proposed time rounded up to 30min slots. we can only do 30min\n<\/pre><\/div>\n\n
\nright now we only have one line per day. But, I need one line per day + ticket. Of course each day can have 1 or 10 sub-rows.\n<\/pre><\/div>\n\n\n
These are the kind of domain rules an agent cannot know: our time tracking only accepts half-hour slots, and a day is rarely one ticket. Then I got suspicious about where the tickets came from at all and asked a question instead of giving an order:<\/p>\n\n\n
\nHow do you determine all issues in the timeframe? My guess is - check all the user was assigned to + check all the user interacted with + all that were mentioned in commits ids...or what did you do?\n<\/pre><\/div>\n\n\n
Asking „what did you do?“ is underrated. The answer showed it only read branch names and the last commit of each push, which missed a lot. The result is the „scan depth“ switch in the final tool.<\/p>\n\n\n\n
The heuristic<\/h3>\n\n\n\n
Here is how the estimate actually works. It is deliberately dumb, which is why I trust it.<\/p>\n\n\n\n