Adam Lewis

Domain-based is the property I've found hardest to retrofit. Names inside a file can be fixed a function at a time. A repository organised into controllers, services and repositories has to be moved wholesale before a single business change stops being scattered across it, and that is work nobody budgets for. It matters more now that an agent reads the tree before it reads anything else. A top-level checkout directory tells it where a change belongs. The comparison table is a good addition, particularly the row on how each set fails once it turns dogmatic. https://prickles.org/tenet/screaming-architecture/A1

I don't work in payments, but the roundMoney() point travels. A generic helper hides which boundary required the rounding, and once the operation is named the rule it implements has somewhere to live. Same with the Money type over a bare decimal, the scale and the rounding rule end up in the type where the compiler can check them instead of in a convention someone has to remember.

I've hit the same requirement on anything a non-developer edits, where a validator that stops at the first fault gets exactly the reception you'd expect. The rule I'd add to the split is about its own discipline: you note that nothing downstream of validate() runs on an Invalid result, and that constraint lives in prose rather than in the types, so it's the one a later change breaks first. If it can be a lint rule or an architectural test it holds, in my experience a written convention alone doesn't. I argue the stricter version of the type-level side here, with less room than you allow for the reportable case: https://prickles.org/tenet/domain-driven-types/T1

The valid-JSON-but-wrong case is the one that worries me with agents, because everything downstream treats parsed as true. I keep a verification step in the workflow itself, so the agent has to run the check or quote the source before a result gets used, whichever tool produced it. The MemToC numbers are better evidence for that habit than I had before.

The signal I watch for is the first one on your list, small changes creating unrelated regressions. That is the point where prompt-and-test stops being cheap, because every change needs a human to rebuild confidence that the tooling should be supplying. We've kept the agent and made the gates deterministic instead, tests and static checks that run on every change regardless of who or what wrote it. The cost of change stays visible on the build, which is most of what the hybrid model needs.

Good explanation, and the section on not adding an interface for everything is the one most write-ups leave out. I'd add that this matters more now that agents write a lot of first drafts. Left to themselves they construct the concrete sender inside the service every time, because that's the shape most of the training data has, and they will also add an interface for a class that will only ever have one implementation if you tell them to 'apply SOLID'. Both need a rule in the repo. The agent side of DIP, if useful: https://prickles.org/tenet/dependency-inversion-principle/A11

Most of the review arguments I've sat through were two people discovering they'd assumed different requirements, so settling that in the spec first has cut most of them off. I've written up how I approach it here: https://prickles.org/tenet/spec-first-execution/P2

The clarification step is the one I see skipped most often, so it is good to see it named as work rather than overhead. I keep the questions and their answers in the spec itself, and the agent checks back against them as it builds. A surprising amount of review argument disappears when the ambiguity was settled in writing first.

That makes sense, an observed cap is more defensible than one picked up front because it comes from what the skills actually needed. And the number matters less than the fact that hitting it makes you stop and check whether the skill has quietly taken on a second job. Cheers for the detail.

Nice. The thing I'd point to in what you did is that the consensus ends up written in a doc the agents re-read, rather than only living in the session that produced it. That's the same reason the per-decision markdown files have stuck for me - the agreement survives the context window, so the next run picks it up instead of going over it again. I'll read through the synthesis proposal. Multi-agent coordination is one I haven't spent much time on yet.