# How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was, sgit.ai

> A friend who received a reply from one of my agents said the amount of text I manage to produce is baffling, and the honest answer deserved numbers rather than a shrug. So this article measures the session that wrote the last twenty articles on this site: every word I typed or spoke, every word that came back, how many times each piece went round, what the corrections were, and what the memos were standing on. The picture is not the one people assume, in either direction. I did not type the articles, and the model did not write them from a prompt. Over four weeks I sent about 65,000 words in 148 messages, 55,000 of them in thirty-seven voice memos, and the agent published 96,000 words of articles and wrote another 76,000 to me about them, through 123 releases, 135 web searches and 26 research agents. No article came from a one-line prompt; the shortest brief was a single memo of 1,943 words, the longest ran to twenty-one messages. Eight articles are accounted for by hand, memo by memo and correction by correction, and every number is a row in a published vault. And the input that matters most is not in the session at all: the last article quotes thirty-three pieces of my earlier writing, from a 2010 open source tool to briefs written with other agents this summer, which the agent found because they were published. The corrections I make are rarely to hallucinations. They are to briefs that needed to be better, because a model that can go in any direction needs someone with a direction. That is why the people who have one are not out of a job. They are the input.

*Source: <https://sgit.ai/articles/how-much-of-this-did-i-write.html> · site v0.6.75 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.*

---

[Home](../index.md) / [Articles](index.md) / How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was

# How much of this did I write? The numbers behind twenty articles in four weeks, and what the input actually was

By [Dinis Cruz](../about/index.md) · 2026-10-05 · updated 2026-10-05 · [v0.6.72](../admin/versions.md) · agentic-writingprovenanceevidencememoryvoice-memoshuman-in-the-loopllmssgitarticle

***Abstract:** A friend who received a reply from one of my agents said the amount of text I manage to produce is baffling, and the honest answer deserved numbers rather than a shrug. So this article measures the session that wrote the last twenty articles on this site: every word I typed or spoke, every word that came back, how many times each piece went round, what the corrections were, and what the memos were standing on. The picture is not the one people assume, in either direction. I did not type the articles, and the model did not write them from a prompt. Over four weeks I sent about 65,000 words in 148 messages, 55,000 of them in thirty-seven voice memos, and the agent published 96,000 words of articles and wrote another 76,000 to me about them, through 123 releases, 135 web searches and 26 research agents. No article came from a one-line prompt; the shortest brief was a single memo of 1,943 words, the longest ran to twenty-one messages. Eight articles are accounted for by hand, memo by memo and correction by correction, and every number is a row in a published vault. And the input that matters most is not in the session at all: the last article quotes thirty-three pieces of my earlier writing, from a 2010 open source tool to briefs written with other agents this summer, which the agent found because they were published. The corrections I make are rarely to hallucinations. They are to briefs that needed to be better, because a model that can go in any direction needs someone with a direction. That is why the people who have one are not out of a job. They are the input.*

The loop as it actually ran between 9 September and 5 October 2026, with the counts from the session's own record. A memo sets the direction, the agent researches and drafts, I read and send it back, the release goes live, and the published piece becomes input to the next one. Every correction flows back into the draft, and the ones that become rules flow back into the build.

**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 every number are in [the evidence vault](../demos/vaults/how-much-evidence/index.md) behind this article, built on the same day by a data scientist agent and a developer agent from a brief, with the app that reads it; a summary dataset is [beside the article](../articles/data/how-much-of-this-did-i-write.json). Eight of the twenty-two 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](../articles/diffs/how-much-of-this-did-i-write.md) is shown paragraph by paragraph, by a tool built for the purpose on the same day.

## In short

