Most quantitative work in public health is now done by writing code. An analyst who estimates the prevalence of loneliness, compares vaccination coverage across regions or fits a regression model usually does so in a statistical programming language such as R, Python, SAS or Stata. Until recently, a student who had never programmed needed weeks of practice before producing a first reliable table. AI coding assistants change that starting point. A student can describe an analysis in plain language, receive working code within seconds, ask what each line does and ask for help when R reports an error. This lesson teaches the practices that turn that capability into analyses a student can trust and defend.

The lesson follows a single analysis from beginning to end. It uses the 2021 wave of the Canadian Social Connection Survey, a public, de-identified dataset that appears in HSCI 207 Lesson 11 and in several HSCI 410 lessons, and it shows the prompts, the code an assistant proposed, the real R output and the checks applied at each step. This first section describes the tools and summarizes what controlled studies show about their effect on the speed of programming work.

Box 8.1 introduces the Cedar Valley Health Authority, its Connector program for socially isolated and lonely older adults, and Jordan, a co-op student whose first analysis in R supplies the example followed through the lesson.

Why analysts write code

A spreadsheet hides its steps: once a column has been recoded or a row deleted by hand, nobody can see what was done. A script, which is a plain text file of instructions that a program carries out in order, records every step. Anyone with the script and the data can run it again, see each decision and obtain the same result. That property is called reproducibility, and it is the reason HSCI 410 Lesson 1 treats the script as the official record of an analysis.

R is a free, open-source language for statistics and graphics. It was created by the statisticians Ross Ihaka and Robert Gentleman at the University of Auckland in the early 1990s and is now maintained by a large international community. Much of its usefulness comes from packages, which are bundles of additional functions that users install. This lesson uses three of them: dplyr, for selecting, filtering and summarizing data; readr, for reading and writing data files; and ggplot2, for plots. Hadley Wickham, chief scientist at Posit, created both dplyr and ggplot2.

Language models write code well for reasons that Lesson 2 explained. Their training data contain very large amounts of public code, and code is highly regular, so the next token in a line of R is often easy to predict. Code also has a property that ordinary prose lacks: it can be run. A factual claim in a paragraph can only be checked against a source, but a line of R either runs or produces an error message, and when it runs, its result can be compared with a count, a hand calculation or a second method. AI-written code is therefore easier to verify than many other kinds of AI output, provided that the user actually runs and checks it.

The next part describes the four forms in which AI coding assistance is available and what each can see of the data.

Four forms of coding assistance

Coding assistance arrives in four main forms in 2026. They differ in what the assistant can see, in who runs the code and in how much the assistant does before a person reviews its work. The products named below are examples available in 2026; the categories are likely to outlast any particular product.

The tabs that follow describe the four forms in turn, with examples of current products and the main weakness of each.

Table 8.1 sets the four forms side by side, with what each can see, who runs the code and the work each suits.

Table 8.1. Four forms of AI coding assistance, with what each can see, who runs the code and the work each suits.

What the assistant knows about the data

All four forms share one limit: an assistant knows only what it has been told or shown about the data. A chat assistant that has never seen the Canadian Social Connection Survey cannot know that the age variable is named DEMO_age, that the loneliness items are stored as ordered categories, or that a question shown to a respondent and left blank is recorded as the text "Presented but no response". It fills each gap with a plausible guess, and plausible guesses produce code that looks right. There are two ways to close the gap. The user can describe the data through its data dictionary, which is the document that lists each variable's name, meaning, type, permitted values and missing-value codes (Section 2 shows how), or the user can give a tool access to the data itself, which is subject to the governance rules in Section 4.

With the forms of assistance and their shared limit described, the next part turns to the evidence from randomized studies on whether AI tools make programmers faster.

What the evidence says about speed

Two randomized studies are often cited on the question of whether AI tools make programmers faster. They reached very different results, and the reasons for the difference are the most useful part of the evidence.

A defined task completed 56 percent faster

Peng, Kalliamvakou, Cihon and Demirer (2023) recruited 95 professional programmers through a freelancing platform and asked them to write an HTTP server in JavaScript as quickly as possible. An HTTP server is a small program that answers requests from web browsers; the task was self-contained, clearly specified and of a kind that appears often in public code. The programmers were randomly assigned to work with or without GitHub Copilot. Those with the assistant finished in an average of about 71 minutes, compared with about 161 minutes for the control group, which is 55.8 percent less time. The authors also reported signs that developers with less programming experience gained more, although that estimate was imprecise.

Experienced developers on their own projects took 19 percent longer

METR, a research organization that evaluates AI systems, ran a randomized trial with 16 experienced open-source developers (Becker, Rush, Barnes and Rein, 2025). The developers worked on 246 real tasks, such as bug fixes, new features and reorganizations of code, in large and mature software projects to which they had contributed for years; the projects averaged more than 22,000 stars on GitHub and more than one million lines of code. Each task was randomly assigned to allow or disallow AI tools, and when AI was allowed the developers mostly used an AI-enabled code editor with leading models of early 2025. Tasks completed with AI took 19 percent longer. Before the study, the developers had forecast that AI would cut their time by 24 percent, and after it they still believed that AI had made them about 20 percent faster.

