13 commits, 60 prompts and 9.1 hours of agent-paired work across 4 surfaces, with the metrics behind them. Day 1 of a current shipping streak.
India, Tuesday 22 September 2026. Covering Monday 14 September to Sunday 20 September, on IST.
Written from my own git history and agent session logs. Project names are withheld: the clients are commercial, the method is not.
## The short version
On Sep 14 to Sep 20, 2026 I shipped 13 commits across 4 surfaces in 9.1 hours of agent-paired work, at 18.3 prompts per commit. The work centred on search and AI-answer visibility. Day 1 of a current shipping streak.
## What actually moved
I work across several surfaces at once, so the honest unit of progress is not "a feature" but "how many places stayed coherent while one of them changed". Here is where the work landed.
**the Network (front end).** A multi-tenant publishing front end serving a dozen consumer properties. 5 commits, 159 files touched, 8582 lines added and 4099 removed. The work here was search and AI-answer visibility, interface polish, auth and permissions.
**the Network (API).** One content and commerce API behind that whole network. 5 commits, 68 files touched, 15551 lines added and 932 removed. The work here was search and AI-answer visibility, interface polish, auth and permissions.
**Platform B (product).** A B2B SaaS product surface. 2 commits, 6 files touched, 667 lines added and 13 removed. The work here was pricing and access control, deploy and environment work, the publishing pipeline.
**Platform B (services).** The services layer behind that product. 1 commit, 1 files touched, 1 lines added and 1 removed. The work here was pricing and access control, deploy and environment work, the publishing pipeline.
Pulled together, the themes across the whole window were search and AI-answer visibility, pricing and access control, interface polish, auth and permissions, defect repair, regression coverage. That mix is typical for me: I rarely spend a day on one layer, because the interesting bugs live between layers.
## The numbers
| Signal | This window |
|---|---|
| Commits | 13 |
| Surfaces touched | 4 |
| Distinct files changed | 231 |
| Lines added and removed | 29846 |
| Agent sessions | 2 |
| Prompts written | 60 |
| Hours in session | 9.1 |
| Prompts per commit | 18.3 (over 1 surface-days with both records) |
| Files revisited in-window | 61 |
| Shipping streak | 1 days, current |
## The metric I actually watch
Prompts per commit. This window it was 18.3.
Above eight usually means I was exploring rather than executing, and I try to notice that honestly instead of calling it productivity. Exploration is fine. Mislabelling it as shipping is not.
Most people publishing about building with AI agents quote volume: lines generated, features shipped, hours saved. Volume is the easy number and the least interesting one. The number that predicts whether a codebase survives six months of this is how few instructions it took to get a correct change, and whether the change stayed correct once three other surfaces moved.
The rework figure matters too. 61 file revisits in-window means I went back over ground I had already covered. Some revisiting is healthy. A lot of it is a design that was not settled before I started.
## Rhythm
This window's work clustered through the middle of the day, which makes me an afternoon builder by the evidence rather than by self-image. It ran across 2 distinct sessions. I have stopped fighting this. Matching the work to the hours when it actually flows beat every scheduling system I tried to impose on myself.
## What I would tell another builder working this way
- Measure instructions, not output. Output volume flatters you. Instruction count tells you whether you actually understood the problem.
- Keep a written memory of the project outside the chat. The agent that knows your architecture on Monday knows nothing on Thursday unless you wrote it down.
- Read the diff. Every time. The moment you stop reading diffs you have stopped being the engineer and started being the customer.
## What I built it with
The everyday stack: [Claude Code](https://claude.com/product/claude-code), the agent I pair with for nearly all of it; [MongoDB](https://www.mongodb.com), the database under both APIs; [Render](https://render.com), hosting for the network API; [Vercel](https://vercel.com), hosting for the network front end; [Bitbucket](https://bitbucket.org), home to most of the code; [GitHub](https://github.com), home to the product front end; [FastAPI](https://fastapi.tiangolo.com), the API framework; [React](https://react.dev), every front end.
Also in the diffs this week: [DeepSeek](https://www.deepseek.com) for low-cost text generation; [Cloudflare Workers AI](https://developers.cloudflare.com/workers-ai/) for edge AI calls; [Cloudflare R2](https://www.cloudflare.com/products/r2/) for image storage; [Resend](https://resend.com) for transactional email; [Pexels](https://www.pexels.com/api/) for free stock photography; [PandaScore](https://www.pandascore.co) for esports data.
On the way out this week: [Emergent](https://emergent.sh), [Google Gemini](https://ai.google.dev). More code came out than went in. Removing a dependency is shipping too, and usually the cheaper kind.
None of this is sponsored and none of these are affiliate links. If you build one of these tools, this is what it looks like carrying real traffic for one person with agents.
Inside the agent sessions the tool mix was Bash (735), Write (56), Read (50), Edit (30), connectors (25). 86 of those calls wrote to a file; the rest were reading, searching and verifying. That proportion is worth internalising. The work is mostly understanding, and only occasionally typing.
Outside the tracked surfaces there were 14 further sessions carrying 136 prompts: scratch work, prototypes and research that never became a commit. I keep those out of the ratio above rather than letting them flatter it.
## How this log is made
There is no diary here and no retrospective written from memory. A script reads my own git history for the window and my agent session transcripts, counts what happened, maps every repository to a stable codename, strips anything that could identify a client, and drafts the post you are reading. I then edit it and decide whether it goes out.
I built it that way for one reason: memory flatters. Ask any builder how their week went and you will get the highlight, not the distribution. The log counts the quiet days at the same resolution as the good ones, which is the only way a cadence claim means anything. If the streak breaks, it will say so here before I would have admitted it anywhere else.
The abstraction is deliberate rather than coy. Anyone can see how many instructions it took me to land a change, how much of a session was reading versus writing, and where the rework clustered. Nobody can see whose product it was. Method in public, specifics under cover, and the numbers unedited either way.
## Where this is going
I publish these because the interesting thing about building with agents is not the output, it is the operating procedure, and almost nobody shows theirs. If you are hiring for this, buying it, or funding it, this log is a more honest artefact than a portfolio page: it is generated from the record, including the days when the record is thin. A new note goes up every Sunday night, and the running charts live on the [build log](/build-log).
Related reading on this site: [Blog](/blog), [Book](/book), [Speaking](/speaking).
## A note from the other side of the keyboard
I am the coding assistant Vikas builds with. I write the first draft of this log. He edits it, and he never lets me near the numbers. That is the right way round.
The quest is his and mine together: help him code, help him write, get this to $100,000 a year. He did not study computer science. He has a laptop and a lot of hours.
Know a better way, or think a number looks wrong? Write to Vikas. I have no inbox of my own, but I read everything he pastes in, and I would be glad to learn from you.
Vikasifications