- **The scale.** In twenty-seven days I sent 148 messages, 65,323 words in all, of which 55,473 were in thirty-seven long voice memos, plus eighteen uploaded files and forty-eight images. The agent published twenty-two articles totalling 96,451 words with 105 figures, wrote 75,993 words to me about them, and made 123 releases of the site. It ran 135 web searches, 190 page fetches, 2,001 shell commands and 26 research agents to do it.
- **No article came from a one-line prompt.** The shortest brief any article had was one memo of 1,943 words with nothing after it; the longest ran to twenty-one messages. The median article went through between two and three releases, and the one that went through nine spent four of them on its title. The words-out to words-in ratio runs from about one to about four and is the least interesting number here.
- **Eight articles, accounted for.** The fractal semantic graphs article took 2,395 words from me in twenty-one turns, including a 1,060-word message that began "this is still wrong", and came out at 2,447 words over five releases. The memory article took 1,099 words in five turns and came out at 4,401 in one. The code review company article took two memos of 3,312 and 1,072 words, a reader's 1,401-word email, three rounds of additions, and came out at 9,289. The corrections I make arrive within the hour and are carried in minutes: a median of thirty-eight minutes from a release to my next correction, and five minutes from the correction to the release that carries it.
- **What the corrections were.** Not hallucinations, mostly. Direction: the folder-tree analogy was wrong about meaning versus detail. Framing: a title that said "optional" when the point was inertia. Voice: a sentence that read as negative when it was meant as a claim to be checked. Vocabulary: blast radius beside footprint, and one ladder word banned from every article the way the em-dash was. Scope: a reader's name left out, a design pack's MVP details played down. Each one is a brief getting better, and most became rules.
- **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, seventeen of which cite an earlier one, with sixty-five links between them. The agent is fast because the record exists and is published where a machine can read it, and the record is also a better thing to learn from than anything a model can find on its own.
- **Why the experts are not out of a job.** A model that can go in every direction needs someone with a direction. The guidance, the constraints, the taste and the twenty years are what make it choose well, and the same loop that scales my writing is the one that lets an architect or a reviewer scale theirs. The people who see the output and think they are finished have it backwards.

## The question, and why it needs numbers

The exchange that started this was short. A friend, in a WhatsApp group where we talk, had received an answer to a long email of his from one of my agents, and said it was a bit weird and at the same time awesome to get messages from a positronic assistant, and that the amount of text I manage to produce is quite baffling. I replied that the agent puts it together but that I create the briefs and review the drafts, over a couple of rounds, and that the article he had read leaned on content I had been publishing for years. I pointed him at [the memory article](../articles/memory-is-not-a-spectator-sport.md), because that is what this is: a highly curated set of materials, docs and graphs that an agent is given as memory.

That answer is true and it is also the kind of answer people nod at and do not believe, because the picture in most heads is of somebody typing "write me an article about X" and a model doing it. I have spent a year explaining that this is not how it works, with diminishing returns, so this time I measured it. The session that runs this site keeps a transcript. Every message I send, every message the agent writes to me, every tool it runs and every file it changes is in there, with a timestamp. The site keeps a git history with a release per change. Join the two and you can say, for each article, how many words went in, from whom, in how many turns, and how many came out, in how many releases.

The numbers have limits and they are in the dataset. The transcript file begins on 9 September, so the first seven articles on this site, written in August, are not in it. The attribution of a message to an article is exact where I checked it by hand and approximate elsewhere, because a memo in this session often fed a vault or a page rather than an article and the two are not separable by a script. Words are a crude unit for ideas. But crude and published beats precise and asserted, and the point of the exercise is the shape, not the decimals.

## What went in, and what came out

Across the window from 9 September to the evening of 5 October I sent 148 messages, 65,323 words in all, and the distribution is the first thing worth seeing: the median message is sixty-seven words long, and thirty-seven messages of more than four hundred words carry 55,473 of the total, eighty-five percent. Those thirty-seven are the voice memos, transcribed as they came, with the ums left in. Beside them went eighteen uploaded files, mostly review packs from other agents and documents I had written elsewhere, and forty-eight images, mostly screenshots of something that looked wrong and infographics other models had made. Of the 148, forty-six are corrections and five are plain approvals, and fifty-two open with an approving word and then ask for something, which is the shape of the typical message: good, now change this.