METR stated the limits of its result plainly: the trial is a snapshot of early-2025 tools in one setting, it does not show that most developers or most programming work are slowed by AI, and AI may help more with unfamiliar code or less experienced developers. METR has continued to publish measurements as the tools have changed.

Figure 8.1 sets the results of the two studies side by side, using the figures their authors reported.

Reading the two studies together

Both studies were randomized, and their settings differed in three ways. The tasks differed: a new, self-contained program of a familiar kind in the first study, and changes to large, complex code with high standards for quality in the second. The people differed: freelance professionals meeting a task for the first time, and experts who already knew their code in detail. The most reasonable reading is that the gains from AI coding tools depend on the task and on the user's relationship to it. When a task is well defined and common, an assistant's first answer is usually close to right and the time saved is large. When an expert already knows what the code should do and must review, correct and adapt the assistant's suggestions to a complex project, the review can cost more time than the assistant saves.

The METR result also shows a gap between perception and measurement. Developers who were slower with AI felt faster, which suggests that a person's impression of an AI-assisted session is an unreliable guide to its real effect. For a data analyst, the corresponding risk concerns correctness more than speed: an analysis produced quickly with an assistant feels finished, and only checks of the kind taught in Section 3 can show whether it is right.

The next part considers what this evidence implies for a student who has never written R.

What this means for a beginner in R

A student who has never programmed differs from the participants in both studies. The potential gain is larger, because the alternative is often no analysis at all, and the ability to judge the code is smaller, because the student cannot yet tell good R from bad R at a glance. That combination explains the design of this lesson. Students do not need to write R from memory to use it well with an assistant, but they do need to read each line well enough to say what it does, run the code in small steps, read the output and apply checks that would reveal an error. Lesson 3 described AI capability as a jagged frontier, strong on some tasks and weak on others that look similar. For R, the frontier runs roughly as the cards below describe.

The accordion that follows takes up three questions about learning R with an assistant: whether the language still needs to be learned, which form of assistance to start with, and whether code written with an assistant counts as the student's own work.

Box 8.2 asks the reader to match four tasks to the form of coding assistance that suits each and to name one risk to watch for.

Jordan settles on the pilot's chat assistant for the analysis, because each step will then be visible, logged and run by Jordan personally. Section 2 sets out the workflow Jordan follows and the first four steps of the analysis.

Before that, the reflection and knowledge check that follow review the forms of coding assistance and the evidence on their effect on speed.

An assistant can produce a complete analysis script in one reply, and for a beginner that is the least useful thing it can do. A long script that has never been run hides its errors among dozens of lines, and a student who cannot yet read R has no way to find them. The workflow in this section slows the process down to a pace at which each piece of code is understood and checked before the next one is written. It assumes no prior experience with R. Students who have not yet installed R and RStudio can follow the setup in HSCI 410 Lesson 1, and HSCI 207 Lesson 11 explains data dictionaries and missing-value codes using the same survey.

A workflow for writing R with an assistant

The workflow in this lesson turns a request for code into a sequence of small steps, each of which is run, read and checked before the next is written. Figure 8.2 shows the workflow as a whole, in which most steps repeat for every small piece of the analysis and the script is saved and logged once the last check has passed. The subsections that follow describe its parts: describing the data, asking for code in small steps, running and reading each step, asking for explanations and saving the work.

Describe the data through its data dictionary

The assistant writes code for data it cannot see, so the quality of its code depends on the description it receives. The most efficient description is the relevant part of the data dictionary: each variable's exact name, the question it records, its type (number, text or category), its permitted values and its missing-value codes. A missing-value code is a value that stands for a missing answer, such as 999, -88 or, in the Canadian Social Connection Survey, the text "Presented but no response". Describing the data in this way gives the assistant what it needs without sending a single record, which is also the habit that Section 4 requires for confidential data. A useful prompt adds who the user is, the question the analysis must answer and an instruction to ask for anything the dictionary does not say.

Ask for code in small steps

Each request should cover one step that produces output the user can inspect: load the data and count the rows, keep the needed variables, recode one kind of missing value, create one new variable. Small steps keep each block of code short enough to read, they make an error easy to locate, and they create a natural point at which to check the result. It also helps to ask the assistant what output to expect, because a prediction made before the code is run gives the user something to compare against.

Run and read each step

The user runs every block in an R session (in RStudio, Positron or the R console) and reads all of the output. A warning means that R completed the step but noticed something worth attention, such as values it could not convert. An error means that R stopped without completing the step, which is the safer kind of failure, because a step that stops cannot silently produce a wrong number.

Ask for explanations

