The LLM invents a function that seems plausible but doesn’t exist, or it assigns a function to the wrong package.

Question asked to ChatGPT:

“How do I calculate a standardized Z-score on my age column?”

Response provided:

library(tidyverse)

mydata <- mydata %>%

mutate(z_age = standardize(age))

The problem:

The standardize() function does not exist in the tidyverse.

You must either use scale(age) (base R) or (age - mean(age)) / sd(age).

How can you spot this?

The code throws an error: “could not find function ‘standardize’“:

Error in `mutate()`:

ℹ In argument: `z_age = standardize(age)`.

Caused by error in `standardize()`:

! could not find function «standardize»

If you type a function name in the RStudio console preceded by a “?” (for example: ?standardize), and the documentation finds nothing, it’s most likely a hallucination!

The LLM suggests syntax that worked 2 or 3 years ago but is now deprecated or has been replaced.

Typical examples:

• Suggesting `summarize_each(funs(mean))` instead of `summarize(across(everything(), mean))` (the first form has been obsolete since dplyr 1.0)

• Using `aggregate(data, by=list(group), FUN=mean)` is much more readable and efficient than `group_by() %>% summarize()`

• Mixing packages that are no longer maintained (e.g., plyr when dplyr has been the standard for a long time)

How can you spot this?

The code works, but RStudio displays a warning message such as “summarize_each() was deprecated in dplyr 1.0.0.”

Pay attention to the warnings returned by R and displayed in the console—that’s what they’re there for!

Rule of thumb:

If a deprecation warning appears, ask the LLM, “Give me the current, non-deprecated version.”

This is the most dangerous error, because the code works, but the analysis is wrong. The LLM suggests an inappropriate test, forgets to check the conditions of application, or interprets the results with too much confidence.

Typical examples:

• Suggesting a t-test on data that is clearly not normally distributed, without checking anything

• Using a chi-square test when the expected counts are less than 5 (the correct choice would be Fisher’s exact test)

• Comparing four groups in pairs using t-tests without correcting for multiple testing

• Interpreting a p-value < 0.05 as “evidence of an effect” without considering power or effect size

How to spot it:

No errors or warnings are returned! That’s why you need to be vigilant. Always ask the LLM: “What are the conditions for applying this test? How can they be verified?”

Rule of thumb:

Code alone isn’t enough. Before applying a test, understand why this particular test is being used, not another. If you’re unsure, it’s time to seek expert human advice!

The LLM cannot see your screen. It knows nothing about your table’s structure, the packages you use, or the version of R you have installed. If you don’t tell it anything, it will guess—and not always correctly.

What you need to provide:

• The nature of the dataset: how many rows, how many columns, what type of data (numeric, categorical, dates…)

• The exact names of the columns relevant to your question

• The package(s) you want to use (tidyverse? base R? ggplot2?)

• The data structure, not the data itself (we’ll get to that next)

Confitiality

What to do instead:

• Describe the structure: “I have a numeric age column, a 4-category diagnosis column, and a date_inclusion column in Date format.”

• Paste the output of `str(data)` or `glimpse(data)`: It shows the data types and a few examples, without revealing the entire content.

• Create a small fictional dataset that resembles yours, with five made-up rows that share the same structure.

• Anonymize the data if you absolutely must show an excerpt (replace names, scramble identifiers, round off sensitive values).

Example of a well-defined context, without data leakage:

“I have a 320-row, 8-column ‘patients’ data frame, imported using read_csv(). The relevant columns are age (numeric, between 18 and 92), gender (2-level categorical: F/M), and systolic_blood_pressure (numeric, with about 5% NA). I’m working with the tidyverse.”

The LLM has everything it needs to write correct code for you, without having seen a single row of your table.

2.2 Step 2: The goal: Say what you want to achieve, not how

When we’re just starting out, we tend to write our prompts as technical requests:

“How do I do a group_by() followed by a summarize() with mean()?”

This isn’t a good approach because you’re imposing a solution on the LLM before it has even understood your need. And if your solution isn’t the right one, it will code it for you anyway!

The objective should instead describe the expected result, allowing the LLM to choose the function.

Avoid:

“Give me a mutate() with case_when() to create an age_category variable.”

