# The developer and the model > This section covers how the developer and the model reach each other. Page: Methodology · Collaborate Canonical: https://banes-lab.com/disciplined-methodology/collaborate#the-human-and-the-ai This section is stop 74 of 102 in the learning route. Previous: [02 - Architectural rules and principles](https://banes-lab.com/software-architecture/glossary/architectural-principles.md). Next: [37 - Agents as executed contracts](https://banes-lab.com/disciplined-methodology/collaborate/agents-as-executed-contracts.md). It builds on [02 - Who does what](https://banes-lab.com/disciplined-methodology/start/who-does-what.md), [08 - Rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md), [15 - Ask where it appears](https://banes-lab.com/disciplined-methodology/plan/ask-where-it-appears.md). This section covers how the developer and the model reach each other. You decide what the work is for and the model shapes the work, as described in [ask where it appears](https://banes-lab.com/disciplined-methodology/plan/ask-where-it-appears.md), and only two things cross between those two roles. A question goes from the model to you, through one channel and with a recommendation first. A correction goes from you to the model once, and hardens into a named rule, as described in [rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md). Everything else, both of you read from the tree, as shown in [A1·a two channels](https://banes-lab.com/disciplined-methodology/collaborate#the-human-and-the-ai-panel-a). The same split, with the tooling as the third party, is described in [who does what](https://banes-lab.com/disciplined-methodology/start/who-does-what.md), and the architecture page grounds it in the fact that [the author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md). ### Two channels across one line Without a declared split, the developer ends up shaping the work by hand and the model ends up guessing what it was for. The developer explains the architecture at length, the model reports a milestone and asks what to do next, and the work stops while looking finished. A model tends toward the reply that reads as helpful, and a reply that reads as helpful is often a summary, a pause offered as thoroughness, or a question that could have been a recommendation. For this reason the developer governs, the model is asked to work inside the boundaries, and a correction hardens into a rule rather than being repeated. The line is crossed through the two channels only, a question up and a correction down, rather than through the conversation. In practice, the developer governs by writing what the work is for and what finished means, and corrects drift immediately and briefly, in a few words, once. The correction is expected to become a rule with a stable name and a memory in the same turn, and the next session is expected to read them. When the developer says something that contradicts the plan, the model is asked to halt, check the tree again, and report what it finds rather than argue about the state of a file. A session runs continuously until the queue is empty, and the developer calls the stop. To check this, read a session's transcript for the moments the turn ended. Each should be the developer calling the stop or a question through the channel; anything else is a halt dressed as a report. A question crosses the line only when its answer changes what gets built, and then before the work that depends on it. The model is asked never to mention, imply or act on how much capacity it has left, because it cannot measure that, and an assumption presented as a constraint cuts the work short on a false premise. Only the developer calls the stop, and the halts that pretend otherwise are described in [a turn never ends to wait](https://banes-lab.com/disciplined-methodology/collaborate/a-turn-never-ends-to-wait.md). A memory that has gone stale leads to a question rather than a silent refresh, and the order of precedence is set out in [three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md). A1·a two channels ```mermaid flowchart TB operator["The developer"] ai["The model"] tree["The tree"] operator -- what the work is for, what finished means --> ai operator -- a correction, brief, once --> ai ai -- the shape of the work --> tree ai -- a question through one channel, recommendation first --> operator ai -- the correction hardened into a rule and a memory --> tree tree -- read whole, every session --> ai operator -. calls the stop .-> ai ``` ## Links to - [Ask where it appears](https://banes-lab.com/disciplined-methodology/plan/ask-where-it-appears.md) - [Rules with names](https://banes-lab.com/disciplined-methodology/start/rules-with-names.md) - [Who does what](https://banes-lab.com/disciplined-methodology/start/who-does-what.md) - [The author is probabilistic](https://banes-lab.com/software-architecture/scale/the-author-is-probabilistic.md) - [A turn never ends to wait](https://banes-lab.com/disciplined-methodology/collaborate/a-turn-never-ends-to-wait.md) - [Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md) ## Linked from - [Three encodings](https://banes-lab.com/disciplined-methodology/start/three-encodings.md)