After each step, the user can ask what a function does, what each argument means and what an error message means. Over a few analyses, these questions build the reading fluency in R that checking requires.

Save the work

Code that has been run and checked goes into a single script, with a comment on each step, so that the whole analysis can be rerun from the top. The script, together with the AI use log introduced in Lesson 3, records what the assistant drafted and how each step was checked.

The workflow asks a student to read each block of code and its output. The next part sets out the minimum R notation needed to do so.

Reading R: a minimum vocabulary

A beginner can read most of the code in this lesson with the eight pieces of notation in Table 8.2. In nrow(cscs), R applies the function nrow(), which counts rows, to the object called cscs. A function is a named operation that takes inputs, called arguments, inside its parentheses and returns a result.

Table 8.2. Eight pieces of R notation, with their meaning in plain language and an example of each.

With this vocabulary, the code in the demonstration that follows can be read line by line. Worked Example 8.1 begins the demonstration that runs through the rest of the lesson: Jordan describes the survey to the assistant through its data dictionary and asks for a plan and the code for the first step only.

SURVEY_collection_year: survey wave (2021, 2022, 2023 or 2024)
DEMO_age: integer, "How old are you (in years)?" (16 to 100 in 2021)
DEMO_gender: factor; Man, Woman, Non-binary, Presented but no response
GEO_province: factor; 13 provinces and territories, Presented but no response
LONELY_ucla_loneliness_scale_companionship: ordered factor,
  "How often do you feel that you lack companionship?"
  Hardly Ever, Some of the time, Often, Presented but no response
LONELY_ucla_loneliness_scale_left_out: ordered factor,
  "How often do you feel left out?" (same options)
LONELY_ucla_loneliness_scale_isolated: ordered factor,
  "How often do you feel isolated from others?" (same options)
LONELY_ucla_loneliness_scale_score: integer, 3 to 9 (items scored 1 to 3, added)
Codes: "Presented but no response" = question shown and left blank;
NA = a question never answered.

The R code, output and checks for the first four steps follow. Worked code 8.1 loads the survey and keeps the 2021 wave, Worked code 8.2 shows the error produced by code written before the assistant saw the dictionary, Worked code 8.3 selects and renames the seven variables, and Worked code 8.4 counts the missing values and recodes the missing-value code.

library(dplyr)     # verbs for data frames: filter, select, mutate, summarise
library(readr)     # write_csv() and read_csv()
library(ggplot2)   # plots

github_url <- "https://raw.githubusercontent.com/jorgeandr3s/heal/main/cscs/public_data/CSCS2025_full_cleaned_deidentified_data_and_metadata.RData"
load(url(github_url))          # creates a data frame called data

cscs <- data |>
  filter(SURVEY_collection_year == 2021)   # keep the 2021 wave only

nrow(cscs)    # rows: one per respondent
ncol(cscs)    # columns: one per variable

[1] 4045
[1] 3247

try(
  lonely <- cscs |>
    select(age, gender, province, ucla_score)
)

Error in select(cscs, age, gender, province, ucla_score) :
  Can't subset columns that don't exist.
x Column `age` doesn't exist.

lonely <- cscs |>
  select(age           = DEMO_age,
         gender        = DEMO_gender,
         province      = GEO_province,
         companionship = LONELY_ucla_loneliness_scale_companionship,
         left_out      = LONELY_ucla_loneliness_scale_left_out,
         isolated      = LONELY_ucla_loneliness_scale_isolated,
         ucla_survey   = LONELY_ucla_loneliness_scale_score)

glimpse(lonely)   # one line per column: name, type, first values

Rows: 4,045
Columns: 7
$ age           <int> 58, 35, 39, 55, 70, 60, 77, 37, 50, 24, 27, 29~
$ gender        <fct> Woman, Non-binary, Man, Woman, Woman, Woman, M~
$ province      <fct> Alberta, British Columbia, British Columbia, O~
$ companionship <ord> Often, Some of the time, Often, Some of the ti~
$ left_out      <ord> Often, Often, Often, Some of the time, Often, ~
$ isolated      <ord> Often, Some of the time, Often, Hardly Ever, O~
$ ucla_survey   <int> 9, 7, 9, 5, 9, 6, 3, 5, 8, 8, 5, 6, 7, 3, 4, 6~

colSums(is.na(lonely))                  # NA count in each column
table(lonely$gender, useNA = "ifany")   # every answer, NA included

          age        gender      province companionship      left_out
            0             3             0           421           421
     isolated   ucla_survey
          421           462

                      Man                     Woman
                     1883                      2049
               Non-binary Presented but no response
                      106                         4
                     <NA>
                        3

lonely <- lonely |>
  mutate(gender   = na_if(as.character(gender),
                          "Presented but no response"),
         province = na_if(as.character(province),
                          "Presented but no response"))

table(lonely$gender, useNA = "ifany")   # the 4 codes are now NA
sum(is.na(lonely$province))             # 50 codes became NA
summary(lonely$age)                     # plausible range for adults?

       Man Non-binary      Woman       <NA>
      1883        106       2049          7

