Large language models (LLMs) and LLM-based tools like Claude Code are now a part of how we do research. Used well, they make us faster and free us to focus on the harder, more interesting parts of a project. Used carelessly, they introduce subtle errors into our code, fabricate references in our papers, and erode the trust readers place in our work.

This page describes how we use these tools in our team. The underlying principle is simple: you are responsible for everything you ship, regardless of how it was produced. An LLM is a tool, like a compiler or a plotting library. We don’t blame compilers for bugs, and we don’t blame LLMs for mistakes in our papers. When you join the group, I’ll ask you to read and sign the current version of this policy, and there will inevitably be situations that fall outside its scope. Let the examples below guide your judgement, and if you remain uncertain, ask me before you proceed.

This policy covers two modes of LLM use:

• Interactive use — chat-style LLMs and LLM-based coding assistants where you prompt, review the output, and decide what to do with it. This is how most of the team currently uses these tools, and most of this policy is about this mode.
• Agentic use — tools that take actions autonomously on your behalf, such as writing files, running commands, or querying resources without turn-by-turn approval. A smaller number of you are starting to use these, and they introduce additional considerations covered in the section below.

The policy is scoped to coding and writing, the two areas where LLM use is most common in the group today.

What we encourage

• Using LLMs as coding assistants. Claude Code is my current recommendation, but the landscape is moving fast so use what works well for you. Generating code to rapidly prototype ideas, produce complicated figures, and scaffold routine work are all good uses, but careful specification and verification are essential, and you must be able to read and stand behind any code you keep. Share what you’re learning on Slack (#programming is a good place) or in the team GitHub page (tutorials/ is a good place). If you find a better tool, a useful workflow, or a prompt pattern that saves time, post it. We all benefit.
• Using LLMs for writing support on your own text. Rephrasing, tightening a paragraph, improving clarity or grammar, translating between registers, and brainstorming outlines are all reasonable uses, as is polishing or translating text you wrote and understand. Generating substantial new passages is a different matter; see What requires care below.
• Low-stakes, easily verifiable cleanup. Spotting typos, inconsistencies, or places where a text doesn’t follow a given specification. These tasks are time-consuming but cheap to check, which makes them a good way to use a model to prioritize where to direct your own attention. In a time-crunch, this can be a reasonable way to do a rough clean-up of a thesis or paper draft.
• Using an LLM as a tutor. Getting an initial explanation of an unfamiliar concept, method, or piece of terminology. Verify what it tells you against primary sources before relying on it, and treat its explanations as a starting point, not an authority. Be aware of visibility bias: models may not know what matters in niche topics and can point you toward high-visibility but less important/accurate directions by chance.
• Refining preliminary research ideas. Developing and sharpening early ideas through repeated interaction with a model can help. Be deliberate about it: it is not a substitute for critical thought, the worst case is an unproductive rabbit hole, and it works well only when you already have a solid grasp of the problem and the surrounding concepts.
• Maintaining your CLAUDE.md (or equivalent) diligently. LLM-based coding tools compact their context as conversations grow. When the context is compacted, anything not captured in persistent files like CLAUDE.md is effectively lost, and you’ll find yourself re-explaining the same project details every session. Build up your CLAUDE.md as you go. Write skills (see Anthropic’s skill-creator docs) when you find yourself giving the same instructions repeatedly. Time invested here pays back many times over.
• Transparency. Be open about where and how you’re using LLMs: with me, with collaborators, and in your written work where relevant (see below).

What requires care

• Let the tool edit a few things at a time. Small, reviewable diffs are much easier to check than sweeping changes. If you can’t meaningfully review the edit, you can’t meaningfully take responsibility for it.
• Be cautious with design decisions. LLMs are often confidently wrong about architectural choices, algorithm selection, and tradeoffs specific to our domain. Treat LLM suggestions on design as input to your own thinking, not as answers. For any non-trivial design decision, come to me or a colleague before committing.
• Don’t lean on a model’s summary of a paper you haven’t read. Summaries drop nuance, miss caveats, and occasionally invent claims. Use them to decide what to read, not as a replacement for reading.
• Treat any references a model suggests as leads, not sources. Asking a model to point you toward related work is only acceptable if you independently confirm that each source exists and actually supports the claim you attach it to. This slips very easily into fabrication (see What is not negotiable).
• Be wary of drafting substantial passages. Generating substantial passages of a paper, proposal, or thesis is permitted in principle but discouraged unless the output is heavily revised, fully understood, owned by you, and disclosed where required. The risk is not only error but the slow erosion of your own voice and reasoning. If you find yourself relying on this regularly, that’s a signal to stop and talk to me.
• Don’t use a model where checking its work costs as much as the work. If verifying the output is as time-consuming as doing the task yourself, you’ve gained nothing and added risk. Keep in mind that LLMs have substantial environmental and societal impact, so don’t use an LLM for a task “just because” as these tools are not without cost and consequences.
• Log what matters for reproducibility. If LLM output is a meaningful part of a result (e.g., a prompt that generated training data, a model call embedded in a pipeline), record the prompt, model name, and version in the same way we record random seeds. Future-you (and possible reviewers) will thank you.
• Be careful about what you put into a model; confidential data stays out of hosted LLMs. With most consumer tools your inputs leave your control and may be retained or used to train future systems, and some mistakes here cannot be undone. Do not paste into a third-party LLM: proprietary or unreleased data/files that you did not create; this includes but is not limited to data from industry collaborators (e.g., AstraZeneca), unpublished manuscripts or results from other groups, peer-review materials, student work you’re grading, or anything marked confidential. Do not upload personal data or human-subjects data; under GDPR this is a legal matter, not merely a courtesy, and consumer LLM services are generally not an appropriate place for it. Do not enter credentials, API keys, or anything covered by an NDA or data-use agreement (this applies in particular to industrial PhDs and postdocs). When in doubt, assume that anything you type into a model may become public, and act accordingly.
• Not all services are equal. Enterprise or “zero-retention” offerings that contractually do not train on your inputs are very different from free consumer accounts that may. Factor this into what you are willing to share with a given tool.
• Peer-review materials are off-limits. Most major venues (NeurIPS, ICML, ICLR, Nature, Science, and increasingly others) now explicitly prohibit pasting manuscripts under review into LLMs. Check the venue’s policy before you review, and default to “don’t” if unsure.

If you use agents

A subset of the group uses agent-based tools — systems that take multi-step actions (writing files, running commands, submitting jobs) with limited per-step human approval. This is a powerful mode of working, and worth learning. The flip side is that autonomy requires more upfront care in how you set things up, because by the time you notice something has gone wrong, the action has often already happened. If you use agents, these practices apply on top of everything above.

• Start in approval mode, earn autonomy. Most agent tools (including Claude Code) let you approve each action individually or run fully autonomously. Default to per-action approval. Move to more autonomous modes only after you’ve built trust through a short cycle of runs you’ve reviewed very carefully and diligently.
• Sandbox first. Don’t point a new agent workflow at shared compute, the group GitHub organization, or real data until you’ve validated it on a scratch directory, a fork, a test dataset, or a separate environment. This is basic hygiene and good practice.
• Set explicit budgets. Agents should have caps on iterations, tokens, and run time.
• No autonomous actions on shared infrastructure without a dry run. Shared compute quotas, shared storage, the group GitHub org, anything deployed — the default is that agents propose, you review, you run. Promote a workflow from “proposes” to “runs autonomously” only once you’ve seen it behave correctly repeatedly and the consequences of mistakes are bounded.
• Mind credentials. Don’t give agents access to broad credentials (long-lived API keys, Chalmers login, cluster SSH keys, full-scope GitHub tokens). Use task-scoped, revocable credentials where possible.
• Capture what the agent actually did. If an agent runs experiments or produces code that feeds into a result, the log needs to capture the agent’s actions, not just its summary of them. “The agent says it trained the model” is not the same as “here is the training log.”
• Agents are still bound by every rule above. No peer-review materials. No confidential data. References must be verified by hand (see below). Accountability is still yours.

What is not negotiable

These are the firm rules. Please read them carefully.

• Verify every reference yourself. LLMs hallucinate citations constantly — author names, titles, journal, year, DOI, even BibTeX entries that look perfectly formatted can be fabricated. Providing the LLM with a URL does not fix this. There is already an epidemic of fake references in the scientific literature, and we are not going to contribute to it. For any manuscript from this group, references must be verified by hand — confirm the paper exists, confirm the authors and title match, confirm the DOI resolves to the right work, confirm the quoted claim is actually in the cited paper. This is one of the few parts of writing where LLM assistance is not permitted, full stop. This extends to bibliography management: do not use a model to generate, format, or modify reference lists or .bib files. The risk of subtle, hard-to-spot errors is high, and proper verification costs as much as doing it by hand.
• You are accountable for everything you ship. If LLM-generated code introduces a bug into our codebase, that bug is yours. If LLM-generated text ends up in a paper with an error, that error is yours. If an agent acting on your behalf deletes the wrong files or pushes broken code, those actions are yours. “The LLM made a mistake” is not an explanation we accept, because the LLM is not a member of the group, you are. If you delegate a decision to a model, you own the outcome; “the AI thought it was ok” is no more of a defense than “the AI made a mistake.” Proofread everything. Run the code. Verify the claim.
• Follow the venue’s disclosure rules. Many journals and conferences now require authors to declare LLM use. Check the specific venue’s policy before submission and comply with it. When in doubt, disclose and be transparent.
• A model cannot be an author. Authorship carries accountability that a tool cannot hold; this is the standard position across major publishers. The corollary is that you are accountable for everything that appears under your name.
• Flag substantial AI involvement internally, too. When you circulate a draft that involved substantial AI assistance, say so, so the rest of us can read it with that in mind.
• Clear anything unusual with me first. If you’re considering a novel use of these tools that this policy doesn’t cover, talk to me before you start. Not because I’ll necessarily say no, but because these decisions may have implications beyond your own project.
• No fabrication, ever. Any use where a mistake is or could reasonably be interpreted as research misconduct is never acceptable. This includes fabricating facts, data, results, references, or quotations. There is no version of this that is acceptable.
• Don’t outsource turning vague ideas into precise ones. Do not generate lengthy text or notes from half-formed ideas and send them to others for review. This wastes their time, misrepresents your thinking, and outsources exactly the skill you are here to develop.

On mistakes and reputation

Everyone makes mistakes, LLM-assisted or not. The issue is not that mistakes happen; it’s whether we catch them before they reach readers, reviewers, and collaborators. If you find yourself repeatedly shipping errors that a careful proofread would have caught, that’s a pattern we need to discuss. Your reputation as a careful scientist is one of the most valuable things you build during your time in the group. Do not put this reputation at risk by being sloppy with your use of AI tools.

Other context worth considering

The sections above are the policy. What follows is context — some general reasoning and things worth keeping in mind even though they are hard to write as firm rules. Much of this comes back to a single concern: some kinds of use can quietly interfere with your path towards becoming an independent researcher, which is the reason you are here.

• Reliability. Treat every factual claim, citation, number, and snippet of code a model produces as unverified until you have checked it. These systems are fluent and confident regardless of whether they are correct, and they will produce plausible-looking nonsense with no signal that they are doing so. Fluency is not accuracy. This caveat sits underneath every encouraged use above.
• Costs. We are currently in a heavily subsidised regime: access to frontier models is cheap or free, and it is widely suspected that providers are not charging the full cost of running them. Plan around the risk that this may not last. Prices could rise, or the free and cheap tiers could become significantly less capable. Don’t build a way of working that collapses if that happens, and make sure your core competence does not depend on continuous access to any particular model.
• Environmental footprint. Running these models consumes meaningful energy and water. This is a legitimate reason to prefer the smallest tool that does the job rather than reaching for the largest by default.
• Skill and dependency. This is one of the key concerns behind much of the policy, and the one most educators care most about. The danger doesn’t stem from any single use. Rather, it is the cumulative habit of outsourcing the critical thinking that a PhD exists to build. Reading hard papers, getting stuck, writing your way to clarity, and developing taste in what is and isn’t a good idea are uncomfortable and slow, and they are precisely the things that make you an independent researcher. A model can do a passable version of each, which makes it tempting to let it. Be honest with yourself about when you are using these tools to work faster and when you are using them to avoid learning something. The first is good; the second has a cost you will not see until much later.

A final note

Like everything in our group guide, this is a living document and will evolve as the tools and norms around them change.

Last updated: July 26, 2026.