Chapter 27 Using AI chatbots for help with R

27.1 Introduction

This chapter goes with the AI workshop. Instead of a lecture, the workshop has some discussion and plenty of hands-on use of AI chatbots (also called AI assistants), such as Microsoft Copilot Chat, ChatGPT, Claude or Gemini, to help with R programming and statistics.

You can use whichever tool you prefer or have access to, and it is a good idea to compare more than one. You never need a paid subscription: as an SDU student you have free access to Microsoft Copilot Chat by logging in with your SDU account. If you would rather not use AI tools at all, that is fine: you can do the activities by working with a neighbour, and you will still learn how to check AI output, which is a useful skill in itself.

The chapter covers:

  • What AI chatbots are and how they work
  • The rules for using AI in BB852
  • Ways AI can help with R
  • When AI gets it wrong, and how to check its output
  • Tips for good prompts
  • How to declare your use of AI

27.2 How AI chatbots work

AI chatbots are built on large language models (LLMs). An LLM is a machine learning model trained on enormous amounts of text (books, websites, computer code and so on) to do one thing: predict a likely next word, again and again. Because the training text includes a great deal of R code and statistics, this simple trick produces answers that are often very useful. But the model is producing plausible text, not checking facts, so a fluent, confident answer is not necessarily a correct one.

Many current tools can also search the web or run code. This helps, but it does not remove the need to check the output yourself.

27.3 Using AI in BB852: the rules

This section is the official statement of the BB852 rules on generative AI. The slides, the assignment brief and itslearning all point here rather than repeating the rules.

BB852 follows SDU’s common rules for generative AI, with no course-specific exception. SDU’s own page, The use of artificial intelligence at SDU, is the authority: if SDU changes its rules, the new rules apply, even before this book is updated. At the time of writing (November 2026), they mean:

  • Allowed: you may use AI tools in the practicals and in the written assignment.
  • Not allowed: AI tools may not be used in any supervised written or oral exam. In BB852 this means the multiple-choice exam.
  • You are responsible for everything you submit. AI tools often produce code that runs but fits the wrong model, invent functions or arguments, and describe results with more confidence than the data support. You must be able to explain every line of code, every modelling choice and every number in your assignment. Check AI output against the course book and the lectures.
  • Declare your use by attaching the Faculty of Science declaration form (see Declaring your use of AI below). Summarise what you did; do not paste prompts or chat logs. Declaring use does not lower your mark, but SDU treats missing or incomplete declaration as plagiarism.
  • Protect data. AI tools are not necessarily GDPR compliant, so never put personal, sensitive or confidential information into a prompt. The course data sets are fine to use.

If you are unsure whether a use is acceptable, ask before you submit.

27.4 Ways AI can help with R

  • Finding errors (debugging)
  • Explaining code
  • Interpreting output (e.g. what does this model summary mean?)
  • Choosing a model (e.g. I have this design, how should I analyse it?)
  • Improving code and adding comments
  • Translating code from another language

The activities below use code and data from the course, so you can check the answers against what you already know. In each case, the point is not just to get an answer but to judge whether the answer is right.

27.4.1 Finding errors

It can be frustrating to deal with error messages in R. Give the tool the code and the error message, and ask it to help.

This R code gives an error. Help me fix it.

fox <- read.csv("CourseData/fox.csv")
mod1 <- glm(noffspring ~ weight, data = fox family = poisson)

Run the fixed code in R. Did the tool explain why the code failed, or just give you a corrected version? (Follow-up: ask it what family = poisson means.)

27.4.2 Explaining code

You can ask for help understanding what code does. Telling the tool your level helps it pitch the explanation.

Explain this line to a beginner in R and statistics:

foam_mod <- lm(foamIndx ~ method, data = espresso)

Check the explanation against the ANOVA chapter. Is anything wrong or missing? A good explanation should mention that method is a factor, that lm() here fits the same model as a one-way ANOVA, and that the intercept is the mean of the reference method.

27.4.3 Interpreting output

Fit the model above (the data are in espresso.csv), run summary(foam_mod), and paste the output into the tool:

Explain this output. Then write a results sentence for a scientific report.

[paste your summary(foam_mod) output here]

