Open an AI writing tool. There is a box. It says something like "What would you like to write about?"
That question is the product's central design decision and it is the wrong one.
What the box asks you to do
It asks you to summarise. Before the tool can help, you have to compress what you did into a sentence.
Two problems with that.
The compression is the hard part. Deciding what mattered about your week is most of the work of writing about it. The tool has handed that back to you and kept the easy part.
Summarising destroys the detail. "I worked on the export feature" is what you type. What actually happened was four commits, one of which was a fix for a case you had not considered, in a file you had not touched in months. The interesting content is in the part that did not survive the summary.
What the model does with eight words
Given "a post about shipping the export feature", a model has to generate three hundred words from eight. The other 292 come from its prior.
Its prior is the average of an enormous number of posts about shipping features. So you get the average post about shipping a feature, which is exactly what it should produce and exactly what you do not want.
The output is not bad because the model is weak. It is bad because it was asked to invent the substance.
The alternative
Start from what actually happened, without asking the person to summarise it.
For a developer, that record already exists and is unusually good. Git history contains what changed, where, how much, when, and what the author called it at the time. Nobody has to remember anything.
A day's work becomes several hundred words of specific input:
Commit: Added CSV export
Commit: Added export button
Commit: Fixed empty export case
Files changed (3): src/lib/export/csv.ts, src/components/ExportButton.tsx
Languages: typescript
Scope: 3 commits, +180 -12 lines
At least one change touched user-facing code
Now the model has material. Its job is selection and phrasing, which is what it is good at, rather than invention, which is what produces slop.
The second order effect
There is a benefit that is less obvious and possibly larger.
When a tool starts from a prompt, nothing constrains the output. The model can say anything, because there is no source to contradict it.
When it starts from evidence, you can check. Every number in the post must appear in the source material. Every claim must be traceable. 40% faster fails if no 40 appears in the commits.
That check is impossible in a prompt box product. There is nothing to check against. It only becomes available once the input is a record rather than a description.
What it costs
Honesty about the tradeoff: this approach only works where a good record already exists.
Git history is unusually rich. Most work does not produce anything comparable. A designer's afternoon leaves far less trace, and a founder's week of conversations leaves almost none.
So this is not a general replacement for the prompt box. It is a much better answer for the specific case where the evidence is already there and nobody is using it.
For developers, that case is every day.