[1] 50

   Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
   16.0    28.0    34.0    39.8    52.0   100.0

By the end of these four steps, the survey file has been loaded, reduced to seven variables and checked for missing values. The next part turns to prompts that ask the assistant to explain the code at each step.

Asking for explanations

Every block in Worked code 8.1 to Worked code 8.4 contains functions that a beginner has not met before. Each of the prompts below asks the assistant to explain the code the student is actually running, which keeps the explanations tied to real output.

Explanations of this kind build the reading fluency that checking requires. Once a step has been explained and checked, its code is saved, which the next part describes.

Saving the work

Once a step has run and passed its checks, its code goes into the script in order, with a comment that says what the step does. The downloadable script for this lesson follows that pattern, and it labels the blocks that contain the assistant's errors. A script should run from a fresh R session without any manual steps, so the final test of a saved script is to restart R and run it from the first line to the last.

Analysts who want text, code and output in one report can use a Quarto document, a file with the extension .qmd that mixes paragraphs of writing with chunks of R code. Quarto, an open-source publishing system developed by Posit, runs the code and inserts the output into an HTML, Word or PDF report, so the numbers in the report always come from the code.

The AI use log introduced in Lesson 3 records the assistant's part in the analysis. A short entry for each working session is enough, as in Jordan's first entry in Table 8.3.

Table 8.3. Jordan's AI use log entry for the first analysis session.

Box 8.3 asks the reader to explain a single line of R in plain words, using the notation introduced in this section.

The first four steps produced a file of 4,045 respondents with the right variables and with the gender and province codes converted. The assistant's remaining code (scoring the items, building the age groups, the table and the plots) runs without a single error message. Section 3 shows that two of those steps are nonetheless wrong, and how the checks find them.

Before that, the reflection and knowledge check that follow review the workflow, the data dictionary and the first four steps of the analysis.

When R stops with an error message, the problem is visible and an assistant can usually explain it. The harder case is code that runs to the end and prints a tidy result that is wrong. Such silent errors arise most often where the code meets the data: a missing-value code that the code treats as a real answer, a boundary that puts people in the wrong group, or a filter that removes rows without saying so. An assistant that has been told little about the data makes these errors easily, and a beginner cannot spot them by reading the code. They are found by checking the results.

Four checks for an AI-written analysis

The four checks in Table 8.4 catch most silent errors in descriptive analyses. None of them requires advanced R, and an assistant can write the code for each one. The effort should rise with the stakes, as Lesson 3 recommended for verification in general: a figure for a planning meeting deserves every check, and an exploratory look at a variable may need only the first.

Table 8.4. Four checks for an AI-written analysis, with what each one catches and how to carry it out in R.

The two parts that follow apply these checks to the next two steps of Jordan's analysis, the scoring of the loneliness items and the construction of the age groups.

Check in action: scoring the loneliness items

The next step in Jordan's plan scores the three UCLA items and adds them. The demonstration continues with the prompt, the assistant's code as proposed, and the real output.

Box 8.4 gives Jordan's prompt for this step and Box 8.5 the assistant's reply. Worked code 8.5 shows the code as proposed, with a range check and a comparison against the survey's own score applied to its output.

lonely <- lonely |>
  mutate(ucla_score = as.numeric(companionship) +
                      as.numeric(left_out) +
                      as.numeric(isolated))

table(lonely$ucla_score, useNA = "ifany")   # every value, NA included

   3    4    5    6    7    8    9   10   12 <NA>
 494  490  806  888  403  209  315    4   15  421

# Second method: compare with the score the survey team computed
lonely |>
  count(ours_missing   = is.na(ucla_score),
        survey_missing = is.na(ucla_survey))

# Look at the rows where the two disagree
lonely |>
  filter(!is.na(ucla_score), is.na(ucla_survey)) |>
  select(companionship, left_out, isolated, ucla_score) |>
  head(3)

levels(lonely$companionship)   # the order of the levels decides the numbers

  ours_missing survey_missing    n
1        FALSE          FALSE 3583
2        FALSE           TRUE   41
3         TRUE           TRUE  421

              companionship                  left_out
1 Presented but no response Presented but no response
2               Hardly Ever          Some of the time
3 Presented but no response Presented but no response
                   isolated ucla_score
1 Presented but no response         12
2 Presented but no response          7
3 Presented but no response         12

[1] "Hardly Ever"               "Some of the time"
[3] "Often"                     "Presented but no response"

The consequences reach further than the 19 impossible values. Since the smallest possible wrong score is 1 + 1 + 4 = 6, every one of the 41 respondents would have been counted as screening positive at the Connector threshold. Comparing the table in Worked code 8.5 with the corrected table in Worked code 8.6 shows that 22 of the 41 wrong scores fell inside the valid range (10 extra respondents at 6, 6 at 7, 3 at 8 and 3 at 9). A range check alone would have missed more than half of the errors, and only the comparison with an independent second method found them all. HSCI 207 Lesson 11 makes the same point about numeric codes such as 999: a code treated as a number distorts every summary that includes it.