Does the tool read the output the way you would? Do the numbers in its sentence match the output? Many tools write test-led sentences (“there was a significant difference, p < 0.001”). Compare its sentence with the Examples of statistics reporting: does it report the estimated differences with 95% confidence intervals?

27.4.4 Choosing a model

You can describe your study design and ask for help with modelling choices.

I counted bumblebee visits to 40 flower patches, half mown and half
unmown. Which model should I fit in R?

Before you ask, decide which model you would choose and write it down. Does the tool agree? (From the course, a natural choice is a Poisson GLM, glm(visits ~ treatment, family = poisson), followed by a check for overdispersion.) Tools often suggest a t-test, a log transformation of the counts, or jump straight to a more complex model. A good tool will also ask for information it needs: were the patches the same size, and were they watched for the same length of time?

Advice on modelling is where AI tools are most error-prone, so ask follow-up questions until you understand why it recommends an approach. Treat it as a sparring partner, not an oracle.

27.4.5 Improving code and adding comments

Sometimes you will have written a long script without commenting it, which makes life hard for “future you” and for collaborators. You can ask an AI tool to add or improve the comments, or to suggest a simpler way to do the same thing. Try it on a script you have written during the course, then check that the code still runs and gives the same results.

27.4.6 Translating code

You may find code in another language, such as Python, that you want to use in R. AI tools are usually good at translation, but they can also copy the original’s mistakes. Try this:

Translate the following Python code into R.

from numpy.random import normal
from scipy.stats import ttest_1samp

seed=(1)
sample = normal(150, 10, 20)
print('Sample: ', sample)

t_stat, p_value = ttest_1samp(sample, popmean=155)
print("T-statistic value: ", t_stat)
print("P-Value: ", p_value)

There is a deliberate bug: seed=(1) creates a variable called seed but does not set the random number seed, so the results change every time. Does the tool notice, and does its R version use set.seed(1)?

27.5 When AI gets it wrong

Common failures in R and statistics:

  • Inventing packages, functions or arguments that do not exist.
  • Being out of date. Tools learn from text up to a certain date, so they know less about newer packages and recent changes.
  • Weak arithmetic. Unless it actually runs code, a chatbot is guessing at numbers, and it can be bad at counting and calculating.
  • A plausible but wrong model for your design (e.g. ignoring that the data are counts, or that measurements are repeated on the same individuals).
  • Test-led write-ups that give p-values but no estimates or confidence intervals.
  • Dropping terms from a model just because p > 0.05, without looking at the estimates.

The first three are general problems. The last three are specific to statistics, and they are exactly the mistakes this course teaches you to avoid.

27.5.1 Will it admit that something does not exist?

When asked about something it has no knowledge of, a chatbot will often still produce a confident answer (a “hallucination”). Try this prompt:

In R, how do I use the overdispersion = TRUE argument in glm()
to deal with overdispersed count data?

There is no such argument: R stops with an “unused argument” error. Did your tool invent an explanation, or did it tell you the argument does not exist and point you to a real solution (a quasi-Poisson or negative binomial model, as in the GLM chapters)? What did your neighbour’s tool say? How could you check? (Try running it, and read the help page with ?glm.)

27.5.2 Do two tools agree?

Give two different tools the same prompt:

In R, how do I test whether foam index differs between three espresso
methods, and how should I report it?

Compare the answers. Do they suggest the same model? Do they reach the same conclusion? Do they report estimates with confidence intervals, or only p-values? Which one matches the course book?

27.6 Verify, don’t trust

Before you use AI output in your work:

  1. Run it. Run the code yourself, from a clean R session, and check that it works.
  2. Check the numbers. Every number in a sentence the AI wrote must match your R output.
  3. Check the model. Is it the right model for the data and the design? Compare with the course book.
  4. Check the assumptions. Look at the diagnostic plots yourself.
  5. Check the reporting. Are estimates and confidence intervals reported, not just p-values?
  6. Explain it. If you cannot explain the code or the output in your own words, do not use it.