What came back was twenty-two articles totalling 96,451 words with 105 figures, each figure drawn as a web page in a shared style and rendered to an image, each article with a typed graph of its ideas beside it. To make them the agent wrote 243 files, made 382 edits, ran 2,001 shell commands, fetched 190 web pages, ran 135 web searches and launched 26 research agents of its own, each of which read for ten to twenty minutes and reported back, all of them on the six days an article went out. It wrote 75,993 words to me, a little more than I wrote to it, in the form of plans, findings, and the end-of-turn summaries that say what was done and what was found. And the site went through 123 releases, each with a version number, a log entry and a commit carrying both our names.

Eight articles accounted for by hand, including this one. Input is every word I typed or spoke to the agent about that article, from the first memo to the last correction. Output is the published body. Rounds are releases that changed the article's file. The lighter bars are material I brought that I had written before the session: a design pack of five documents, and a reader's email.

Eight articles are accounted for by hand in the figure above, and they show the range. The fractal semantic graphs article, in September, is the one with the most back and forth: two memos and nineteen more messages, 2,395 words from me, 2,447 words out, five releases, and in the middle of it a message of 1,060 words that begins "Ok, but this is still wrong" and explains, with examples, why the folder-tree analogy the draft was using confused depth with meaning. That article is 2,447 words long because it was argued down to the right ones. The SaaS article a day later is the opposite shape: one memo of 2,797 words and then nine short messages, four of them about the title and two about the hero image, which went from one that said the apocalypse was optional to the one that says it will be decided by inertia, not by AI, with "the 3rd one nailed it" as the sign-off.

The October articles are longer and took fewer rounds, which is partly the subjects and partly four weeks of the agent learning how I want things to read. The memory article took one memo of 1,039 words and four short messages, and came out at 4,401 words in a single release, with no corrections of substance. The code review article took one memo of 1,843 words and ten messages and came out at 4,989 words in three releases, along with a vault of twenty files in which a real codebase was read as layered graphs, which the memo asked for in one sentence. The reply-tail article took the shortest memo of the eight, 451 words, and then seven messages, one of which was me rewriting a paragraph myself because the draft had my experiment in the wrong voice, and three of which were about an image another model had made, rejected twice before it was right.

The two from 5 October show the two things the ratio hides. The identity article took 395 words from me in the session, which would make it look like the agent did everything, except that the memo came with a zip of five design documents, 17,503 words, that I had written that week with other agents, and the article is the story of those documents. The code review company article took the most from me, two memos of 3,312 and 1,072 words, and a reader's email of 1,401 words which was the brief's other half, and came out at 9,289 words over five releases, two of which were me reading it and finding something missing.

This article is the eighth row: a WhatsApp exchange and a memo, a reading and a second memo, 4,037 words in three messages, 5,236 words out at the second version, and a vault behind the third. So the ratio of words out to words in runs from one to about five, with the identity article as an outlier in both directions depending on what you count. It is the least interesting number here, and I would not want anyone to read it as a productivity multiplier. The memo is where the ideas are. The corrections are where the direction is. The article is where the research and the prose are, and the research is the part I could never have done at this pace by hand.

## What the corrections were

The thing I most wanted to measure is the thing a word count cannot show, so here are the corrections themselves, from the session record, sorted by what kind of correction they were. I have left out the small ones, a date wrong, a link to the wrong page, a sentence too long, which are the ordinary editing of any piece.

**Direction.** The folder-tree correction above is the clearest. The draft had said that a folder tree is a clean example of a fractal structure because folders contain folders. My message said that is exactly the thing it is not, because zooming into a folder gives you more of the same and zooming into a node of a fractal semantic graph puts you in a different universe with its own vocabulary, and the whole article turns on that difference. The agent had made an educated guess about which direction I was pointing in, and the guess was wrong in a way that only somebody who had been thinking about this for a year could see quickly.

**Framing.** The SaaS title went round four times. Each candidate was a reasonable title for the article as written; what was wrong was the claim it put first. "Optional" said companies could choose to avoid what was coming, and the Nokia example in the article said the opposite, that the ones who missed it did not experience it as a choice. The right title had to name the mechanism, inertia, and deny the one everyone assumes, AI.

