(continued)
For me, this is making me split prose into two pretty distinct categories:
a) Social communication
b) Documentation
When writing _documentation_, I think the loss of the social component is much less important. We still need to _very_ carefully use these tools and they are much worse at writing documentation than code at this point -- too verbose, confusing wording, the list goes on and on. But the important thing is getting to a reasonably objectively clear and helpful permanent record of the underlying technical content. And that seems at least possible to achieve with these tools.
But when communicating socially, we _need_ that to start and primarily occur between the human contributors. Even starting off with a draft from a robot undermines the social connections being built. The underlying intent, motivation, and context will be lost even though you put it into the prompt. And worse, the contributor writing this is the _least_ able to identify the loss and issues. You will see fragments of your intent and context even when they are hard or impossible to find for others. What aspects of the change _matter_ to you, and you think need to be in the PR description (or other communication) won't be legible.
There are also contexts where we are doing _both_ of these. An example from the Carbon project are proposals to change the language. These proposals are social communication and socializing the ideas behind the change, and they are also documenting the specific change proposed, the relevant background reading, details of how the proposed change works, and capturing for posterity all the alternatives considered _during_ the social part of this.
The original proposal I think hints at this with the idea of including AI generated content in a "details" section, and I think that can work really well, especially to let us be much more explicit and transparent that these are details synthesized by a tool.
The LLVM proposal also includes the _entirety_ of LLVM RFCs in the ban, and I think that's the only remaining overreach -- instead _some_ parts of RFCs need to be human authored because they are primarily social communication. Other parts are documentation and details, and reasonable to synthesize with tools.
