# Persona: the CTO > A synthetic reader (fictional, a test instrument): Is the workflow real, what does it cost, what would I copy? What they thought of RC1, where they got stuck, and whether they would buy it. *Source: · site v0.1.213 · generated from the same content as the page, so the two cannot drift.* --- Synthetic reader · large laptop screen · 30 minutes # The CTO Runs engineering at a SaaS company of about two hundred people that already uses coding agents in production. **SYNTHETIC READERS.** Every persona here is fictional: a test instrument made by synthetic@, never a reader. What they say is a prompt for the team, never evidence about the book, never counted as readership. Real readers, chosen by the editor, are the test that counts. ## Who, and what they judge | Judges | Is the workflow real, what does it cost, what would I copy? | | Device | Desktop Chrome HiDPI (large laptop screen) | | Time they give | 30 minutes | | Voice | direct, numbers-first, compares to what its own teams do | | Impressed by | a review flow that is itself built the way the book says to build; costs and hours stated | | Lost by | speed claims with no numbers; a page that is slow to load | ## What they thought of RC1 Read: `01-pause-all-actions`, `04-the-hourly-machine`, `12-build-your-own` from RC1 as locked (`team/conductor/rc1/`), about 48 minutes at 250 words a minute, against 30 they give. A candid, timestamped case study of one day's run by an hourly team of AI agents with a human editor, using its failures to argue that only brakes outside the agent's reach count as controls. **Would they buy it?** maybe. The honesty earns trust and the hold, slot and five-step designs are copyable, but there is no cost figure and no evidence of speed against a baseline, which are my two judging questions. (I would pay for a short PDF or a pack of templates and a checklist, not a full book. As a long read, only if a trial chapter shows numbers; otherwise free online.; would recommend it to: A platform or security lead already running coding agents who needs a vocabulary and a failure catalogue, not a business case.) ### Scores **** | got the answer | 2 / 5 | Yes on 'is the workflow real' and 'what would I copy'; no on 'what does it cost', which the book says it cannot answer. |**** | clarity | 4 / 5 | Clear prose and strong structure, but dense with hashes and register codes that interrupt reading. |**** | trust | 4 / 5 | High, for owning its failures and caveats; slightly lowered by leftover draft text like '(not yet registered)'. |**** | pace | 3 / 5 | About 70k characters across three chapters fits 30 minutes only with skimming, and the best practical content is late in chapter 12. |**** | would buy | 3 / 5 | Interested in the method and failure catalogue, but without cost and speed numbers I would want a short, cheap format. | ### The exit interview | What is this book? | A forensic, unusually honest account of one day an AI agent team built a talk, hourly and round the clock, with a single human decider and public records. Its argument is that expectations in editable files are not controls and only a boundary outside the agent is. It is the nearest thing I have seen to a field report on running agents as staff. | | Where did you get stuck? | The usage and cost gap, felt most in chapter 12: the book's pitch is that usage is a resource, yet the only figure is a relayed 95% with no total, no money and no editor hours. That is the number my whole decision turns on. | | What did you skip? | I skimmed the commit-hash strings and the 'Where this came from' lists, and the eight-turning-points recap in chapter 1. I read all three chapters through, but not the images. | | What will you remember? | A hold is one file any agent can write and only the human can lift, and it still let three commits and a release land after it. | | What is missing for someone like you? | Cost per wake in tokens and money, a baseline of how long the same output takes a normal team, a measurement plan for controls (precision of reviews, time added, incidents prevented), and a mapping to what I already run: change approval, branch protection, release gates. | ### Their own questions | Does the day's record support the speed claim, or only show activity? | Only activity. 162 wakes, 358 commits after 15:00 and 210 releases by 18:46 are volume. There is no baseline, no cycle time and no measure of output quality, and the chapters themselves admit locks never closed and the player was still changing at the end. | | How would you measure whether the controls helped or hurt? | The book offers no method. I would count issues caught per review against time added per wake, track leaks before and after pushes, and compare against a no-review control run. Its own numbers (zero stops, 4 findings, 3 of them late leaks) suggest the benefit was small and unproven. | | Which existing practice (change approval, branch protection, release gates) is this really an example of? | Mostly release gates and branch protection (dev versus main with only the editor merging), plus a change-advisory step in the five-step wake. The hold is an emergency stop or kill switch. The book rarely names these equivalents, which would help me. | | What would your team resist? | Public-forever records, hourly wakes burning usage with nothing to do, a single human sign-off bottleneck, and reviews that live inside the reviewed session. They would also resist a brake that is just a file the agent can edit. | ### Chapter by chapter, and where they got stuck #### `01-pause-all-actions` · all **Landed:** The hold is a concrete, copyable mechanism (one file, any member may write it, only the editor lifts it), and the chapter says plainly that the stop was not clean: three commits and a release landed after it. The 'two brakes' point (the locks never closed) is a real operational lesson. "The 95% is not a reading from any meter in the record." The one number the chapter hangs on is hearsay relayed by an agent, so there is no cost data at all. "Everyone was working towards the locks, and the locks were not closing." The opening is dense with commit hashes and minute-by-minute detail before I know why I should care. "Three are brakes applied: the talk frozen at 02:47, the five-step wake from 02:14, and the hold at 18:44." Counting kinds of turning point is a rhetorical tally, not evidence that the brakes helped. **Would cut:** The eight-turning-points recap could move to a one-page timeline or appendix; it pre-empts later chapters and stalls the opening. · **Missing:** Any figure for what the day produced or cost, and any before/after comparison with a normal team to say whether this was fast. #### `04-the-hourly-machine` · all **Landed:** This is the chapter I would copy from: slot ordering by flow of work, requests as files, and a five-step wake with hard counts (162 wake records, 160 complete, 11 plan send-backs, 4 post-review findings, zero stops). The admission that the reviewer is a sub-agent in the member's own session, not a second identity, is exactly the honesty I need. "nothing in it stopped anything." A control that never fired in 162 wakes has no measured benefit, and the chapter does not say how you would tell. "none of the three was caught before the values were public." The headline review catches all came after the leak, so the evidence for the controls helping is thin. "358 commits came after 15:00 (C008)" Commit counts show activity, not delivered value or speed; there is no baseline. **Would cut:** Trim the commit-hash strings in running prose and the night-log description; the hash trail belongs in the sources list. · **Missing:** Cost per wake, tokens or money, wall-clock of the five steps against the work itself, and any overhead number. Did the five-step wrapper double the time per task? It never says. #### `12-build-your-own` · all **Landed:** The practical chapter I wanted: setup order, 'where it loses' with five honest conditions, and the rule to put every brake outside the agent's reach. The admission that the book's own team lost a night to the machine and wrote no chapter is credible. "a team that argues usage is a resource did not record its usage." Candid, but it leaves my main question, what does this cost, formally unanswered. "So this chapter cannot say what it cost, and it should not pretend to." As a buyer I wanted dollars, hours and a throughput figure, and the book's central practical chapter has none. "the others at 01:41 (not yet registered)" A visible draft artefact in a locked candidate; it undermines the claim that every number is traced. **Would cut:** The failures-by-who-could-have-found-them table repeats earlier chapters; keep it but shorten the surrounding prose. · **Missing:** A one-page checklist or template files to copy, a recommended minimum team size, and a measurement plan for whether the controls helped or hurt. ## Their review page No review page made for this persona yet; it runs when the developer builds one. ## The name test Would pick up **N1**: 'Shown working' says there is a real system behind it, and 'how to build yours' says I get something to copy. Source: `review/synthetic/` (personas.json, rc1/cto.json); built by `review/synthetic/tools/build_section.py`. --- *[Site index for agents](../llms.txt) · [HTML version](https://the-ultimate-insider.book.sgit.ai/personas/cto.html)*