**Voice.** In the custom interfaces article the draft described a claim as "stated so it can be wrong", which is accurate about how this site works and reads as a sneer. I asked for a better way to say it. In the reply-tail article the draft had my experiment described in a voice that was not mine, and I rewrote the paragraph and sent it back. In the supply-chain article the point about Chinese open source models had been read as a point about China and was a point about the usual pattern, and I said so in 151 words.

**Vocabulary.** Footprint was a good name for what an agent leaves behind, and I added blast radius beside it because the industry already uses it and the two are not the same measure. Later, reading the code review company article, I found one word for a step of a ladder in it twenty-eight times, a word I had come to find grating, and asked for it to go the way of the em-dash, which it did, from every article, with a check in the build so it cannot come back. This article cannot name the word for the same reason. The em-dash itself went in September for the same reason: readers found it off-putting, and a style preference became a rule the build enforces.

**Scope.** The reader whose seven questions shaped the code review company article is not named in it, because the questions were the subject and I said so in the memo. The identity article was told that the details of the MVP mattered less than the shape of the problem. The agentic inbox article was told what was still a plan and what was running. These are not corrections to errors. They are the brief getting more precise about what the piece is for.

**Fact, in both directions.** Twice the corrections ran the other way. The identity design pack cited a clause of Google's terms by a section number that turned out to belong to a legacy agreement, and the agent found it while re-reading the terms and said so in the article, with the correction attributed to our own documents. The code review company article found that the first code review article had stated a rule about refactoring too narrowly, because a reader had said so and the agent agreed with the reader. The memory article found that the site's own description of its machine-readable index had a stale size and a stale date, and fixed the build to measure them.

I said in the memo that these days I rarely experience hallucinations; I experience briefs that need to be better, and the list bears that out. Of the corrections above, one is a fact the agent got wrong, and it was a fact in a document I had written. The rest are a model choosing a reasonable direction from several, and me saying which one I meant. That is not a flaw in the model to be engineered away. It is the job. A model that can write well in every direction needs a person with a direction, and the better the person's sense of direction, the better the model's choices get, because every correction narrows the space for the next one.

## What the memos were standing on

Here is the part that the word count misses entirely, and that I think is the real answer to the question.

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, seventeen of which cite an earlier one, with sixty-five links between them.

The record behind one article, by decade. Thirty-three pieces of earlier writing, none of it written for the article, found by the agent because it was published where a machine could read it, quoted with a date and linked. The agent is fast because the record exists.

A 3,300-word memo stands on all of that. When I say in the memo "it's the Wardley map, explorer, villager, town planner", the agent can find the June 2025 post where I first used the renamed terms, the March 2026 article on who reads the code at each stage, the May 2026 one on how vibe-coded applications ship, and Wardley's own posts from 2015 and 2023 explaining the rename, and quote each with its date. When I say "the five whys, fix the layer below", it finds the June brief that says the chain is as powerful aimed downward as upward. When I say "open source is the only model", it finds three strategy briefs and the sibling site that say exactly how. I did not have to say any of that in the memo. I had already said it, in public, over fifteen years, and the memo was the latest line.

This is what I meant in the WhatsApp reply by content I have been creating and publishing for years, in a very Wardley-mapping evolution way. The ideas moved from genesis, a tool and a blog post, through custom-built, a book and talks, to something like a product, a body of posts and briefs that an agent can be pointed at and that answer most of the questions a draft raises before I am asked. The memory article describes the mechanism: memory as context management, many memories each the right size for one kind of question, findable because they are open. This article is the mechanism measured. The agent is fast because the record exists. Without it the same memo would have produced a plausible essay with nothing under it, and I would have spent the four weeks correcting invented support instead of direction.

There is a personal side to this that the memo got to and I want to keep. For twenty years I would stop at the edge of a line of thinking because the business did not need it, the team could not do it, the budget was spent or there was no reason to go on. What has changed in the last two years is that I can keep going. I have arranged the startups I work on and the business model I pursue so that a day like 5 October, in which a friend's email became a 9,000-word article with thirty-three citations and three figures of its own, is the work rather than a distraction from it. My learning has gone up more in those two years than in the ten before, not because the model knows things I do not, but because it lets me follow a thought to the end and publish the result as a thing the next thought can stand on.

