content: both apps were built from single-sentence prompts

Clarifies the strongest claim, which the articles were undercutting:
the founding PRD, architecture and plan documents were drafted by the
agent, not the author — from reference context the agent fetched for
itself (GnuCash's source and manual; Obsidian and Bear feature lists).
The author approved documents, and did not write them.

Both descriptions now say "built from a single-sentence prompt", the
FinvestLens ground-truth passage no longer claims the agent could not
have obtained the source it in fact cloned, and both articles close on
the point: a complete, shipping application, from a single sentence.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Author: ChristineTham

src/content/blog/2026-07-27-finvestlens-1-0.md

@@ -1,6 +1,6 @@
 ---
 title: 'FinvestLens 1.0: 56,000 lines of accounting software in fourteen days'
-description: A native Apple double-entry accounting app, verified against a real 46,000-transaction GnuCash book to the cent — built by writing specifications and issuing prompts. What the method got right, and what real data found that no test suite would.
+description: A native Apple double-entry accounting app, verified against a real 46,000-transaction GnuCash book to the cent — built from a single-sentence prompt, with the agent drafting its own specifications. What the method got right, and what real data found that no test suite would.
 author: chris-tham
 publishDate: 2026-07-27T07:00:00.000Z
 featuredpost: true
@@ -29,12 +29,14 @@ The first commit landed on 12 July 2026. This one is 26 July. In between: 325
 commits, ten Swift packages, 56,611 lines across 221 files, 1,179 tests, and a
 phase plan taken from P0 through P10.
 
-I typed very little of it, and less than you would guess. The instructions were
-mostly of two shapes — _"implement the next phase"_ and _"audit the implemented
-codebase against the plan and fix what you find"_ — issued to **Claude Code**,
-Anthropic's coding agent, running in an agentic loop. The specification said what
-done meant. The audits found the mistakes. That division of labour is the more
-interesting story.
+I typed very little of it, and less than you would guess. The whole project
+began as a single sentence — reimplement GnuCash as a native app for Apple
+platforms — and after that the instructions were mostly of two shapes:
+_"implement the next phase"_ and _"audit the implemented codebase against the
+plan and fix what you find"_, issued to **Claude Code**, Anthropic's coding
+agent, running in an agentic loop. The specification said what done meant. The
+audits found the mistakes. That division of labour is the more interesting
+story.
 
 The method was not improvised. It is the one I set out in Chapters 2 and 3 of my
 book [_AI-dō_](https://christham.net/aidou/) — the practice and the craft — and
@@ -48,13 +50,13 @@ on whether the Way holds up.
 Nothing here is exotic, and I'd rather state it plainly than let anyone imagine
 a secret ingredient:
 
-|              |                                                                                                 |
-| ------------ | ----------------------------------------------------------------------------------------------- |
-| **Agent**    | Claude Code — working directly in the repository                                                |
-| **Model**    | Claude Opus 5 (`claude-opus-5`)                                                                 |
-| **Language** | Swift 6 / SwiftUI, ten local Swift packages, one Xcode project                                  |
-| **Oracle**   | My own 46,553-transaction GnuCash book, GnuCash 5.16, and GnuCash's C/C++ source cloned locally |
-| **Sessions** | Many, across fourteen days — each beginning with no memory of the last                          |
+|              |                                                                                                       |
+| ------------ | ----------------------------------------------------------------------------------------------------- |
+| **Agent**    | Claude Code — working directly in the repository                                                      |
+| **Model**    | Claude Opus 5 (`claude-opus-5`)                                                                       |
+| **Language** | Swift 6 / SwiftUI, ten local Swift packages, one Xcode project                                        |
+| **Oracle**   | My own 46,553-transaction GnuCash book, GnuCash 5.16, and GnuCash's C/C++ source, cloned by the agent |
+| **Sessions** | Many, across fourteen days — each beginning with no memory of the last                                |
 
 The tools that actually mattered, as distinct from the ones that merely existed:
 
@@ -105,14 +107,16 @@ The temptation with a capable coding agent is to start asking for features. That
 is the main way these projects go wrong: you get a pile of plausible code with no
 spine.
 
-So the first artefacts weren't code. From a short statement of what I wanted, the
-agent drafted — and I reviewed — a **PRD** with numbered
-requirements, an **architecture document** with numbered decisions, a **porting
-strategy** mapping GnuCash's C modules to Swift ones, and a **phased plan** —
-eleven phases, each with objectives, dependencies, deliverables, exit criteria,
-test focus and risks.
+So the first artefacts weren't code — but they weren't mine either. From that
+one sentence, the agent fetched its own reference context — cloning GnuCash's
+source, pulling its user manual — and then drafted, for my review, a **PRD**
+with numbered requirements, an **architecture document** with numbered
+decisions, a **porting strategy** mapping GnuCash's C modules to Swift ones,
+and a **phased plan** — eleven phases, each with objectives, dependencies,
+deliverables, exit criteria, test focus and risks. I approved documents; I did
+not write them.
 
-That initial statement could afford to be vague because the reference context
+That sentence could afford to be that vague because the reference context
 was not. The product already existed — twenty-five years of it. GnuCash's
 source code, its user manual, its file format and its reports specify a
 double-entry accounting application more precisely than any requirements
@@ -142,14 +146,15 @@ Here's the decision I'd repeat on any project like this: **our own tests were
 never the final word.**
 
 The final word was GnuCash itself. The expectation was written that way, and
-three things were supplied for the agent to check against:
+three things sat on disk for the agent to check against — two of them supplied
+by me, the third fetched by the agent for itself:
 
 1. **A real book — mine.** My personal GnuCash file: 46,553 transactions, 559
    accounts, over 100,000 price records, multi-currency, a decade and a half of
    my actual financial history.
 2. **A real GnuCash install** (5.16) to produce reference reports.
-3. **GnuCash's actual C/C++ source**, cloned locally, as the porting oracle —
-   not the documentation, not the binary, the source.
+3. **GnuCash's actual C/C++ source**, which the agent cloned for itself as the
+   porting oracle — not the documentation, not the binary, the source.
 
 That third one changed the quality of the work more than anything else. A prompt
 like _"audit our lot and cost-basis implementation against the real GnuCash
@@ -303,9 +308,10 @@ rule assigning one to a transaction has no coherent target); Quick Look for
 `.gnucash` (it's the interchange format, not the document you browse). An agent
 will happily build all four. Deciding they shouldn't exist is the job.
 
-**I supplied the ground truth.** The real book, the GnuCash install, the source
-checkout, four genuine bank export files to validate the import matcher against.
-None of that is something the agent could have obtained.
+**The personal ground truth was mine to give.** The real book, and four genuine
+bank export files to validate the import matcher against — data no agent could
+obtain. The rest of the reference context the agent fetched for itself, starting
+with GnuCash's source.
 
 **And taste stayed mine.** Whether a dashboard reads well, whether a number
 means the right thing — I can be shown the screen, but the verdict is a decision
@@ -490,8 +496,9 @@ whether there are any.
 
 Which is the whole argument. State the intent and the expectations well enough,
 put something real within reach for the work to be checked against, and the rest
-— the implementation, the review, and the catching of its own mistakes — follows
-from the harness rather than from you.
+— the specifications, the implementation, the review, and the catching of its
+own mistakes — follows from the harness rather than from you. A complete,
+shipping application, from a single sentence.
 
 ## Try it
 

src/content/blog/2026-07-27-hellonotes-1-0.md

@@ -1,6 +1,6 @@
 ---
 title: 'HelloNotes 1.0: a Markdown knowledge base that is actually a Mac app'
-description: Fifteen days, 220 commits and 32,000 lines of Swift — a local-first knowledge base whose database is a folder, built by prompting. What the method got right, and the four traps that ate real hours.
+description: Fifteen days, 220 commits and 32,000 lines of Swift — a local-first knowledge base whose database is a folder, built from a single-sentence prompt. What the method got right, and the four traps that ate real hours.
 author: chris-tham
 publishDate: 2026-07-27T06:00:00.000Z
 featuredpost: true
@@ -145,7 +145,7 @@ Both the app and its website follow your Mac, or pin to one appearance:
 
 ## How this was actually built
 
-I wrote very little of this code by hand. I built HelloNotes by prompting [Claude Code](https://claude.com/claude-code), and the git history is co-authored throughout.
+I wrote very little of this code by hand. I built HelloNotes by prompting [Claude Code](https://claude.com/claude-code), the git history is co-authored throughout — and the whole thing began as one sentence.
 
 It wasn't improvised, either. I published **[AI-dō — The Way of AI](https://christham.net/aidou/)** — a book arguing that working with AI is a discipline rather than a vibe — on **8 July**. The first commit in this repository is dated **11 July**. HelloNotes is the first thing I've built start-to-finish under a method I'd finished writing down three days earlier — specifically [Chapter 2, _Personal Productivity_](https://christham.net/aidou/productivity.html) and [Chapter 3, _Software Development_](https://christham.net/aidou/software.html).
 
@@ -162,9 +162,10 @@ Before any code existed, I asked Claude to generate three documents based on my
 That intent could afford to be vague because the anchors were strong.
 HelloNotes sits in a category that existing products have already mapped —
 Obsidian for the linking model, Bear for what native ought to feel like — and
-the PRD was drafted against those reference points. The four-way gap in "The
-bet" above _is_ the specification: name what to keep and what to refuse from
-each anchor, and the requirements largely write themselves. A vague prompt over
+the PRD was drafted against those reference points — feature lists the agent
+researched and fetched for itself, not ones I wrote out. The four-way gap in
+"The bet" above _is_ the specification: name what to keep and what to refuse
+from each anchor, and the requirements largely write themselves. A vague prompt over
 strong references beats a precise prompt over none.
 
 The plan is the part that made this work. Each milestone wasn't a wish, it was a table — task, target file, and an **acceptance criterion**:
@@ -185,7 +186,7 @@ as one of those passes. Extending something that already runs is an easier
 conversation than specifying everything up front, because the app itself
 becomes part of the reference context.
 
-Why this works is worth being exact about, because the book states it as a caution: _"A model is a next-token predictor, not a compiler: it does not execute a specification, it produces the most plausible continuation of everything in its context."_ A spec doesn't help by being run — nothing runs it. It helps by putting the definition of _right_ into that context before the work starts, so that afterwards there is something other than plausibility to judge the output against. Commissioning that plan, and stating what "done" meant in it, was the highest-leverage work of the fortnight. Everything after it was "do Milestone 3".
+Why this works is worth being exact about, because the book states it as a caution: _"A model is a next-token predictor, not a compiler: it does not execute a specification, it produces the most plausible continuation of everything in its context."_ A spec doesn't help by being run — nothing runs it. It helps by putting the definition of _right_ into that context before the work starts, so that afterwards there is something other than plausibility to judge the output against. Commissioning that plan — and insisting the work be judged against the acceptance criteria in it — was the highest-leverage thing I did all fortnight. The heading above is not a paraphrase: one sentence went in, and the PRD, the architecture and the plan came out, drafted by the agent from context it had gathered itself. Everything after that was "do Milestone 3".
 
 (That plan has since been folded into [`implemented.md`](https://github.com/hellotham/hellonotes/blob/main/docs/implemented.md), which is the honest engineering log — milestones, fixes, and a lot of what _didn't_ work. It's still in git history if you want the original.)