Worked code 8.6 gives the corrected scoring code, which states the scoring rule in full and confirms the result with a second method and a known-answer test.

score_item <- function(x) {
  x <- as.character(x)
  case_when(x == "Hardly Ever"      ~ 1,
            x == "Some of the time" ~ 2,
            x == "Often"            ~ 3,
            TRUE                    ~ NA_real_)
}

lonely <- lonely |>
  mutate(ucla_score = score_item(companionship) +
                      score_item(left_out) +
                      score_item(isolated))

table(lonely$ucla_score, useNA = "ifany")
all.equal(lonely$ucla_score, lonely$ucla_survey)   # second method agrees?

   3    4    5    6    7    8    9 <NA>
 494  490  806  878  397  206  312  462

[1] TRUE

test <- data.frame(
  companionship = c("Hardly Ever", "Often", "Some of the time", "Often"),
  left_out      = c("Hardly Ever", "Often", "Some of the time",
                    "Presented but no response"),
  isolated      = c("Hardly Ever", "Often", "Often", "Often"))

test |>
  mutate(score = score_item(companionship) + score_item(left_out) +
                 score_item(isolated))
# Expected by hand: 3, 9, 7 and NA

     companionship                  left_out    isolated score
1      Hardly Ever               Hardly Ever Hardly Ever     3
2            Often                     Often       Often     9
3 Some of the time          Some of the time       Often     7
4            Often Presented but no response       Often    NA

With the scores corrected and confirmed, the analysis moves to step 5 of Jordan's plan, the construction of the age groups, where a second silent error appears.

Check in action: building the age groups

Age groups are built by cutting a continuous variable at chosen boundaries, and errors in grouping arise at those boundaries. Box 8.6 gives Jordan's prompt for step 5 and Box 8.7 the assistant's reply. Worked code 8.7 shows the code as proposed, the checks that expose its two errors and the correction.

age_labels <- c("16 to 29", "30 to 44", "45 to 64", "65 and older")

lonely <- lonely |>
  mutate(age_group = cut(age, breaks = c(16, 30, 45, 65, Inf),
                         labels = age_labels))

table(lonely$age_group, useNA = "ifany")

lonely |>
  group_by(age_group) |>
  summarise(n = n(), youngest = min(age), oldest = max(age))

    16 to 29     30 to 44     45 to 64 65 and older         <NA>
        1619         1203          774          439           10

# A tibble: 5 x 4
  age_group        n youngest oldest
  <fct>        <int>    <int>  <int>
1 16 to 29      1619       17     30
2 30 to 44      1203       31     45
3 45 to 64       774       46     65
4 65 and older   439       66    100
5 <NA>            10       16     16

# CORRECTED: right = FALSE makes each group include its lower boundary
lonely <- lonely |>
  mutate(age_group = cut(age, breaks = c(16, 30, 45, 65, Inf),
                         labels = age_labels, right = FALSE))

lonely |>
  group_by(age_group) |>
  summarise(n = n(), youngest = min(age), oldest = max(age))

# A tibble: 4 x 4
  age_group        n youngest oldest
  <fct>        <int>    <int>  <int>
1 16 to 29      1379       16     29
2 30 to 44      1395       30     44
3 45 to 64       785       45     64
4 65 and older   486       65    100

With the scores and the age groups corrected, the remaining steps save the cleaned file, compute the descriptive table and draw two plots, which the next part presents.

The cleaned file, the descriptive table and two plots

The last step of Jordan's plan produces the results that answer the team lead's question. Worked code 8.8 saves the cleaned file and reads it back, and Worked code 8.9 computes the descriptive table and confirms its last column by a second method.

clean <- lonely |>
  mutate(screen_positive = ucla_score >= 6) |>   # Connector threshold
  select(age, age_group, gender, province, ucla_score, screen_positive)

write_csv(clean, "cscs2021_loneliness_clean.csv")
nrow(read_csv("cscs2021_loneliness_clean.csv", show_col_types = FALSE))

[1] 4045

table1 <- clean |>
  filter(!is.na(ucla_score)) |>
  group_by(age_group) |>
  summarise(n          = n(),
            mean_score = round(mean(ucla_score), 2),
            sd_score   = round(sd(ucla_score), 2),
            pct_6_plus = round(100 * mean(screen_positive), 1))
table1
sum(table1$n)   # respondents with a score

# Second method: the survey team's own yes/no version of the same cut-off
check <- table(clean$age_group, cscs$LONELY_ucla_loneliness_scale_score_y_n)
round(100 * prop.table(check, margin = 1), 1)

# A tibble: 4 x 5
  age_group        n mean_score sd_score pct_6_plus
  <fct>        <int>      <dbl>    <dbl>      <dbl>
