Most guides to using generative AI in research are organised by tool. That is the wrong axis. Tools change every few months, their capabilities overlap heavily, and a list of them tells you nothing about the decision that actually matters — whether a given task is one you can safely delegate.
This guide is organised by task instead, and around one principle that applies unevenly across them.
The competence trap
Here is the awkward property of these tools, and the reason a guide for novices has to differ from a guide for experienced researchers.
This inverts the intuitive assumption. It feels as though a beginner has the most to gain, because there is more they do not know. In fact a beginner carries the most risk, because the verification step that makes the tool safe is precisely the step that requires the expertise they are building.
That does not mean novices should avoid these tools. It means the safe uses are the ones where you can check the output against something other than your own judgement — a source, a dataset, a test that either passes or fails, a supervisor. Every recommendation below follows from that.
Task by task
Finding literature — orientation only
Useful for: getting oriented in an unfamiliar area. Asking what the major theoretical positions are, what a term means, which debates are live, what a field's standard methods look like. This gives you vocabulary, and vocabulary is what you need to search properly.
Not safe for: producing your actual reference list. Ask a model for sources and it will produce plausible authors, plausible titles, plausible journals, plausible years, sometimes a well-formed DOI resolving to nothing or to something unrelated. These are not detectable by inspection, because they are constructed to look exactly like real references.
What to do instead: use the model to generate search terms, then take those to Scopus, Web of Science, ERIC, PubMed, or Google Scholar. Some tools now search real indexes and return live links — those are a different proposition, and the rule becomes simply that you open and read what they return rather than citing from the summary.
Never cite anything you have not opened. This is the single habit that prevents the most damaging failure mode available to you.
Reading and understanding — genuinely strong
This is where the value is highest and the risk lowest for a new researcher, and it is underused.
- Paste a dense paragraph and ask for it in plainer language.
- Ask what a statistical procedure does and what its assumptions are, then check against a textbook.
- Ask for the difference between two concepts you keep confusing.
- Ask what question a paper was trying to answer, then read the paper and see whether you agree.
The risk is low here because you have the source in front of you. The explanation is checkable against the thing being explained. This is the shape of a safe use, and it is worth internalising as a pattern: the model is interpreting a document you can consult, not asserting a fact you cannot.
Where it still goes wrong: models over-smooth. Genuine disagreement in a literature gets rendered as settled consensus, and hedged findings get reported as established. If an explanation sounds tidier than the field feels, it probably is.
Developing a research question — with a supervisor in the loop
Useful for: pressure-testing. Ask what assumptions a question makes, what would have to be true for it to be answerable, what a critical reviewer would object to, what designs could address it. Used adversarially — argue against this framing — models are a cheap source of the objections you will eventually face for real.
Weak for: telling you what is worth studying. A model has no view on what your field currently needs, what your supervisor's group is positioned to do, or what data you can realistically obtain. Questions it proposes tend toward the plausible and generic, which is precisely the profile of a question that will not survive a proposal defence.
Methods and analysis — verify, always
Code is one of the strongest uses, with a hard condition. Generated R, Python, or SPSS syntax is often correct, frequently faster than writing it yourself, and always requires verification. Run it on data where you know the answer. Check that n is what you expect after every filtering step. Confirm the test matches your design.
The dangerous failure is not code that crashes — you will notice that. It is code that runs cleanly and computes the wrong thing: the wrong variable, listwise deletion you did not intend, a default that does not match your assumptions.
Choosing a statistical approach: acceptable as a starting point, then confirm with a methods text or a statistician. Models will suggest defensible-sounding tests that are wrong for your data structure — clustered data treated as independent is a recurring example.
Qualitative coding: handle with care. Useful for a first pass over a large corpus, or as a second opinion against codes you developed yourself. Not a substitute for immersion in your data, which is where qualitative insight actually comes from. If you use it, document exactly what it did and what you retained or rejected — see declaring AI use in a methods section.
Writing — real help, with a caveat about skill
Clearly legitimate: grammar and clarity editing, particularly if you write in English as an additional language, where the cost of language editing is a genuine inequity these tools partly offset. Also: tightening an overlong paragraph, suggesting structure for a section, generating a first draft of a plain-language summary, drafting response-to-reviewer wording.
Do not delegate: the interpretation. The discussion section is where you say what your findings mean, and it is the part of a paper that is genuinely yours. A model can produce a competent-sounding discussion of results it does not understand, and reviewers in your field will often be able to tell.
There is also a longer-term cost worth stating plainly. Academic writing is not transcription of finished thoughts — it is how the thinking gets done. Drafting is where you discover that an argument does not hold, that two findings conflict, that you cannot actually justify a claim. Outsourcing the drafting outsources the discovery, and what you lose is not the text but the reasoning that produced it. Early in a career, that reasoning is the thing you are supposed to be acquiring.
The practical compromise most experienced users settle on: write the bad first draft yourself, then use the tool to improve it. You keep the thinking; you save the polishing.
Peer review — no
Do not put a manuscript you are reviewing into a general-purpose AI tool. It breaches the confidentiality you accepted when you agreed to review, regardless of what the tool does with the text. Many publishers now prohibit this explicitly. If you are asked to review and feel unqualified, decline and say why — that is a normal and respected thing to do.
The verification habit
Everything above reduces to one workflow. Before any model output enters your work:
- Every citation: open it. Confirm it exists, and confirm it says what you are claiming it says. Both checks — a real paper attached to a claim it does not support is the more common error.
- Every factual claim: trace it to a source you have read.
- Every piece of code: test it against a case where you know the answer.
- Every statistical choice: confirm against a methods reference or a person.
- Every interpretation: make sure it is yours, and that you could defend it in a viva without notes.
If a step is one you cannot perform, that is not a reason to skip it. It is the signal that you should not be using the tool for that task yet.
Declaring what you used
Journals increasingly require disclosure, and your institution may have its own rules for theses and coursework that are stricter. The short version: language editing generally goes in the acknowledgements, anything touching the evidence goes in the methods, and no AI system is ever an author. Concrete wording for the common cases is in declaring AI use in a methods section.
Keep a running note of what you used and where, while you are working. Reconstructing it eleven months later, at proof stage, is unpleasant and inaccurate.
What to build yourself anyway
Some capacities cannot be delegated without losing the point of having them, and it is worth naming them explicitly because the delegation is so frictionless:
- Reading a paper critically. Judging whether a design supports its conclusion is the central skill of research training, and there is no shortcut that leaves you able to do it.
- Knowing your own literature. Not summaries of it — the actual arguments, and who disagrees with whom about what.
- Sitting with your data. Particularly in qualitative work, insight comes from prolonged contact with the material.
- Writing your own argument. For the reason given above: it is how you find out whether you have one.
- Judging quality. The thing a model cannot do at all, and the thing your career will ultimately rest on.
A reasonable starting position
If you are beginning, this is a defensible default:
- Use freely for explaining things you are reading, drafting code you will test, and editing prose you have written.
- Use with verification for search terms, method suggestions, and critique of your own framing.
- Do not use for generating citations, writing your interpretation, or anything connected to peer review.
- Always open every source, test every script, and keep a record of what you used.
None of this is unique to generative AI. It is the ordinary requirement that you understand and can defend everything appearing under your name. The technology has made that requirement easier to neglect, and no less binding.
Related: writing for international journals covers the drafting conventions these tools are often used to help with, and what SJR actually measures covers reading the journal metrics you will meet when you decide where to submit.