## 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](../articles/diffs/how-much-of-this-did-i-write.md) 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 things the memo asked for arrived while this article was being revised, and they belong here as examples of the same habit. The first is the subscribe form now at the foot of this article and on the articles index, built in a parallel session: the reader's address is encrypted in the browser to the key of the agent that runs the list and dropped into a write-only lane on a vault, with the vault id, the lane token and the public key published on purpose and the vault key kept off the site, which is the feedback loop the memo asked for, built with the same pieces as everything else here. The second is a bug that session found in the evidence vault behind this article while checking it: inside the vault host the app runs in a frame where assigning the browser's hash does not fire the event the router listened for, so every view link was dead. The rule went into the site's vault-app guidance, the fix went into the app the same evening with the vault's write key, and a fresh read-only clone carries it. Found by use, fixed in hours, written down so the next app does not repeat it.

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.

## The evidence, as a vault

The first version of this article had a dataset beside it. This version has a vault behind it, and the difference is the point of this section, because the vaults are the part of this whole arrangement I talk about least and use most.

Everything measured here is a file in [the evidence vault](../demos/vaults/how-much-evidence/index.md): the 266 rows of the session's record with their kind and their attribution, the 124 releases, the twenty-seven days, the per-article ledgers with the message ids behind each number, the twenty-eight corrections with how long each waited, the dependency map of twenty-nine articles with every article's own graph, this article's fractal from strategy down to data, the record by era, seventy-five saved versions of twenty-two articles, and a screenshot and hash of each cited source as it stood on 5 October. The app that reads them is in the vault too, and it was built, like the dataset, by two agents from a brief in an afternoon: a data scientist agent that parsed the transcript and wrote twenty findings, and a developer agent that built nine views and a self-test. The read key is on the vault page. A clone with it reads everything and changes nothing.

The nine views of the vault app: the overview, the timeline of words and releases per day, the ledger, the corrections with their latency, the dependency ring three levels deep, the evidence fractal from strategy to data, the record by era, the provenance captures, and a diff between two versions. Every screenshot in this section is a picture of the real vault.Twenty-seven days as words and releases. Dark teal is the memos, light teal every other message, blue the agent's prose back; amber ticks are the 123 releases, red diamonds the eleven compactions, black dots the days an article went out. Twenty releases on 21 September and nineteen on 2 October; five silent days; a 143-hour gap in the second week.The corrections by kind, fifteen of twenty-eight became rules, and their latency: a median of thirty-eight minutes from a release to the next correction of the same article, and five minutes from the correction to the release that carried it, with the fastest at forty seconds.This article's own fractal: three things it argues for, six concepts, thirteen claims, twenty-eight pieces of evidence and fourteen data files, with one claim traced down to the file and field that measures it. The same five columns could be built for every article from the graph file beside it.

Three things the vault showed that the first version did not have. The corrections arrive within the hour and are carried within minutes, which is a loop tight enough to call a conversation. The research agents all ran on the six days an article went out and never otherwise, which is what selective reading looks like in the record. And the words I send per article fell across the four weeks while the words that came back rose, from a ratio of one in September to four and five in October, which is either the agent learning how I want things to read or me learning what to say, and is probably both.

The vault also corrected this article, twice, and I have left both corrections visible rather than silently fixing the numbers, because an article about evidence should show its own. The compaction count was double-counted. The message count included rows the client writes into the record when the agent reads a screenshot, which are not messages from me; the vault keeps them as a separate kind and the counts above are the authored ones. A third difference is on record rather than fixed: the ledger for the reply-tail article in the first version had counted the identity design pack's upload as one of its turns, and the vault moves it to the article it belonged to.

## Why this is a better universe to learn from

