Home / Articles / How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was / Versions / v1.1.0
How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was: what changed in v1.1.0
From v1.0.0 (2026-10-05, 6ba12b0a2) to v1.1.0 (2026-10-05, d234ea8cf), paragraph by paragraph.
15 paragraphs added, 1 removed, 3 changed in place, 54 unchanged. About 1,479 words added and 107 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names.
3 unchanged paragraphs
> Where this comes from, and what is behind it. A WhatsApp exchange on 5 October 2026, in which a friend who had just received an answer from one of my agents said the amount of text I produce is baffling, and my reply that I create the briefs and review the drafts, and that the article in question leaned, in a Wardley-evolution sort of way, on content I have been publishing for years. Then a voice memo asking for the thing I always try to explain to be measured rather than asserted. The data is the transcript of the Claude Code session that has run this site since 11 August, parsed for who said what and when, joined to the site's git history. The method, its limits and the full dataset are published beside the article. Seven of the twenty articles were checked by hand, turn by turn; the rest are reported only where the numbers are exact. This article has itself been revised since it was first published, and what changed is shown paragraph by paragraph, by a tool built for the purpose on the same day.
5 unchanged paragraphs, under In short
• The input is not the memo. The last article quotes or links thirty-three pieces of my earlier writing. The record it drew on is a 2010 open source tool, a book, 107 posts on diniscruz.ai in twenty months, 3,025 markdown files in one team's record this year, and the twenty-six articles before it on this site, nineteenseventeen of which cite an earlier one.one, with sixty-five links between them. The agent is fast because the record exists and is published where a machine can read it.
24 unchanged paragraphs, under The question, and why it needs numbers, What went in, and what came out, What the corrections were…
The code review company article quotes or links thirty-three pieces of my earlier writing. None of them was written for the article. They are, in order of age: the O2 Platform, an open source static analysis tool I built between 2010 and 2013 whose method streams technique the article revisits; a blog from 2011 and a book from 2016 on the security side of code review and feedback loops; 107 posts on diniscruz.ai between February 2024 and October 2025, among them the ones on semantic graphs for source code, on explorers, villagers and town planners, on using models to find the solution and code to execute it; the record of one team this year, 3,025 markdown files of briefs, debriefs and articles written with agents while building SG/Send and sgit, 1,682 of them in my own folders, among them who should be reading the code, the five whys as a translator, open source as strategy and budgets on the step; and the twenty-six articles before it on this site, nineteenseventeen of which cite an earlier one, with sixty-five links between them.
4 unchanged paragraphs
The form, the workflow and the tools
One more thing the numbers cannot show on their own, and the memo insisted on: none of this would have happened at this pace without the form it runs in. The articles come out the way they do because there is a production pipeline behind them, built over two years and improved most weeks, and the pipeline is as much the input as the memos are.
The pipeline, as it stands today. A memo arrives, usually as a transcript with the ums in. The agent reads the record first, the articles and their graphs, the team briefs, the posts, and only then searches outside. It writes the article as markdown with a few conventions: a note box saying where the piece comes from, an In short list, figures declared on one line each, a sources list. It draws the figures as small web pages in a shared style and renders them to images with a headless browser, so a figure is text that can be corrected rather than a picture that has to be redrawn. It writes the graph JSON. A build turns all of it into pages, markdown twins for agents, a machine-readable index, link-preview cards and a feed, and a validator refuses the release if a link is dead, a page is orphaned, a credential pattern appears, an em-dash is in the prose or the banned ladder word is in an article. A leak scan runs on every commit. The release gets a version, a log entry and a commit with both names on it, and a live check confirms it is up. The whole of that is open source, in the site's own repository.
The tools inside it were almost all built on the day they were needed, because something was slow. The figure renderer was built when a set of figures from another agent clipped at fixed heights. The vault bundler was built for the code review vault. The code analysers, the delta reader and the method stream extractor were built for the code review article, in an afternoon, and are published with the vault. The transcript parser that produced the numbers in this article was built this afternoon, in about forty lines. And when I asked, while reading the revision of this article, for a way to see what had changed rather than re-read nine thousand words, the agent built a diff tool that compares two versions of an article paragraph by paragraph and publishes the result as a page, which is how the changes to this article can be read. The map of the articles was improved in the same hour because reading it for this article showed it needed to be.
This is the part I most want other people to take from the exercise. The productivity is not the model. It is the model inside a form I control, where any step that is not working can be replaced with a tool the same day, and where two years of those tools have accumulated into a toolkit, all of it open source, that a new session inherits. I have the power to shape the technology I use, and I use it constantly: this is not effective, build a tool for it. A team that adopts the model without that habit gets the model's speed on the first draft and none of it afterwards.
Two smaller things belong here because the memos raised them. The first is that the work is queued. I send memos and corrections in the order I have them, often several at once while the agent is mid-task, and the agent processes them in an order that makes sense, so a thought that arrives while something else is being built is not lost, which suits the way my mind works far better than any to-do list ever did. The second is that the images other models make from these articles go through the same rounds. The infographic at the end of this article is the second version; the first put the emphasis on the numbers and I asked for it to be rebuilt around the one idea in the middle of the piece that I think is the strongest, and the second version has two numbers wrong, which the caption names. Images are drafts too.
1 unchanged paragraph, under The compounding
The last thing the numbers show is that the articles are not twenty separate pieces of work. Nineteen of the twenty-seven articles on this site cite at least one earlier one, and the latest cites seven. The code review company article could not have been written without the code review article; the code review article could not have been written without the fractal semantic graphs article, which is the one argued down over five releases in September; and the fractal semantic graphs article was written from a post on diniscruz.ai and a brief in the team record. Each one is a distillation that the next one assumes.
The last thing the numbers show is that the articles are not twenty separate pieces of work. Seventeen of the twenty-seven articles before this one cite at least one earlier one, sixty-five links run between them, and six of those links run the other way, from an older article that was updated after a newer one existed. The latest cites seven. The code review company article could not have been written without the code review article; the code review article could not have been written without the fractal semantic graphs article, which is the one argued down over five releases in September; and the fractal semantic graphs article was written from a post on diniscruz.ai and a brief in the team record. Each one is a distillation that the next one assumes.
The links are not only in the prose. Every article on this site has a semantic graph beside it, a JSON file per article with the ideas it rests on, the claims it makes, the methods, the examples, how they connect, and which earlier articles and pages it builds on. The build reads those files and draws a map of the articles, every one in date order round a circle, sized by how many others link to it, with the links as edges. The map was redrawn while this article was being revised, because reading it for this article showed that its labels collided and one floated off the ring, which is the loop in miniature: a tool used in earnest gets improved.
[figure hmi-the-articles-map.webp] The twenty-eight articles as the build draws them on 5 October 2026, oldest at the top and clockwise from there, sized by how many other articles link to them. Teal edges run from an article to an earlier one it cites; the six amber edges run the other way, from an older article updated to point at a newer one. The fractal semantic graphs article, with ten articles linking to it, is the one everything else stands on.
[figure hmi-this-articles-graph.webp] This article's own graph, as the build draws it from the JSON beside the article: thirteen nodes, thirteen edges, coloured by kind. The same file tells the map which articles this one builds on, and tells an agent what the article claims before it reads a word of it.
That per-article graph is also what makes the linking cheap. When the agent writes a new article it does not read the twenty-seven before it. It reads their graphs, a few hundred words each, and opens the two or three whose claims the new piece depends on. The index is the graph, the graph is small, and the agent reads selectively, which is the memory article's argument about tokens made concrete: a curated, structured record costs a fraction of a knowledge base that has to be sifted every time.
4 unchanged paragraphs, under What is open
The article as one page, by another model
As with the three articles before it, Dinis fed the published text to ChatGPT and asked for an infographic, twice. The first version led with the numbers. The second, below, was asked to lead with the idea in the middle of the article that he thinks is the strongest, that a model which can go in every direction needs someone with a direction, and it does. It was checked against the article before it went up. The headline figures are right. Two numbers are not: the input for the code review company article is given as 5,785 words where the ledger has 4,522 plus a reader's 1,401, and the count of articles that cite an earlier one is given as nineteen where the build says seventeen, a number this article itself had wrong when it was first published and corrected in the revision whose diff is linked above.
[figure hmi-one-page-by-another-model.webp] The article as a one-page state, second version, generated with ChatGPT from the published text on 5 October 2026 and credited by it to the source. Two numbers in it are wrong, as the paragraph above says; the style and the slogans in the margins are the other model's, kept as they came.
2 unchanged paragraphs, under Threads woven here
• The articles as graphs, the map and the per-article graphs this article's compounding section is about, drawn from one JSON file per article.
11 unchanged paragraphs, under Sources