Thanks for your interest, and your comment, and your encouragement, and your feedback.
First, there's azeirah's excellent comment re: maintenance being a necessity (and paying off!).
Second, I really agree with you, in the sense that agents suffer a lot from contradictory, opposite requirements; but I would argue that they also suffer from under-specification, and that these two risks actually overlap (underspecification in the present can lead an agent to make choices that in the future will lead additional underspecification to have very little relevance or be contradictory with choices the agent has already made).
Part of the importance of the records in my methodology as I advocate them is that they be epistemically coherent. It's not a series of "do this, do that" or "requirement X, Y, Z, execute W, T, U", it's more of an extended explanation for what our situation is, what the idea is, how we are putting it into place, why, and what are the non-obvious choices we are making and why are we making them.
The agents, in my experience so far, don't get confused:
- they only read ADRs that are relevant to their work;
- when importing ideas/decisions from an ADR cross-project, the models (or their sub-agents) are never confused about the differences in context — they understand that project A (TypeScript, web, hosted on GitHub Pages) is different from project B (Rust, CLI, locally run) and how to adapt the imported decision accordingly.
Part of it is because, in the way that I've been building and practicing this, there's a requirement of epistemic coherence and epistemic consistency — everything is explained, nothing comes like a Deus Ex Machina which the model then has to extrapolate (and possibly be wrong about). In my experience this doesn't lead to models hallucinating requirements.
First, there's azeirah's excellent comment re: maintenance being a necessity (and paying off!).
Second, I really agree with you, in the sense that agents suffer a lot from contradictory, opposite requirements; but I would argue that they also suffer from under-specification, and that these two risks actually overlap (underspecification in the present can lead an agent to make choices that in the future will lead additional underspecification to have very little relevance or be contradictory with choices the agent has already made).
Part of the importance of the records in my methodology as I advocate them is that they be epistemically coherent. It's not a series of "do this, do that" or "requirement X, Y, Z, execute W, T, U", it's more of an extended explanation for what our situation is, what the idea is, how we are putting it into place, why, and what are the non-obvious choices we are making and why are we making them.
The agents, in my experience so far, don't get confused:
- they only read ADRs that are relevant to their work;
- when importing ideas/decisions from an ADR cross-project, the models (or their sub-agents) are never confused about the differences in context — they understand that project A (TypeScript, web, hosted on GitHub Pages) is different from project B (Rust, CLI, locally run) and how to adapt the imported decision accordingly.
Part of it is because, in the way that I've been building and practicing this, there's a requirement of epistemic coherence and epistemic consistency — everything is explained, nothing comes like a Deus Ex Machina which the model then has to extrapolate (and possibly be wrong about). In my experience this doesn't lead to models hallucinating requirements.