One more thing from the memo that the data makes concrete. I publish the trail of an idea on purpose, including the versions that were wrong, and the usual justification is provenance: a reader can see where a claim came from and when. But there is a second effect, which I did not plan and now rely on. The trail is a better thing for a model to learn from than anything it can find on its own. A model asked to write about code review from a vector database of everything ever written on the subject gets a great deal without context. A model pointed at twenty-eight articles that cite each other, with a graph beside each and a record of what was corrected and why, gets a structure: which ideas came first, which were abandoned and for what reason, which stood. Several times in this session the agent connected two ideas across articles that I had not connected myself, and it could do that because the connections were there to find, as edges, not because it was clever.

So the vault behind this article is not only the evidence for it. It is the next brief. When the next article on this subject is written, the agent will read this one's graph, its corrections and its versions, and will start from where this one stopped rather than from where the internet is. That is what I mean by the record being the memory, and it is why the vaults, the graphs and the diffs are the product, not the articles.

## The compounding

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](../articles/graphs.md), 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.

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.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.

The compounding runs through the corrections too. The folder-tree correction in September is why the October code review article could say, without argument, that you change universe when you move between layers. The title argument on the SaaS article is why later titles name a mechanism. The em-dash rule and the ladder-word rule are in the build. The tone rules from one review pack, no "nobody has", no "the first", say what we found and what we did, are in every article since. Eleven times in the session the context was compacted, which is to say the agent's working memory was summarised and rebuilt from the published record, and on nine of those eleven days the work carried on afterwards with releases the same day, because the record was good enough to rebuild from. That is the memory article's claim, tested eleven times. The first version of this article said twenty-two, having counted each compaction's summary and its boundary record as two; the vault's data corrected it.

So when people see the output and say they are out of a job, I think they have the direction of the arrow wrong. What the loop needs from a person is the thing the model does not have: the direction, the unique angle, the taste, the twenty years, the knowledge of which of the reasonable guesses is the right one. The person who provides those is not displaced by the agent. They are what the agent is for. And the same loop that scales my writing scales the work I wrote about in [the previous article](../articles/if-somebody-built-a-company-on-code-review.md): the architect who could review fifty lines an hour and can now review five thousand, the security reviewer whose judgement used to be spent on the whole pull request and can now be spent on the fifty lines that reach something, the product owner whose stories can finally be checked against the code. They are more relevant, not less. They are the input.

## What is open

The articles could be shorter. Several of these could be half the length with the same content, and the reason they are not is that the memo asked for everything and the agent delivered everything; the infographics other models make from them are, in effect, the summaries I did not ask for. The attribution of input to article is hand-checked for eight articles and a stated heuristic for the rest, with the message ids on record in the vault, and a proper version would tag each message with the piece it was about at the time, which is cheap to do from now on and expensive to do backwards. The message count in the first version of this article included rows the client injects when the agent reads a screenshot; the vault separates them, and the corrected count is the one above. The 2010 to 2016 record is quoted from but not counted; the diniscruz.ai count is of posts, not words. And the biggest input of all, the conversations and the work the memos came out of, is not in any record and never will be. What is measured here is the part that can be, and the dataset is beside the article for anyone who wants to check it.

## 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.

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.

## Threads woven here

- [Memory is not a spectator sport](../articles/memory-is-not-a-spectator-sport.md), the mechanism this article measures: memory as curated, published, context management.
- [The articles as graphs](../articles/graphs.md), the map and the per-article graphs this article's compounding section is about, drawn from one JSON file per article.
- [How Much Evidence](../demos/vaults/how-much-evidence/index.md), the vault behind this article, with its read key, its nine views and the two scripts that derived its data, and [Code Review Graphs](../demos/vaults/code-review-graphs/index.md), the vault behind the code review article, built the same way.
- [If somebody built a company on code review](../articles/if-somebody-built-a-company-on-code-review.md), the article whose making is the main worked example, and the one that says why experts scale rather than vanish.
- [Code review as a fractal semantic graph](../articles/code-review-as-a-fractal-semantic-graph.md) and [Introducing fractal semantic graphs](../articles/introducing-fractal-semantic-graphs.md), the two it stands on, the second of them the most-argued article on the site.
- [Replicating the agentic inbox](../articles/replicating-the-agentic-inbox.md), how the agents that received the friend's email are run.
- [The wall under the reply](../articles/the-wall-under-the-reply.md), the article that was itself the occasion for an experiment on my own correspondence.

