--- title: "Discussion on \"AI Promoted Everybody. Architecture as Truth (AAT) Is the New Job.\" | Hashnode" description: "Discussion on \"AI Promoted Everybody. Architecture as Truth (AAT) Is the New Job.\". In short. AI now does the production work in software: the code, the documentation, the business scenarios, the epics. What is left for people is the work that used to belong to senior staff: understa" url: "https://hashnode.com/posts/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job/6aef339d53dce3d06aa7ac1e" --- [Feed](https://hashnode.com/feed) / Discussion # [AI Promoted Everybody. Architecture as Truth (AAT) Is the New Job.](https://puglieseweb.hashnode.dev/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job?utm_source=hashnode&utm_medium=feed) In short. AI now does the production work in software: the code, the documentation, the business scenarios, the epics. What is left for people is the work that used to belong to senior staff: understa 5d ago · 14 min read · puglieseweb.hashnode.dev Read the article - [#software-architecture](https://hashnode.com/tag/software-architecture) - [#ai](https://hashnode.com/tag/ai) - [#ai-agents](https://hashnode.com/tag/ai-agents) - [#software-engineering](https://hashnode.com/tag/software-engineering) ## Written by [Emanuele Pugliese](https://hashnode.com/@puglieseweb) @puglieseweb · Hook [View profile](https://hashnode.com/@puglieseweb) Founder of PuglieseWeb. Sets out Architecture as Truth (AAT): architectureastruth.org, Founder of PuglieseWeb. I set out Architecture as Truth (AAT), a practice for building software with AI agents: the architecture documents are the single source of truth, people decide by changing them, and AI agents build from them. https://architectureastruth.org/ ## Responses 4 Markdown supported · ⌘↵ to post [Ahmet Özel](https://hashnode.com/@ahmetozel) [4d ago](https://hashnode.com/posts/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job/6aef339d53dce3d06aa7ac1e/comment/6af157fa68fd16fccf9bb925) The reminder-number incident is worth retaining as a fixture where the proprietor's notification number and the public customer-contact number are deliberately different. If sample data uses the same number for both roles, an implementation can read the wrong field and still satisfy the approved scenario. I would include a case where the public number is absent as well, with the expected behavior decided explicitly. That turns the amendment into a discriminating example rather than only clearer wording, and protects the business distinction when the contact schema or reminder implementation is changed later. [Emanuele Pugliese](https://hashnode.com/@puglieseweb) [3d ago](https://hashnode.com/posts/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job/6aef339d53dce3d06aa7ac1e/comment/6af157fa68fd16fccf9bb925#reply-6af198a9ae54986617771fcc) Thanks, Ahmet. Fair point, and checking it found a real gap. The absent case was already decided: with no public number, the text ends at the email, gives no number, and the reminder still goes. A test also had the proprietor's alert number set with no public number, and it stayed out of the text. But no test set both numbers at once. When we made the reminder give the alert number only if a public number also existed, the other 39 tests in that file still passed. We've now added the fixture you describe, with the two numbers deliberately different, and it fails on that change. One part is still open. The distinction now lives in a test, but the approved scenarios don't name it. Naming it there would be an amendment, and that's the step that would finish what you're suggesting. [Ahmet Özel](https://hashnode.com/@ahmetozel) [3d ago](https://hashnode.com/posts/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job/6aef339d53dce3d06aa7ac1e/comment/6af157fa68fd16fccf9bb925#reply-6af1a51b4b4391b4b0717ea1) That mutation makes the gap concrete: the other 39 tests accepted the wrong number only when both roles were populated, while the new fixture distinguishes them. The existing absent-public-number case already covers the separate delivery requirement. The amendment can record that tested intent: public copy uses the public contact value, proprietor alerts use the proprietor value, and missing public contact leaves notification delivery unchanged. Linking it to the fixture and mutation result would let scenario reviewers see exactly which previously ambiguous choice was resolved. [Emanuele Pugliese](https://hashnode.com/@puglieseweb) [3d ago](https://hashnode.com/posts/ai-promoted-everybody-architecture-as-truth-aat-is-the-new-job/6aef339d53dce3d06aa7ac1e/comment/6af157fa68fd16fccf9bb925#reply-6af1e8948ea4ab53bd916b26) Update: that's done now. The approved scenarios name both cases, and each fails if the alert number reaches the customer. They say what you describe for the customer's side: the reminder gives the public number, and with no public number it still goes, with no number in it. The change that added them carries the fixture and the mutation results for its reviewer. The alert's own delivery isn't covered by these scenarios. Thanks for pushing on it.