I agree. But that usefulness can be deceptive, especially when one thinks enough context has been captured to prevent misunderstandings. An LLM (or human, to be clear) can easily
go down the wrong path from their own assumptions, and now you have three problems.
My main complaint is that articles like this lead people to think they they can avoid those three problems, without understanding why there are three.
I can’t tell from the text if the first paragraph of your response is meant to be ironic or tongue-in-cheek, but it certainly works that way.
It feels hard to recognize that you agree with me from the following paragraph of your post
> This is similar to asking Sarah why the team went for A over B, but without the imperfections of human memory, and available to agents as well. When an agent reads it, the decision isn’t an arbitrary historical fact - it’s the conclusion of an argument the agent can now evaluate and extend.
I definitely agree that human knowledge is imperfect, and that documentation is needed. But I just cannot get around the fact that the following sentence, out of context, can refer to football, American football, and basketball : ‘I passed to the center, and we scored’ and without more context, each of those can have multiple meanings even in each of the sports I named.
const hello = ‘world’
Is valid in so many programming languages that need more context.
No, the agents don’t ask Sarah, but maybe they should. And maybe I’m on this soap box because the thing is that I write internal line of business software and the technical stuff is easy. But when Sarah is the inside sales manager or the industrial engineer a continent away who speaks a different language, the reality of adequately capturing context for decisions that others have made that our software has to implement, and in a context rich enough for documentation to be succinct, is enough to make me frustrated with articles like yours that hand-wave that into ‘trivial to capture in documentation.’
>None of the three can easily be captured in code, but are trivial to capture as documentation.
Posts like this frustrate me. Not because of what they ask, but because of what they incorrectly assume. They assume that documentation can provide enough context, and that human knowledge is not needed.
Every bit of written documentation can and will be misinterpreted. And perfect clarity is impossible. A well-written ADR does not eliminate all ambiguity, because there is too much cultural context around the writing of the ADR that attempting to read it from some other cultural vantage point leads to bad assumptions. We can find this basic lesson from reading law (2nd, 14th amendments to the constitution), history (what did happen after Muhammad died?), philosophy (what in the world is Plato's cave talking about?), or theology (how should we translate Ephesians 5:22-33 and what does that mean) outside its original context with other people.
Just writing things down and thinking an AI is going to later perfectly understand what the intent of the author is... patently ridiculous. I do not intend to dismiss the idea that we should probably document more, but the idea that the AI can just take our documentation and competently understand all the decisions represented in them is ludicrous.
You're not entirely wrong that double-entry accounting doesn't add much to keeping track of one balance. And the example provided in the article was very simple, just like mine was very simple. Transactions do help, but if you are trying to keep track of a balance and understanding how that balance is changing, double-entry accounting is helpful.
I'm not sure CRDTs are actually the right answer here for your example of #2, Marco. A double-entry accounting system might actually be more ideal. In that case, what you are keeping in sync is the ledger, but depending on your use-case, that might actually be easier since you can treat them as a stream-of-data, and you would get the 'correct' answer of 100.
In this case, you would need two accounts, a credit and debit account, and then device A would write +20 to the credit account and -20 to the debit account, device B would write -20 to the credit account and +20 to the debit account, then using a HLC (or even not, depending on what your use-case is again), you get back to the 100 that seems from the description of the problem that it is the correct answer.
Obviously, if you are editing texts there are very different needs, but this as described is right in the wheelhouse of double-entry accounting.
My main complaint is that articles like this lead people to think they they can avoid those three problems, without understanding why there are three.