1 16 to 29      1251       5.49     1.46       49.6
2 30 to 44      1222       5.4      1.59       45.5
3 45 to 64       677       5.99     2.03       57.9
4 65 and older   433       5.65     2.09       51.7

[1] 3583


               No (3-5) Yes (6-9)
  16 to 29         50.4      49.6
  30 to 44         54.5      45.5
  45 to 64         42.1      57.9
  65 and older     48.3      51.7

Plotting is the third check, and here it also adds to the description. The script draws both plots with ggplot2 and saves them as image files; Figure 8.3 and Figure 8.4 redraw them from the numbers that R printed. The R code for the first plot also prints the percentages it shows.

Worked code 8.10 gives the ggplot2 code for both plots.

dist <- clean |>
  filter(!is.na(ucla_score)) |>
  mutate(group = if_else(age >= 65, "65 and older", "Under 65")) |>
  count(group, ucla_score) |>
  group_by(group) |>
  mutate(pct = round(100 * n / sum(n), 1)) |>
  ungroup()
print(dist, n = 14)

p1 <- ggplot(dist, aes(x = factor(ucla_score), y = pct, fill = group)) +
  geom_col(position = "dodge") +
  labs(x = "UCLA Loneliness Scale score (3 to 9)",
       y = "Percent of age group", fill = NULL,
       title = "Loneliness scores, CSCS 2021") +
  theme_minimal()
ggsave("ucla_distribution_by_age.png", p1, width = 7, height = 4, dpi = 150)

p2 <- ggplot(table1, aes(x = age_group, y = pct_6_plus)) +
  geom_col(fill = "#0B7B6B") +
  geom_text(aes(label = paste0("n = ", n)), vjust = -0.4) +
  labs(x = "Age group", y = "Percent scoring 6 or higher",
       title = "Screen-positive for loneliness, CSCS 2021") +
  theme_minimal()
ggsave("screen_positive_by_age_group.png", p2, width = 7, height = 4, dpi = 150)

# A tibble: 14 x 4
   group        ucla_score     n   pct
   <chr>             <dbl> <int> <dbl>
 1 65 and older          3   100  23.1
 2 65 and older          4    51  11.8
 3 65 and older          5    58  13.4
 4 65 and older          6    81  18.7
 5 65 and older          7    40   9.2
 6 65 and older          8    39   9
 7 65 and older          9    64  14.8
 8 Under 65              3   394  12.5
 9 Under 65              4   439  13.9
10 Under 65              5   748  23.7
11 Under 65              6   797  25.3
12 Under 65              7   357  11.3
13 Under 65              8   167   5.3
14 Under 65              9   248   7.9

Figure 8.3 shows something the table's means conceal. Respondents aged 65 and older are spread toward both ends of the scale: 23.1 percent have the lowest possible score of 3 and 14.8 percent have the highest score of 9, compared with 12.5 percent and 7.9 percent of younger respondents. Younger respondents cluster in the middle, at scores of 5 and 6. This pattern is consistent with the larger standard deviation in the oldest group, and it means that "about half of older respondents screen positive" describes two quite different subgroups, one with little loneliness and one with a great deal. The plot also serves as a check: drawn from the uncorrected score, the same chart would have shown bars at 10 and 12 on a scale that ends at 9.

Jordan's summary for the team lead reports these figures as descriptive context and states their limits. The survey recruited respondents online and is cross-sectional, so the percentages describe the people who took part in 2021 and are not estimates for the Canadian population or for Cedar Valley, and no statistical test was run, so the differences between age groups are described without any claim that they would persist in another sample.

These results came from code that ran and checks that passed. Whether a descriptive table was the right analysis for the question is a separate decision, which the next part considers.

The choice of analysis belongs to the analyst

The assistant would have written equally fluent code for a regression model or a test across all thirteen provinces and territories. It cannot judge whether an analysis answers the question or whether its assumptions hold, and it tends to accept the framing it is given. Deciding that a descriptive table with a stated threshold answered the team lead's question was Jordan's decision, made with the epidemiologist. The methods themselves are taught in HSCI 410: Lesson 2 covers data cleaning and descriptive analyses, Lesson 3 covers regression, and Lesson 6 covers visualization with ggplot2.

Choosing one analysis also raises the question of what happens when an assistant makes many analyses easy to run, which the next part takes up.

Many analyses and the garden of forking paths

AI makes another analysis almost free. An analyst can ask for loneliness by province, by gender, by income, with a threshold of 6 or 7, with or without the youngest respondents, and receive working code for each in minutes. Reporting the comparison with the most striking difference invites a false positive, because among many comparisons some will differ by chance alone. This is a form of selective reporting, and an untiring assistant makes it easier, often without any intention to mislead.

