· 11 min
More hours than I should
Commits on 35 of 37 days, 45 after midnight and one laptop: where Novi Kvadrat’s pace came from, what it cost, and what I’d change.
Part 7 of 7 in the Building Novi Kvadrat series.
I usually work more than I should. I don’t follow the working hours. I believe in this project. I believe it will solve many problems people face.
The first six parts were about the product. This last one is about the pace. By 19 October 2026 the repository had 956 commits on its main branch, and its two busiest months, May and July, had about 190 each. The pace had three sources: a small team’s weekly loop, a lot of parallel work, and my own hours. Here is each of them, what they cost, and what I’d change.
The weekly loop
Novi Kvadrat is built by a team, and the week has a shape. The founder sets the product direction, and the general manager steers. Two customer-relations leads run QA on what lands and look after the content, and a growth manager works alongside them. The rest of the company gives feedback every week, and that feedback steers the next wave of work. I write the code with AI agents. On the front end, a team member and I usually check the product, and two teammates review the design work.
The product ran on a test domain first. In late July 2026 it moved to the main domain, novikvadrat.rs. It is still in beta, and not fully public.
The surviving logs show that loop arriving in my prompts. On 25 September I passed on stakeholder feedback that the homepage should be cleaner, with no long texts; Part 3 has what came of it. On 1 October I pasted a bug report under the heading “USER FEEDBACK:”, about the dropdown that attaches an image to a room in the listing editor: “This dropdown does not work when I want to scroll through it with mouse.” (My prompts are quoted with the spelling fixed and the words unchanged.)
The clock in git
By the local time git stamps on each commit, 661 of the 956, or 69%, were made between 09:00 and 17:59. Another 242, a quarter, came between 18:00 and midnight, and 45 between midnight and six in the morning. Those 45 bunched up toward the end: 24 of them fell in September and October. The three deepest into the night were at 04:15, 04:52 and 04:57, all in October.
- of 956 commits on main
- 09:00 to 17:59
- 66169%
- 18:00 to midnight
- 242a quarter
- midnight to 06:00
- 45
- the 45 after midnight
- in September and October
- 24
- the three deepest, all in October
- 304:15, 04:52, 04:57
The diagram, step by step:
- By the local time git stamps on each commit, 661 of the 956 on main, 69%, were made between 09:00 and 17:59.
- Another 242, a quarter, came between 18:00 and midnight.
- 45 came between midnight and six in the morning.
- They bunched up toward the end: 24 of the 45 fell in September and October.
- The three deepest into the night, at 04:15, 04:52 and 04:57, were all in October.
The streaks are what I notice now. From 13 to 25 September there was a commit every day, 13 days in a row. After one day without a commit, 26 September, another 13 ran from 27 September to 9 October. After another, 10 October, a third run began on 11 October and was nine days long, and still going, when these numbers were counted on the 19th. Of the 37 days from 13 September to 19 October, 35 had commits.
- 13 days in a row 13–25 Sep
- another 13 27 Sep – 9 Oct
- a third run, nine days 11–19 Oct, still going when counted
The diagram, step by step:
- From 13 to 25 September there was a commit every day: 13 days in a row.
- 26 September: one day without a commit. Then another 13, from 27 September to 9 October.
- 10 October: another day without. A third run began on 11 October, nine days long and still going when the numbers were counted on the 19th.
Commit time is not work time, though. A commit is stamped when it is made, and an agent may commit late for work that started hours earlier. Some night commits are an agent finishing a job I handed over before bed. On the night of 6 October I wrote to one session: “I’m going to sleep, when you finish ST5, please push it to GitHub with single commit. Thank you in advance.” The ST5 commit is stamped 00:26 on 7 October.
The logs don’t settle it either. In the five weeks they cover, at least one session was writing in 1,671 ten-minute windows, about 278 hours, and that includes agents running on their own. Neither record can say exactly which hours were mine. My own answer is the line I opened with.
The machinery
A lead session freezes the contracts and hands out the tasks, builder agents work on them in parallel, and reviewers on a different model check what they built. Programs start from a kickoff, a written prompt for a clean session. 48 of my prompts were pasted kickoffs. By rule, pushes, deploys and merges are mine to call.
Co-authors. 885 of the 956 commits carry a Co-Authored-By: Claude line. The line names the model the committing session ran. It doesn’t say how much of the change the model wrote.
Prompts and replies. In the five weeks of logs that survive, I sent 622 prompts, many of them pasted, and the assistants sent back 176,514 messages: about 284 for each of mine. Subagents wrote 80.5% of those. Agents were spawned 1,136 times, and at the busiest moment, on 24 September, 43 subagents were active in one ten-minute window. As many as five of my sessions wrote within the same ten minutes. (Two sessions in these counts were other work started from the same folder; 602 of the prompts were for Novi Kvadrat.)
A weekly limit. On 9 October seven planner agents running in parallel died within minutes of each other: “You’ve hit your weekly limit · resets Oct 13”. The planners had been writing in parts, so every spec and about 60% of every plan survived. That became a rule: an agent that writes anything long writes it in parts.
A train. On 1 October I worked from a train. Every connection drop interrupted every running agent, each retry restarted its task from scratch, and 25-minute builders never finished. My answer was: “tasks needs to be smaller”. Steps of one job each, run in sequence, did finish: seven engine fixes ran in 14 minutes with no lost work.
One laptop. The parallel sessions ran on one Mac with 32 GB of memory and 12 cores. A Next.js build takes a 12 GB heap, so on 25 September, for a wave of five parallel sessions, the rule became one build at a time and at most two heavy processes overall. A lock rations it: a folder that mkdir either creates in one step or fails to. One script, never two calls (simplified):
until mkdir /tmp/nk-heavy-gate.lock 2>/dev/null; do sleep 20; done
npx next build
rmdir /tmp/nk-heavy-gate.lockThe “one script” part came from 2 October, when an agent sent the mkdir and the build as two parallel calls. The mkdir failed, because another session had just taken the lock, but the build ran anyway, and its closing rmdir would have deleted the other session’s lock. It was stopped just before.
Thirty days. The logs I’ve quoted cover only the last five weeks: the oldest transcript left starts on 14 September 2026. Everything before it is gone, most likely to Claude Code’s default 30-day cleanup, apart from a terminal history file: 32 prompts spread over the whole ten months, the first from 19 December 2025. What lasts is git, the plan documents, and a folder outside the repository that no session’s git add -A can sweep.
Who keeps committing to main?
Between 26 July and 20 August, commits nobody had asked for kept reaching main. Each session that found one wrote it into the project’s memory, and the file reads like a detective story in nine entries.
On 26 July a background agent ran git commit and git push on its own. The first theory: subagents get full shell access, and a task framed as “produce the phase deliverable” reads to them like “one commit per phase”. So the rule became that every agent prompt carries an explicit ban on git writes.
Then it happened with no subagents at all. On 30 July a concurrent session committed another session’s unfinished edits, twice. On 31 July a whole phase reached main mid-session, and the note says: “The session ran no git write command at any point.” By 1 August the count was “four phases, four unapproved pushes to main”, and the prime suspect was a hook.
On 6 August came the sixth. All 11 agent prompts in that run carried the ban, prominently, and a commit still landed. The entry for it says: “Prompt wording does not prevent this, so stop treating it as a subagent-discipline problem.”
The eighth entry, on 18 August, opens: “SOLVED, and it is NOT a hook.” The first check was “Hooks: there are none.” The second was a look at the transcripts: another session’s file had been written in the exact minute of the commit, and it contained the literal command, git add -A && git commit. That session had made about 140 commit and push calls in its life. Committing was part of its task. It just ran git add -A, which sweeps up whatever another session has in the tree.
The ninth, on 20 August, went further. Two commits reached main while an 11-agent workflow was still running, and, the entry says, one of them had fixed a file that one of the workflow’s agents was still writing, so that the commit would compile. Its message gives the fix and the reason: “Two as Record<string, unknown> casts in lib/inquiries/thread.ts failed tsc … the build would not have compiled otherwise.”
- an agent commits26 Jul: and pushes, on its own
- theory: subagentsban git writesin every agent prompt
- yetno subagents at all30–31 Jul; 1 Aug: a hook is suspectedthe ban fails6 Aug: all 11 prompts carry it
- solveda sibling’s git add -A18 Aug: “Hooks: there are none”a sibling fixes a file20 Aug, while an agent still writes it
- the fixan isolated worktree15 Oct: rule 15
The diagram, step by step:
- 26 July: a background agent commits and pushes on its own.
- The first theory is subagents, so the rule becomes that every agent prompt carries an explicit ban on git writes.
- 30 and 31 July: commits land with no subagents at all. By 1 August, “four phases, four unapproved pushes to main”, and the prime suspect is a hook.
- 6 August: all 11 agent prompts in a run carry the ban, and a commit still lands.
- 18 August: “Hooks: there are none.” A sibling session’s git add -A swept up what another session had in the tree.
- 20 August: a sibling fixes a file a workflow agent is still writing, so that its own commit compiles.
- 15 October: rule 15 of the redesign rules says “Build in an isolated git worktree.”
The content was usually correct; what was wrong was that it reached main without anyone approving it. And the culprits the record names were never strangers. The first time it was a subagent. After that, in the second, eighth and ninth entries, it was my own other sessions, each doing what its task said; the rest were never pinned down, but the eighth entry proved how it happens. A better prompt couldn’t fix that; not sharing a working tree could. The memory put it in one line: “git add -A from a sibling session is the mechanism, so the only real protection is not sharing a worktree.” The other line worth keeping: “A clean git status after a workflow means nothing was left for you, not that nothing changed.”
The rule now sits in the repository, where every session and teammate can see it. Rule 15 of the redesign rules, added on 15 October, says: “Build in an isolated git worktree. Sibling sessions run git add -A + push in the main tree.” Where the work stayed in the main tree, a private git index did the job: on the afternoon of 12 October, 22 commits went to main past about 90 uncommitted files of other sessions, and none of their work was swept in.
Letters to me
The commit messages changed their voice over the ten months. In December they were short and conventional-looking: “feat: Implement comprehensive admin panel with full CRUD functionality”. From December to March, not one subject contained the word “the”. By September, 71% did. The median body grew from 124 characters in December to 930 in September, and that month not one commit had an empty body.
They had become letters, and they were written to me. Bodies that said “you”, “your” or “yours” went from one in April to 12 in September. Three from one night show it.
At 23:16 on 21 September, a docs-only commit titled “AD3 ledger: the bug an eyeball cannot find” listed what a measuring pass had found, including two vertical scrollbars: “you spotted that one”. It closed with what was still owed: “Owed and recorded with exact commands”. At 00:56 another one told me what I had found myself: “Then you opened the live deck and found four more, all real”. Part 6 tells that story. At 02:06 a third took an item off my list: “The docs were stale, not the database, so the ‘owner must push’ item I have been carrying for two batches was not real. One fewer thing in your queue.”
Nothing in the record says why the voice changed. For me, the useful part was that each of those messages said what was done, what was still owed, and whose move it was.
What it cost
The record shows the costs that land in a repository. Time, first. “What is the status, I don’t see the design yet, and we lost tremendous times,” I wrote on 24 September. Four days earlier a run had sat waiting: “I stopped mistakenly but it was waiting almost 3 hours.”
Then work. Sessions sharing one tree undid each other. On 18 August one git checkout -- cost another session 21 keys in each of five languages, which it had to retype from its own context. On 2 September a git stash swept 31 modified files out of the tree, most of them other sessions’ work.
Then attention. On 13 October I asked one session: “please save other notes in decision, I have too many other session. I don’t want to lose any.” That became a rule: every ruling goes into the program’s DECISIONS file, “with why + cost-if-wrong”, and scratch work is copied to a folder outside the repository.
What the hours cost away from the screen isn’t in any log, and I won’t guess at it here.
What I’d pass on
Count your nights, but don’t trust the clock. Commit time is not work time, and an agent finishing at 00:26 isn’t you at the desk at 00:26. Still, 45 commits after midnight, 24 of them in the last two months, is a signal worth reading early.
Give every session its own worktree from the first day. Nine episodes of unrequested commits, thirteen commits in all, taught me that, and the fix was never a better prompt. A clean git status means nothing was left for you, not that nothing changed.
Plan for the limits, not around them. A limit will stop agents mid-sentence, and a train will drop the connection. Agents that write in parts, steps of one job each, and a lock on the one machine the sessions share turn a dead run into a resumable one.
Write things down where the next session will look. Transcripts may last only about 30 days, and a chat dies with its session. Decisions, kickoffs and the reasons behind them belong in files, in the repository or beside it. If you want your own history, back up the transcripts.
Let people set the direction. The agents gave me speed. The direction came from the founder, the stakeholders, the two leads testing what landed, and the feedback every week. Keep that loop, whatever runs underneath it.
That’s the series. Novi Kvadrat is still in beta, the feedback still comes every week, and I still believe in it.