Instead, try:

“I want to create a new column that classifies patients into three age groups: under 40, 40 to 65, and over 65.”

The second phrasing allows the LLM to propose the cleanest solution. The first one locks it into a choice that may not be optimal.

This is a step that’s often overlooked, but it will save you time. If you don’t specify anything, the LLM will respond with a long block of explanations, alternatives, “there’s also…,” and you’ll have to dig through it to find the useful code.

What you can ask for:

• Code only, without explanations (“respond only with the code block, without comments”)

• Code commented line by line if you want to learn

• Multiple versions (“suggest two ways to do this: one using base R, one using tidyverse”)

• A specific output format (“the result must be a data frame with exactly 3 columns: group, mean, standard deviation”)

Example:

“Respond with a single block of tidyverse code, commented in English that produces a data frame sorted by descending mean.”

The assembled prompt:

Here’s what a complete prompt following the method looks like:

Background: I have a “patients” data frame with 320 rows and 8 columns, containing the variables age (numeric), sex (categorical: F/M), and systolic_blood_pressure (numeric, with a few NA values). I am working with the tidyverse.

Objective: I want to create a new column, age_category, that classifies patients into three age groups: under 40, 40 to 65, and over 65.

Expected format: A single block of tidyverse code, commented in English, that adds this new column to the existing data frame.

The benefit isn’t just speed (you can dictate 3 to 4 times faster than you can type). It’s also that you phrase things more naturally. When speaking, you spontaneously explain the context, what you want, and how you want it. It’s exactly the three-part structure, but without conscious effort.

You can simply say, “So here’s the thing: I have a table of 320 patients with columns for age, gender, and blood pressure. I’d like to create a new column that classifies patients into three age groups—under 40, 40 to 65, and over 65—and just give me the tidyverse code with comments in English.” The LLM understands this spoken language very well, and you’ll get just as precise a response as with a carefully written prompt.

This structure forces the LLM to focus on your specific problem, not on the generic problem it thinks it recognizes. It reduces hallucinations (as seen in Section 1) because by providing context, you’re implicitly telling it, “Don’t give me a function that doesn’t apply to this data.”

With a little practice, dictating a structured prompt takes 20 seconds and saves you 10 minutes of debugging.

Rule of thumb:

Before sending your prompt, reread it and check that it contains all three blocks. If one is missing, add it. This habit will become automatic in a few days.

• Run the entire block, not line by line. Some errors only appear in context.

• Read the console: not just the last line, but also the intermediate messages.

• Distinguish between the three types of output:

- An error (Error in...): The code stops, and you see it immediately.

- A warning (Warning message:): The code has finished, but R reports a problem. Do not ignore it. This is often where deprecated functions, silently introduced NaNs, or questionable type conversions are hidden.

- A message (plain text without a prefix): generally informative, but sometimes important (“Joining with by = ...” may reveal a join performed on the wrong column).

Tip : If you see a warning and don't understand it, paste it intor the LLM and ask, "What does this warning mean, and do I need to fx it"

Three quick checks:

• dim() or nrow(): How many rows and columns? Does this number make sense? If you were expecting a summary by group with three groups and you get 320 rows, something is wrong. (figure 1)

• head(): What do the first few rows look like? Are the columns what you expected?

• str() or glimpse(): Are the data types correct? A date stored as a character, a factor stored as numeric, a variable that’s supposed to be an integer but is a double with strange decimals—these are all signs that something went wrong earlier in the process.

The code runs, and the result has the right format. But are the numbers themselves credible?

This is where your domain knowledge becomes essential—and it’s something an LLM lacks.

Some questions to ask yourself:

• Are the orders of magnitude correct? An average systolic blood pressure of 1,200 or 12 mmHg is suspicious. An average age of 450 years is too.

• Do the summed numbers match the expected total? If you group 320 patients by gender and get 180 + 90 = 270, 50 people are missing somewhere (likely unmanaged NA cases).

• Are there any absurd values: negatives where they’re impossible, percentages over 100, dates in 1900 or 2087?

• Are there any unexpected NA values?

Two tools are very useful for answering these questions.

The first is the summary() function (figure 2). Applied to an entire data frame, it gives you the minimum, maximum, median, mean, quartiles, and number of NAs for each numeric column.