27.7 Tips for good prompts

  • Give context. Say that you are an MSc biology student, how much R you know, and what the data are (e.g. “I have counts of bee visits per patch and a mown/unmown treatment”).
  • Be specific. Describe the desired outcome, and include the code and any error messages.
  • Set package constraints. Tools often suggest extra packages (sometimes ones that do not exist). Say which packages you want to use, e.g. “use base R, dplyr and ggplot2” for this course.
  • Use small examples. When asking about a problem with your data, share a small, reproducible example rather than the whole data set (and never personal data).
  • Work iteratively. Test small pieces of advice and ask follow-up questions when you don’t understand.
  • Push back, then check. Asking “Are you sure? Check that again.” often surfaces errors. But tools can also cave in and change a correct answer, so pushing back is not a substitute for checking.

27.8 Declaring your use of AI

SDU’s rules require that the reader can see how AI contributed to your work. For the written assignment this means two things:

  1. In the assignment itself, indicate AI use at the relevant point (in the methods, a footnote or an appendix). Text that an AI wrote (directly or paraphrased) must be cited like a quotation, with the tool listed in your references. Describe how AI was used for coding or analysis.
  2. Attach a declaration. The Faculty of Science has a declaration form for this. As a minimum you must state whether you used AI and, if so, which tools you used, what you gave them (a description is enough; see How much detail? below), how you used the output, and how you critically assessed it.

These questions will help you fill in the declaration:

1. Which tools did I use (name and version or model, if known)?
2. What did I use them for? (e.g. writing or starting R code, fixing
   errors, explaining output or statistical concepts, choosing or
   checking the analysis, interpreting results, improving language)
3. What kinds of things did I give them? (e.g. my own code, error
   messages, R output, my draft text; not the exact prompts)
4. Where does AI-generated text or code appear in my assignment
   (directly or edited)?
5. How did I check the output? (e.g. re-ran the code, compared with
   the course book, checked model diagnostics, compared two tools)
6. What did the AI get wrong, or what did I change?

27.8.1 How much detail?

Keep it short. A declaration should take about half a page and five minutes to write. The aim is that the reader can see what kind of help you had and how you checked it, not to reconstruct every conversation.

  • Do not paste your prompts or chat logs. They are long, hard to read and not needed. Summarise instead.
  • Describe types of use, not individual questions. If you asked twenty questions about error messages, that is one line: “fixing errors in my R code”.
  • Describe what you gave the tool in general terms, e.g. “my own code and error messages”, “the output of summary()”, “a draft paragraph of my Discussion”.
  • Be specific only where AI output ended up in your assignment, e.g. “the code for Figure 2 started from a Copilot suggestion, which I edited”.

If you find it hard to summarise, try finishing these sentences: “I used [tool] to help me with [type of task]. I gave it [type of input]. I used the output to [what you did with it]. I checked it by [how].”

For example:

Too vague About right Too much
“I used AI for coding.” “I used Copilot to fix errors in my R code, by giving it my code and the error messages. I checked each fix by re-running the code.” Pasting the 15 prompts and replies from your chat about the error.
“AI helped with the analysis.” “I asked ChatGPT to explain the output of my GLM. I compared its explanation with the GLM chapter of the course book.” A transcript of your conversation, or a list of every question you asked.

Here is an example of a complete declaration with the level of detail expected:

Tools used: Microsoft Copilot Chat (SDU licence); ChatGPT (free version) for one comparison. What for: starting R code; fixing errors; explaining R output; improving language. What I gave them: my own R code and error messages, the output of summary(), and two paragraphs of my Discussion. Where it appears: the ggplot code for Figure 2 started from a Copilot suggestion, which I edited (axis labels, geom_jitter(height = 0)). Two sentences in the Discussion were shortened with Copilot. No AI text appears unedited. How I checked: re-ran all code from a clean session; compared the lm() model with the course book chapter on ANCOVA; checked residual plots with autoplot(); asked both tools the same question about the interaction term and compared answers. What it got wrong: Copilot suggested dropping the interaction because p = 0.08, without looking at the estimate or its confidence interval. I kept the full model and reported the interaction estimate with its CI.

27.8.2 Practice declaration

At the end of the workshop, write a short practice declaration for what you did with AI today, using the questions above. Then swap with a neighbour: could they tell from your declaration exactly what the AI did and how you checked it?