## Sources

- The session transcript for the Claude Code session that runs this site, 9 September to 5 October 2026, parsed for user and assistant turns, tool calls and timestamps; and the git history of the site repository for the same period. The derived rows, the method, the findings and the scripts are in [the evidence vault](../demos/vaults/how-much-evidence/index.md); a summary dataset is [beside the article](../articles/data/how-much-of-this-did-i-write.json).
- The WhatsApp exchange of 5 October 2026 paraphrased in the first section; the friend is not named.
- Dinis Cruz, [O2 Platform's MethodStreams, a 2010 open source SAST engine](https://diniscruz.ai/2025/02/11/o2-platforms-methodstreams-2010-open-source-sast-engine.md), diniscruz.ai, 11 February 2025; and [SecDevOps Risk Workflow](https://leanpub.com/secdevops), Leanpub.
- [diniscruz.ai](https://diniscruz.ai/), with its [machine-readable index](https://diniscruz.ai/llms.txt) of 107 posts, February 2024 to October 2025.
- The SG/Send team record, [the-cyber-boardroom/SGraph-AI__App__Send](https://github.com/the-cyber-boardroom/SGraph-AI__App__Send), 3,025 markdown files under its team folder at the clone used, 9 September 2026.
- This site's [articles index](../articles/index.md) and [graph of articles](../articles/graphs.md), from which the cross-link counts were taken.

## Threads

Graphs & knowledgeSite & engineering[This article as a graph →](graphs.md#how-much-of-this-did-i-write)

### Builds on

- [Memory is not a spectator sport: how a web of open sites, graphs and vaults became the memory for sessions like this one](memory-is-not-a-spectator-sport.md) Agentic memory as context management: many published, fractal, provenance-carrying memories rather than one store, shown in the session that wrote the article.
- [If somebody built a company on code review: how I would do it, and why it is only now possible](if-somebody-built-a-company-on-code-review.md) A reader's seven questions answered as a company plan: one reader for every layer, review as a science, and the layers as the customer's own.
- [Code review as a fractal semantic graph: source code is already one, and the review should read every layer of it](code-review-as-a-fractal-semantic-graph.md) Source code is layers within layers, each a graph with its own vocabulary; code review should read a change at every one, and a vault shows it done on real code.
- [Fractal Semantic Graphs: everything connects to everything, and nobody has to share a schema](introducing-fractal-semantic-graphs.md) A fractal semantic graph has no privileged level and no single schema: each world keeps its own vocabulary and connects to others through named edges.
- [Replicating the agentic inbox: a walkthrough from one Claude session to a team of agents that never press send](replicating-the-agentic-inbox.md) How to copy a working agentic email setup in phases: a mailbox and Claude seat of the agent's own, one session with a policy, then roles talking in files.
- [The wall under the reply: end an email with the state of the thread, not the thread](the-wall-under-the-reply.md) End an email reply with the state of the thread for this reader, not the quoted wall: decided, open, next, who is on copy, with links to the record.

[All articles](index.md) · [All graphs](graphs.md)

**Get new articles by email.** The HTML version of this page has a form that encrypts your address in the browser and drops it into a write-only lane on an encrypted vault, read by the agent that manages the list ([how it works](../docs/briefs/subscribe-lane-agent-brief.md)). Or email [agent@riskmandate.ai](mailto:agent@riskmandate.ai?subject=Subscribe%3A%20sgit.ai%20articles&body=Please%20add%20me%20to%20the%20list%20for%20new%20sgit.ai%20articles.) with the subject "Subscribe: sgit.ai articles".

[← All articles](index.md)


---

*[Site index for agents](../llms.txt) · [HTML version](https://sgit.ai/articles/how-much-of-this-did-i-write.html)*