For categorical columns, it gives you the counts per category. With a single command, you can see outliers, skewed distributions, and missing values at a glance.

If you just want to count the NAs column by column, colSums(is.na(data)) does the job more directly.

The second is the RStudio viewer (figure 3). Click on the data frame name in the Environment tab (top right), or type View(data) in the console. The table opens in a tab, where you can click on the header of any column to sort the values in ascending or descending order.

This is very handy for spotting, in just two clicks, an absurd maximum value, a negative number that shouldn’t exist, or a birthdate in 1850. You can also use the small search bar at the topright of the viewer to quickly filter rows containing a specific value. If something seems off, don’t validate it. Go back to the code, or ask the LLM to explain it line by line.

Rather than blindly trusting the result across your 320 lines, apply the code to a mini dataset where you know the answer in advance.

Example:

The LLM has written code for you to calculate the average voltage by gender with NA handling. Before applying it to your real data, create a dummy dataset:

test <- data.frame(

sexe = c(«F», «F», «F», «M», «M», «M»),

tension = c(120, 130, NA, 140, 150, 160)

)

You know in advance that the expected average is 125 for women (ignoring the NA) and 150 for men. If the code returns these two numbers, it is probably correct. If it returns something else, for example, 83 for women (because the NA was counted as 0), you have found a bug before it affects your actual analysis.

• You know what you want to do, but not how to write it in R: “I want to convert my table from wide format to long format, by date variable.” The LLM produces a suitable pivot_longer() in seconds.

• You want to explore several approaches: “Give me three different ways to visualize the distribution of a numeric variable.” The LLM is an excellent generator of alternatives.

• You need to decode an error message. Paste the error and the code, and ask for an explanation. It’s often faster than searching on Stack Overflow.

• You want to translate code from one “dialect” to another. Switch from base R to the tidyverse, or vice versa.

• You want to quickly generate repetitive code. A loop that produces 20 similar plots, a script that renames 40 columns according to a pattern—the LLM saves you a ton of time. Note that GitHub Copilot is also a good option in this situation.

• You want a comment or an explanatory note on a block of code you’ve written to verify your understanding.

The official documentation remains irreplaceable, and too few beginners consult it. Here’s when to prioritize it:

• You want to understand exactly what a function does. Type “?function_name” in the console: You’ll get the exact list of arguments, their default values, the return type, and often reproducible examples at the bottom of the page. It’s the definitive source.

• The LLM has given you working code, but you want to know if a different option might be better. The function’s help lists all the arguments, whereas the LLM often only mentions the most common ones.

• You are working with a specialised package (epidemiology, time series, geostatistics, etc.). Many of these packages have vignettes (detailed instructional documents) accessible via `browseVignettes(‘package_name’)`. These are written by the authors, are up to date, and are often worth ten prompts.

• You want to check for potentially obsolete syntax (see Chapter 1). The documentation displays

deprecation warnings and indicates the replacement function.

• You are looking for a comprehensive list of a package’s functions. Type help(package =

‘package_name’) or visit the package’s website (often a very comprehensive pkgdown).

I recommend consulting a competent professional (colleague, supervisor, statistician, specialist forum) in the following cases:

• Choosing a statistical method for your specific problem. Which test? Which model? Which correction for multiple comparisons? The LLM will give you a plausible answer, but the right choice depends on your study design, the nature of your variables, the assumptions you can or cannot verify, and the actual scientific question. This is exactly the kind of decision where bad advice goes unnoticed — and where the consequences can be significant (see section 1, Error No. 3).

• Interpreting your results. An LLM can describe what a p-value generally means. It cannot tell you whether, in your context, your result is robust, biased, or trivial (in any case, you are taking a risk).

• Any question involving sensitive data that you cannot share with an LLM (see section 2). A human subject to the same confidentiality obligations (colleague, supervisor) can view the actual data — an LLM cannot.

• Key methodological decisions: experimental design, sample size, analysis plan, choice of protocol. These decisions shape your entire study. They warrant a proper discussion with someone who knows your field.

• When you have a hunch that something is amiss, but cannot put your finger on what it is. This intuition is important, and it is best discussed with a human who can ask the right questions in return.