Writing and verbal communication are core research skills we need to practice. All paper first drafts must be written without AI. Lab communication must follow the first-follow-up rule: lab members should know enough details about the code, experiments, and presentations they give to answer a reasonable first follow-up question from a labmate without checking with their AI assistant.
This document contains the expectations for my lab group for the use of AI in writing and communicating about research. I'm writing these policies in part to help guide my students, and in part to discuss some of the underlying issues about thinking. This policy may change in the future as we discuss and adapt as a lab.
Policy Points #
These expectations have scope over all writing and communication in the lab: writing papers, presentations in lab meetings, weekly 1:1s, slack updates, etc.
- Write the first draft without AI.
- Be ready for the first follow-up.
- Obey Grice's maxims of Quantity and Quality even when your agents don't.
- Be in charge of your technical terms.
Motivating Context #
I use AI agents throughout my work, especially in coding. They allow me to get more done than I'd otherwise be able to. However, our skills atrophy when they are not used, or worse, we never develop them at all. As such, I'm concerned about getting my own use of AI right somehow, and even more concerned about instilling good practices in my students. It's possible that some skills I love—like mucking with tensors and thinking about neural architectures—will be less necessary in the future. But communicating and clear thinking will always be necessary.
I'm increasingly presented with AI-generated writing, especially by potential new lab members, junior students, etc. In technical writing and thinking, it is very easy, and very low-value, to seem to know or communicate something. It is very hard, and very high-value, to actually precisely know and communicate something.
I don't expect students to go without AI agent use in general, and especially in coding, I expect them to use agents. However, in writing and communication, for the time being at least I've decided the lab needs somewhat strict standards to empower us to think clearly and communicate well.
Policies in Detail #
Write the first draft without AI.
For each piece of writing, from blog posts to papers to tweets to slack messages, the first draft must always be written by a human. 1 Writing is thinking and helps clarify one's understanding. Further, empirically, the anchoring effect of AI writing is too strong, even if a human provides substantial edits afterward.
The human first draft is also very helpful for ensuring that students know the math they're presenting. It's often not until I write up math in LaTeX for the first time that I realize some detail I'd been glossing over in my head or as I take scratch notes about the idea. If a model generates the math from the code that was vibecoded, those potentially critical details are just never interrogated. If the lab member writes out the math and then looks at the code and it implements something different, then it's a great find of a potential bug or miscommunication!
Be ready for the first follow-up.
A lab member must be ready to answer a first follow-up question from a lab member (including me) about the work they're presenting, without referencing their AI assistant.
Of course, there are questions I can't answer about my code or research. When does garbage collection happen in the Python code that runs my model? Interesting question. I have no idea; I've given up on that level of knowledge of my code. This point of policy handles this concern nicely, however—I don't have to be able to answer any question about the experiments I've run, just those that my (reasonable, cooperative) labmates are genuinely curious about. As a lab (and, starting with me,) we set the expectations for what kinds of details are critical to our research and what we expect each other to know. It takes time to understand what follow-up questions are; this is part of the process of learning in the lab. So, junior students are given time to figure out these conventions.
We say first follow-up because in the course of an in-depth conversation about an experiment, we may tackle increasingly nuanced questions that we might not have even thought about at first, in which case we may attend back to our code and the agents that helped us generate it.
Obey Grice's maxims of Quantity and Quality even when your agents don't.
In cooperative communication, Grice's maxim of Quantity states that a cooperative speaker modulates the amount of information given to what they believe the other speaker needs. (No extra information, and no missing details.) Current agents conspicuously don't do this. They focus on small details that the user pointed out (Ok, here's the Properly Weight Decayed Experiment — using weight decay properly is assumed in our conversation, unless it's been a topic of previous discussion.) They also omit critical aspects, like perhaps what the maximum thinking trace length was (an agent might set a “reasonable maximum” of 500 tokens, but we know for our purposes that we need thousands.) Models tend to over-explain, and this costs our collaborators time to go through the mush.
Grice's maxim of Quality roughly states that we try to say true things. When we only have partial oversight of what our agents have done, we are often in a position where we just don't know all details and so we just don't know exactly what's true of what our experiment has actually implemented. It's up to the lab member to not make statements that they don't have sufficient evidence for, by understanding core parts of their code.
For example, an agent might tell a lab member I found a bug in the implementation of multi-head latent attention having to do with RoPE. I fixed it. The results are as follows... In a world where the lab member found and fixed the bug, they would communicate the bug to me. "oh the bug ended up not being important, here's what happened...". This helps me triage how the bug should affect how I think about previous results. In a world where the agent discovered the bug and the student says the bug wasn't a big deal without truly knowing, I'm stuck. In such a case, it's the student's job to get more information about what the bug was and understand it.
See this Stanford Encyclopedia of Philosophy article for a discussion of Grice.
Be in charge of your technical terms.
Good technical writing provides nice intuitions that act as scaffolding for building the reader's understanding. This intuition-building has to be well-separated from statements that are meant to be precise. The introduction, definition, and consistent application of a few technical terms is one way in which strong papers distinguish between intuitions (residual connections are like a highway for the information to flow...) and precision (For a function $f(x): \mathbb{R}^{d} \to \mathbb{R}^{d}$, applying a residual connection to $f$ means constructing a function $g(x) = f(x) + x$). Another useful way to distinguish the two, of course, is the explicit use of phrases like Intuitively, to call out intuition-building. It's surprisingly difficult to set a small, clear number of technical terms in a paper and make sure they're always used consistently.
AI writing makes this much harder. Honestly, models come up with really compelling-seeming technical terms—and a lot of them—all throughout writing. AI agents discuss where the leverage is, the critical flow---it's hard to even come up on the spot with examples that match models' technical-seemingness. These are worse than nothing, since they seem technical, but are neither (1) baked into our thinking about the paper, nor usually (2) well-defined and thought out in the context of the argument we're trying to make. I expect students to decide on their technical terms, and remove technical-seeming language from models' suggestions or update them to use the agreed upon terms.
One useful intuition, from Aleks Hołyński, is as follows: if you can remember a time that you didn't know the definition of some term (e.g., every seemingly technical term Claude generates for you,) and you're deciding to still use the term, make sure to (1) know the definition, and (2) communicate that definition to your collaborators clearly.
Other Useful Resources
These are not part of our lab policy, but are useful resources when thinking about AI and communication with each other.
One is the Clay AI writing policy and another is Naomi Saphra's essay, Life on the Uncanny Precipice. Thanks to Judy Shen and Aleksander Hołyński for helpful discussions as I drafted this policy.
Artefacts in this first draft, like tikz diagrams etc., may be produced with the help of AI.
↩