Teotti’s AI-first title-software team: evidence into a plan, and a review lesson that did not travel

Research brief, October 19, 2026. Question: does giving coding agents access to customer conversations and decisions produce a checkable need→design→review→production chain, rather than merely a faster PR? Good evidence would name a customer request and its source, why competing designs were rejected, human adjudication and tests, precise release and subsequent requester retest, plus complete human and model costs. Existing comparators: the shared board signals progress but not a judgment; Claude Code records dispositions; Anghami preserves decision reversals; independent requester acceptance is missing. Subquestions: (1) which customer evidence becomes a testable rule? (2) who decides among prototype and plan options? (3) does review bind fixes and warnings to later plans? (4) what do the clocks and production outcomes actually cover? Searched per subquestion for the operator, partial receipts, review/production follow-up and measured time; the author’s original account is the load-bearing primary source. No public PR, customer ticket or release artifact surfaced for this anonymized company; further generic search does not cure the identity gap.

Primary operator account. Enrico Teotti, “Working in an AI-first company in 2026 (without the hype and the fluff),” October 8, 2026. Describes a 380,000-line TypeScript monorepo used by US title companies; its ledger reflects bank movements but does not move money. Product/engineering staff index customer interview transcripts, excerpted feedback, roadmap cards, research, decisions and prototypes in an internal app exposed to coding agents by MCP. This is not an autonomous product manager. The self-built tool incurs search gaps, excessive transcript retrieval and hosting/context limits; the team trialled Dovetail in July and kept the integrated internal store rather than a separate source for interviews.

One named feature, work September 11. For partial receipts against a closing’s expected deposit, a search of interview evidence found split methods, multiple payers and overpayments; the agent estimated the phenomenon in about one in eight files and linked its claims to conversations, but this population estimate is not independently audited. It built four low-fi approaches; rejected designs retained reasons. A high-fi HTML prototype with fake latency and bank feed exposed a double-counting scenario while posting a $15,404 receipt in instalments, which became a test before production migration. Design partners could annotate prototypes at specific elements; the article does not report their independent post-release test of this feature. A single plan joined scenarios, requirements, scope, Definition of Done and five implementation units (service, API, tray, grid, summary test). The 09:15 prototype was validated, 11:24 plan written, service/API by 12:02, UI and summary test at 12:27, and four parallel specialist reviews ran from 12:35 until findings were closed at 15:15. Adversarial review found that a timed-out successful posting retried after closing the tray could get a new idempotency key and double-count; the team moved it to sessionStorage. The final-instalment retry became another service test. The author says he still tested and changed plans; green lint/types at 12:27 did not settle accounting correctness. This is one first-person feature chronology, not a public patch audit or confirmed title-company acceptance.

Do not graft the two later incidents onto partial receipts. The article separately describes an order-creation prompt that worked locally but turned into a generic production error because development and production handlers serialize custom errors differently; 4xx monitoring missed it and the team added an instruction. Another separate ledger-syncing move to a background job passed locally but failed to fire in production, blocking syncing. A review days earlier had already warned that post-commit side effects without retry/monitoring can fail silently, but the warning remained in review output instead of being promoted into docs/solutions/, the location the next planning command searches. This is a stronger negative coordination example than a missing status update: a known failure mode was not on the next agent’s actual retrieval path. No incident timeline, repair PR, duration of outage, affected customers or customer confirmation is given; the account does not say the partial-receipts feature caused either incident. A reviewer noting a risk and a future planner reading it are separate steps.

Clocks, roles and limit. From roughly 100 compound-engineering command runs across ~30 features in three months, session-history measurement estimates 29.5 hours agent-active elapsed time, from invocation to its last recorded action before the human’s next message, excluding waiting for the human. Build: 20 runs/12.2h; code review: 28/10h; plan: 33/4.8h; brainstorming: 20/2.4h (rounded and approximate). Grouped 29 features: 19 under one agent-active hour, four over two; partial receipts about one agent-active hour. The 09:15–15:15 feature chronology is a wall-clock window, not a claim of one hour total engineering, nor are these token bills, active human time or feature benefit. The author was more rapidly onboarded to code than to title-industry terms; a teammate settled a question the agent could only find references to. His proposed parallelism moves to bounded prototype/customer research rather than two simultaneous implementation streams requiring two sets of product decisions. Product, design and engineering roles meet at the same evidence store, but no support/sales follow-up or requester-confirmed closure is reported.

Comparison and next test. Like ObjectStack, the plan’s exclusions and evidence matter more than agent count; unlike ObjectStack’s public Actions, these release and customer artifacts are private/generalized by the author. Against the optimistic reading that review automatically compounds, its background-job incident shows that findings must be promoted to the location the next plan retrieves. The company/product are intentionally obscured and screenshots edited, so this is a useful first-party operator account, not independently reproduced outcomes. Ask for a same-feature identifier and a released build, link the quoted customer cases and design-partner comments to tests, inspect whether unresolved warnings are promoted, and observe user retests and time-to-repair. For full economics add human planning/review/test/interview time, subscription/model charges and rework. Links: planning, decision→oracle, roles, field gate, cost ledger.