Gelman and Loken (2014) described a subtler version of the same problem, which they called the garden of forking paths. Every analysis involves choices about which respondents to exclude, how to code variables, which subgroups to compare and which cut-offs to use. If those choices are made after looking at the data, a different dataset could have led to different choices, so even a single analysis can produce a statistically significant result that does not reflect a real pattern. The authors stressed that this can happen without any conscious fishing through the data, through ordinary and well-intentioned judgement applied after the results are visible. Interactive 8.1 shows the simpler case of many analyses: in a world in which no real differences exist, it estimates how often at least one of several analyses crosses the conventional threshold of p < 0.05.

With one analysis per study, about 5 percent of studies report a false positive, which is the rate the threshold is designed to allow. With 5 independent analyses the expected share is 22.6 percent, with 10 it is 40.1 percent and with 20 it is 64.2 percent. Real analyses of the same data are usually correlated, which slows this rise, but the direction is the same. The simulation shows only the deliberate version of the problem; Gelman and Loken's point is that choices made after seeing the data inflate the error rate even when only one analysis is run.

A pre-specified analysis plan

The protection against both problems is a pre-specified analysis plan, a short document written and dated before the results are seen. It states the question, the data and the rules for including respondents, the definition of each variable (including how missing-value codes and scale scores are handled), the groups and thresholds, the statistics to be reported, any tests and how they will be interpreted, and how any departure from the plan will be reported. HSCI 410 Lesson 1 shows how to write the plan down, with a date, before modelling begins. A plan has two further uses in AI-assisted work. It can be pasted into the prompt, so that the assistant's code follows the plan, and the assistant can be asked to compare a finished script with the plan and list any differences.

Box 8.8 sets out Jordan's plan for the age-group analysis: the question, the data, the scoring rule, the statistics to be reported and the decision to run no tests.

Box 8.9 asks the reader to decide how Jordan should respond when the assistant offers to run many further comparisons.

Jordan's analysis now rests on a plan, a cleaned file, a table confirmed by a second method and two plots. Every step used only public, de-identified survey data described through a dictionary. Section 4 turns to the rules that apply when the data are confidential.

Before that, the reflection and knowledge check that follow review the four checks, the two silent errors and the case for a pre-specified analysis plan.

Jordan's analysis used a public, de-identified survey file and described it to the assistant through a data dictionary. Much of the analysis done in public health uses data of a different kind: clinic and program records, surveillance and laboratory data, linked administrative data and research data collected under consent. Personal and confidential data of this kind come with legal duties, consent terms and agreements that decide who may see them and where they may be stored, and those rules apply to AI tools as they apply to any other software. This section sets out the reasons behind the rules, the conditions that a research data platform attaches to access, the ways an analyst can still obtain AI help with code, and the principles that govern First Nations data.

Why identifiable and confidential data stay out of consumer AI services

Personal health information is information about an identifiable person's health or health care, such as a diagnosis, a clinic visit or a screening score linked to a name, a health number or a combination of details that points to one person. Confidential data include personal information of other kinds, research data collected under consent, data shared under an agreement and unpublished work belonging to others. Lesson 3 taught students to classify information before entering it into any tool. For analysis, the classification decides which kinds of AI assistance may be used, as Figure 8.5 summarizes.

Several reasons support the rule that identifiable and confidential data stay out of consumer AI services, and each applies even when the analyst means only to fix a line of code. The first concerns control: text and files entered into a consumer service are stored by the provider under its terms of service, which Lesson 3 showed can differ markedly from the terms of an institutional tool in how long inputs are kept and whether they may be reviewed or used to improve models. The second is legal. In British Columbia, the Freedom of Information and Protection of Privacy Act (FIPPA) governs personal information held by public bodies, including health authorities. Since amendments in 2021, a public body may disclose personal information for storage outside Canada only in accordance with the regulations, and a new program or system that stores sensitive personal information outside Canada requires a privacy impact assessment, an assessment that no individual's improvised use of a consumer chatbot has received. The third concerns consent and agreements: research participants agree to particular uses of their data by particular people, and ethics approvals and data agreements specify who may access the data and where. The fourth is that de-identified is not the same as anonymous. Removing names does not prevent identification when a combination of details, such as age, sex, community and a rare condition, points to one person, which is a particular risk in small rural communities such as many of those Cedar Valley serves.

Box 8.10 applies these reasons to the Cedar Valley pilot, both to Jordan's survey analysis and to a possible next analysis of the Connector program's own participant records.

The same reasons shape the conditions that research data platforms attach to access, and the next part describes them through the example of Population Data BC.

Research data platforms: the example of Population Data BC

Population Data BC (PopData) supports research access to linked administrative data in British Columbia, as HSCI 207 Lesson 1 explained. Its access process shows the conditions that research data platforms typically attach to sensitive data. According to PopData's guidance for researchers, research ethics and peer review must be completed before a data access request is submitted. Data stewards, the people or bodies responsible for each data source, review and approve or reject each request. The principal investigator and every team member who needs access must complete PopData's Privacy Training 101 for Researchers, and the team signs a research agreement and confidentiality pledges, with the data to be used only for the purpose requested. The analysis takes place inside PopData's secure research environment, which is reached only through an encrypted virtual private network with two-factor authentication; all imports into and exports from the environment are monitored, ethics approval must be kept current, and research materials must be submitted to the data stewards before public dissemination.

