-
Notifications
You must be signed in to change notification settings - Fork 2
Kreed Lab AI Guidelines
Kreed Lab AI Guidelines. Updated August 2026.
This is not a “don’t use AI” document. It is a guide for using AI well. This means using AI in ways that will make your science faster, clearer, and more robust. We also devote attention to avoiding pitfalls with AI, mostly concerning when AI introduces errors or impedes learning - these can make your science slower and less clear, and leave you unprepared to tackle similar tasks in the future. This is the opposite of what you want to accomplish!
Never upload protected, confidential, or restricted material unless the AI tool you are using is explicitly approved for that use. This may include human-subject data, confidential grants, manuscripts under review, unpublished collaborator data, and material governed by data-use agreements. Each lab member is responsible for understanding the restrictions attached to the information they handle.
AI is most useful when you can “close the circle” by checking its output against your expertise, observable behavior, primary sources, or an independent analysis. If you cannot evaluate whether an answer is correct, you cannot evaluate if it is incorrect. Good uses that can usually be easily verified include:
- Editing text you wrote for grammar, clarity, organization, or redundancy. Did the meaning change?
- Finding typos, missing protocol steps, or mismatched figure callouts. Is it correct?
- Debugging code or generating small functions you understand and can test.
- Building python notebook elements like click-downs where failures are readily observable.
Some lab members pointed out that AI can be useful even without immediate verification. This may include the following types of interactions:
- Brainstorming ideas or previewing an analysis, provided the result is later rebuilt and validated.
- Acting as a tutor for unfamiliar concepts, with important claims checked elsewhere.
In short, always review AI output before using or sharing it. You are accountable for any outputs you pass on to others.
Before using AI, ask what you are trying to accomplish. If your goal is to learn a skill, first make a serious attempt yourself and use the AI as a tutor when you get stuck. Paying someone else to work out at the gym won’t make you stronger, and outsourcing your learning to AI won’t develop your own skills. Struggle, feedback, and practice are part of learning - embrace the struggle :)
Consider asking a (human) colleague for help before using AI. Conversations with other scientists build relationships and provide perspectives that an AI system may not. Working only with AI is like working only with yourself or with one other colleague - you may be isolating yourself and missing out on ideas you don’t even know you’re missing out on. This is especially true if you have colleagues who are experts in what you are trying to do - AI will usually provide generic advice, while an expert can often provide more nuance, historical perspective, or warn you about pitfalls that AI might not know of.
Disclose AI use to collaborators, lab members, etc, whenever you used AI to materially contribute to code, analysis, or writing. Just as you wouldn't pass off a colleague's writing as your own work, don't hide it if you used AI for your own writing. Follow applicable institutional, journal, and funder policies on AI use and transparency. For code, comments might say:
- “Generated in part with ChatGPT/Claude; manually reviewed by ____.”
- “AI-assisted draft; analysis logic and outputs manually checked.”
Literature. AI can help locate possible papers, check a reference list, or suggest starting points for learning more about a topic. AI summaries are not a substitute for reading! Seriously, we can’t stress that enough. AI can invent citations, provide broken links, and misrepresent the conclusions of papers. Just like you wouldn’t form your opinion based solely on asking one other person, don’t assume that AI has the definitive interpretation of a paper. For instance, many AI systems only have access to abstracts and not full text of papers, and may not reveal that they relied on the claims in abstracts to support the (confident sounding) conclusions. It is critical to open every cited paper and read enough of the primary source and figures to determine if it supports the specific claim being made. Even without hallucinations and other major issues, abstracts can sometimes over-sell the data in a paper, so if the AI system can’t access the full text it has no way to assess this.
Finding one supporting reference also does not establish that a statement accurately represents the field. Watch for confirmation bias, if you ask AI a leading question like “find me a reference that supports ____” it will find one, that does not mean that this is an accurate portrayal of the field.
Scientific writing. AI is often more useful as an editor or critic than as a writer. Many people have concluded something to the effect of “writing is thinking”. If you want to develop your skills as a critical scientific thinker you have to develop as a writer. Writing is also a way to express yourself and become the type of scientist you want to be.
Never use AI to draft before you know what you want to say - it will usually blur your ideas into generic sentences. High quality science writing has a high information content per word (think about Nature articles with strict word counts). AI can perform very poorly on this metric and quickly generate a lot of words with little information. This is even more true for personal statements, reference letters etc where being generic is not good enough.
Coding and data analysis. You are accountable for AI-assisted code and results that the code produces. Use tests, known outputs, manual checks, and human review when appropriate. For full pipelines, proceed slowly enough to understand each step. Work to make your code accessible and ask others to try it out - this is a sure-fire way to find bugs that won’t surface if you keep running the same data through.
Do not use AI to re-write functions that already exist in the lab. This fragments our codebase and introduces the potential for errors.
Take particular care with data cleaning, statistical analysis, plots, and summary values. Know that errors in these areas may look plausible - if you mean to index 60 lines of data and you get 59 you may not immediately realize the error from the result. Use checks such as returning the shape of dfs and confirming they match your expectations.
Again - you are accountable. Do not present a result until you understand how it was produced and have adequate evidence that it is correct. There is nothing that kills confidence quicker than a scientist who changes their conclusion each time they present something. This is even more true when presenting outside the lab.
This document was developed following discussions and notes from Kreed lab members, compiled and edited by the PIs with assistance of AI from Edison Scientific. Source material for the guidelines is the Kreed lab members notes below:
Part 0: When should you use AI?
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| Eric | What level of competency should you have before using AI? |
| When you can “close the circle” - when you have some way to evaluate the output you receive from AI - trust but verify | |
| If you want a proof of concept or sneak peak of the end result, while remaining realistic if you don’t really know what you did. |
Part 1. When should you NOT use AI?
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| CRITICAL - Do not upload any protected data to an LLM! This is everyone’s responsibility to understand, if you accept confidential data you need to understand the terms. This includes most human data, confidential documents like grants, papers in review, etc. You have the right to share your own writing (like your manuscript draft) with an LLM | |
| Travis | It’s brave new world and society will soon learn the consequences we can’t possibly predict. So be specific with instructions. |
| Think about if you want AI companies profiting from public resources like government funded data. If you give it data files, they will train on it (probably even if you click options to turn this off). | |
| Not Meaghan but I wish it had been | Be mindful of your own learning goals, and whether AI is inhibiting your development. For instance, if you’d like to be good at formatting plots on your own, are you progressing at this? |
| Not Meaghan but I wish it had been | Be mindful of your scientific identity and how you are developing it, and whether AI is inhibiting this. |
| If you haven’t tried to solve the problem on your own, or with human input - this gets into learning, trying something on your own is critical to the learning process. | |
| Travis | Ask people who’ve had good outcomes how they’ve got those good outcomes. |
| Bobby/Travis | The longer the chat - the crappier it gets. Let CLaude rest. But it’s the context window; it’s not a robotic software engineer. Everytime you give it a new question, it reads through all prior comments during that session. Context window = how much it can digest at once. At some point it’ll do ‘compaction’ to open space…. Then it gets forgetful and frustrating. Claude indicates it’s getting full. This is why long detailed initial prompts are helpful. There’s a U-shaped curve in the weight the model puts on the output; the early input and most recent output will carry the most weight. Stuff in the middle can get lost, so if you’re making key decisions mid-session; reset. |
| Bobby | Be very specific; the more instructions and steps you can give it the better. Helps you focus, helps debugging later, breaks into manageable verifiable chunks. |
| Bobby | Use but verify/don’t trust. Great for speeding up syntax elements; just like you wouldn’t trust code from a random person, you’d also want to verify. |
Part 2: Literature searching
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| Travis | This is the category I find least helpful (and often frustrating). Links to references are often wrong/broken. Feels easy to get caught in loops. |
| Lex | Sort of the opposite of Travis’ point, I find asking AI to check a reference list for accuracy/relevance can be helpful. It might miss some incorrect refs, but a true hit (ie: a reference it says is incorrect) is a valid signal, and one that is pretty easy to check. I found a mis-reference in Alex’s preprint this way, we had the right first author, wrong paper cited. |
| Lex | I do find it helpful to ask “what is a good reference for this sentence: ______________”. Of course you have to open/read the suggested reference, but in this way I think it’s similar to typing key words into pubmed when you’re looking for info on “obesity and dopamine”, etc. There are risks here that it tends to choose common references, but if that’s what you want it can be helpful. Eric: This risks confirmation bias! You can find a reference for any statement - it doesn’t mean this is the accurate state of the field? (+1 Meaghan) |
| Lex | I also find some specialized tools like Elicit.com or Edison Scientific much better for literature searching than ChatGPT or Claude - they will return the references at least so you can check, which is critical! |
| Eric | It can be good to find a reference you remember reading but don’t recall the authors or title. Claude Science is good at this. |
| Eric | Claude science can be good for summaries/literature reviews. |
| Meaghan | I used Elicit to try and learn about cortex a while back - it kept claiming something specific about cortical connectivity, I asked Travis if it was true. “Not really, it’s probably picking up this highly cited and refuted paper [provides reference]”. In other words, AI can be good for getting a survey or place to start (it’s still subject to reputational/citation bias), but I don’t think there’s a short cut to having a grasp on trends in a field. |
| Bobby | Hallucinated references getting better, but asking for key or seminal papers on topic X can give you a good starting point. |
Part 3: Scientific writing
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| Travis | I find it help to prompt something like: “you are a scientific editor, suggest changes to this block of text to improve grammar, clarity, and length”. Or “here’s a protocol I’ve written. Identify places where steps may be missing and format the document to look nicer.” “Here’s my CV, switch dates from chronological to reverse chronological’. Limited experience turning an outline into text or asking for a first draft. |
| Lex | I find proofreading really helpful - “Please proofread this document, checking that all figure callouts are correct”. |
| Lex | I find “Review this like a journal reviewer” helpful, even as a way to get my own brain going. Again, I think the commonality on why this is helpful is that the risk is low (you’re not asking it to modify your text), and you can then use your expertise to evaluate if the output makes sense to you or not. |
| Copy editing it good - can you find repetitive text, typos, etc | |
| Meaghan | It definitely has its place. To the extent that: “writing is thinking”, I advise holding off and grappling with what you’re trying to say as much as possible before asking an AI to do any interpolation. Giving it clear instructions: “i.e. edit this sentence to not include the word x, (or ‘flag instances of redundancy’), I’m two lines over, please shorten this paragraph (like Eric suggested) can be really helpful. When your first stop is generative AI before you put pen to paper in any context, then it’s probably too much generative AI. |
| Meaghan | As someone who reads tonnes of writing constantly (papers, grants, statements, essays, QEs), many of your audiences are just like me, and read until our eyes bleed (admissions committees, reviewers etc). By pattern matching, AI writes really ‘well’ but also in a super predictable style, and leans more towards generalities (it’s just pattern matching after all). Whether you realize it or not, the audience on the other side has a hard time remembering you or figuring out what’s special about you or what you’re trying to say, it just melts into the other 13 similar things they’ve read that day.There was a time when type-os in a rec letter were a sign of sloppiness, now it’s a signal the writer cared enough to actually write it, not to feed the person’s CV into an LLM. The ‘envelope signal’ has flipped. Reading a few clumsily worded sentences in a fellowship app is refreshing and memorable. |
| Bobby | LIke coding; don’t blindly trust. |
| Bobby + Radostina | Very good at explaining concepts to you! Explain math concepts, for example. Great tutor: I.e. “What is a UMAP?” “Re-explain something [non-linear dynamics] like I’m five years old”. Can really help building intuition for understanding. Concepts that have objective truth in the real world that can be explained (i.e. physics). |
Part 4: Coding and data analysis
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| Travis | I am starting to dabble more with agentic coding, but still sometimes find it useful to go the “slow” way and ask for specific lines of code I might plug into a notebook myself. Using “plan” mode in Claude, keeping an eye on context window, and being thoughtful of the scope of what I pursue in a single session are pieces of advice that have felt immediately useful to me. Applying skills and config markdowns are things I’ve been told to try, but have a little more barrier to entry. |
| Lex | I agree with Travis on the “slow” copy/pasting code building vs. full agent. I find I can waste more time when I don’t understand the code and can’t modify it (and asking the AI to modify it sends me in circles). Doing the plan and then copy pasting as you build feels more solid when I’m done. |
| Lex | I find it INCREDIBLE at building colab/jupyter widgets - dropdowns, radio buttons, semi-GUI features in a notebook. I never learned how to do that stuff and AI can do it really well. Our Psygene notebooks have some slick examples that I think make them much more useable for others. Again, this stuff has built-in checks. If a button or dropdown doesn’t work you know it because it doesn’t work. (As opposed to if the graph is showing the wrong value for the mean it’s not immediately apparent). |
| Lex | I think the most important line in those articles we read was “You are accountable”. AI can write code so quickly it’s hard to check everything well enough to feel like we can be accountable, but it’s critical we do check. The errors are ours, even (or especially?) if AI wrote them. This doesn’t necessarily mean reading line by line and searching for bugs - software tests, sample data, etc, can be better than that. But probably don’t ask an AI to write a test for some code it just wrote :) |
| Will | It’s great for debugging. |
Part 5: Transparency
| Name (optional) | Comment on what’s working well, not well, etc |
|---|---|
| Will | You should be transparent about when you use it - tag code with “This was generated in part by Claude”. Publishing code may require documenting strategy, approach, etc. |
| Eric | You can note if the code was manually reviewed or not |
| Meaghan | I agree that now the expectation is that your analysis code will be published alongside your raw data; transparency in where/how AI was used is particularly important for scientific integrity here. I’ve seen more reviews go out with comments to the effect of “language was edited by an AI”. |
- Software Setup
- NRB Printer Setup
- Poster Printing
- Poster Templates and Examples
- Travel Guidelines
- AI Guidelines
- Cage Cards
- Red Hazard Cards
- Surgery Cards
- Mouse Transfer Procedure
- Cage Check
- IACUC Protocols
- Mouse Genotyping
- Autoclave
- Localizing Injections with DiI
- GCaMP8
- ChR2 (H134R)
- GrabDA
- dLight
- Caspase
- mCherry/YFP Controls
- retroCre
- RNA Extraction with TRIzol
- cDNA Synthesis with Bio-Rad Reagents
- Designing Primers and Primer Mixes
- qPCR Setup and Analysis
- Biotinylation
- Western Blot
- Antibody Stocks
- Cryostat
- Freezing Microtome
- SST and PV Immunostaining
- GFP Immunostaining
- Immunofluorescence and Immunohistochemistry Troubleshooting
- Electrode Array Construction
- Attaching Fibers to Inn NeuroPhys Arrays
- NanoZ Impedance Testing
- NanoZ Gold Plating
- Recording Setup
- Electrode Lesions for Histology
- Overview
- Current Clamp
- Voltage Clamp
- Clampex Protocols
- Solutions and Recipes
- Troubleshooting
- Post-Patching IHC
- PPR Analysis with ClampFit
- Bonsai Installation
- Overhead Tracking
- Real-Time Place Preference
- Triggered Delayed Videos
- CSV Headers
- FED3 Overview
- FED3 Troubleshooting
- FED3 Human Bandit Code
- Synchronizing FED3 with Recordings
- FED3 Bandit Code for Recordings
- FED3 Artwork
- FED3 Analyses