These conditions answer the question of AI use in practice. Record-level data cannot be moved from a secure environment into an outside AI service, since the agreement restricts their use and the platform monitors what leaves the environment. AI help with code therefore happens outside the environment, through the data dictionary and synthetic stand-ins, and the finished code is brought into the environment through the platform's own process. Unreleased output belongs under the same rules: an analyst who wants help interpreting a table should wait until the data stewards have approved its release, or describe its structure without its numbers. Any AI tool offered inside a secure environment by the platform itself is a different matter, governed by the platform's rules.

Keeping the records inside the secure environment still leaves several ways to obtain AI help with code, which the next part sets out.

Getting AI help without sharing the data

An analyst working with confidential data can still use an assistant for most of the coding work described in this lesson. The four approaches below can be combined, and all of them keep the records where the rules require them to be.

Worked code 8.11 builds the simplest kind of synthetic stand-in: six invented respondents with the real column names and answer codes, and values drawn at random.

set.seed(488)
fake <- data.frame(
  age           = sample(16:100, 6, replace = TRUE),
  gender        = sample(c("Man", "Woman", "Non-binary",
                           "Presented but no response"), 6, replace = TRUE),
  companionship = sample(c("Hardly Ever", "Some of the time", "Often",
                           "Presented but no response"), 6, replace = TRUE))
fake

  age                    gender             companionship
1  34                Non-binary Presented but no response
2  52                Non-binary Presented but no response
3  49                       Man                     Often
4  53 Presented but no response Presented but no response
5  54                Non-binary               Hardly Ever
6  38                       Man          Some of the time

Each of these approaches keeps confidential records where the rules require them to be. Data about First Nations communities carry further obligations, set out in the principles of OCAP®, which the next part describes.

OCAP® and First Nations data

The First Nations principles of OCAP® were established in 1998 by First Nations leadership, and OCAP® is a registered trademark of the First Nations Information Governance Centre (FNIGC). The four principles set out how First Nations data are to be collected, protected, used and shared. HSCI 207 Lessons 4 and 5 introduced them in the context of engagement and research ethics, and they apply with particular force to AI tools, which move data and derived information across organizational and national boundaries.

The four flip cards that follow describe the principles of ownership, control, access and possession.

In practice, an analyst who works with First Nations data under a data sharing agreement asks the community's data governance body, through the channels the agreement names, before using any AI tool in the analysis, including tools that receive only a description of the data. A data sharing agreement can address AI explicitly by stating whether AI tools may be used, which ones, with what kinds of data, and how the community will see the code and the results. The safe default for an analyst is to treat any AI use that the agreement does not mention as unapproved until the community has decided. Lesson 10 extends these ideas with the CARE Principles for Indigenous Data Governance and relates them to the commitments in the B.C. framework.

Box 8.11 asks the reader to classify five requests from a health authority's analytics team under rules like those of the Cedar Valley pilot.

Box 8.12 draws the lesson together. Table 8.5 sets out, for six tasks in data analysis and coding in R, how AI performs and the check that applies.

This section has set out why identifiable and confidential data stay out of consumer AI services, the conditions that research data platforms attach to access, the ways to obtain help with code without sharing the data, and the principles that govern First Nations data. The reflection and knowledge check that follow review these rules.

Bringing It All Together

This lesson followed one analysis from a data dictionary to a cleaned file, a descriptive table and two plots, with an AI assistant writing most of the R code and a student with no programming experience directing and checking it. The evidence on AI and programming speed showed why that division of labour matters. Gains are large on well-defined tasks of a familiar kind and can disappear when the user must review complex code, and people's sense of how much an assistant helped them is an unreliable guide.

The workflow kept every step small enough to read: describe the data through its dictionary, ask for one step and what to expect, run it, read the output, check it and save it. Two of the assistant's steps ran without any message and were wrong. A missing-value code was counted as an answer worth 4, and the age groups put 65-year-olds in the wrong group. A range check, a comparison with an independently computed score, a known-answer test and a look at the youngest and oldest age in each group found both errors, and the corrected code reproduced the survey team's own results exactly. A dated analysis plan then guarded against the easiest temptation that AI creates, which is to run many analyses and report the most favourable.

The same workflow carries over to confidential data with one change: the records stay where the rules require. Data dictionaries, synthetic stand-ins, approved institutional tools and local models give an analyst most of the benefit of AI help with code, while privacy law, data access agreements and the OCAP® principles decide where the data may go and who decides how they are used.

The final reflection asks you to bring the lesson's workflow and checks together for a public dataset and to adapt them for confidential records.

Final Knowledge Assessment

Key terms, tools and people from this lesson on using AI assistants to write, understand and check analyses in R.