There is a particular cry of despair reserved for the moment your R console turns red and says something annoyingly cryptic and full of symbols. You did not ask for this and yet here you are, at half past midnight, trying to decipher ideographs the way ancient priests once read the entrails of a goat, hoping the gods will explain themselves.

Good news: there is now a small robot whose entire purpose is to read the entrails for you. It’s called aideR, it lives in your RStudio toolbar, and this post covers what it does, how to install it, and two bugs that should be kept in mind when using it.

What is it, actually?

aideR is an RStudio Addin that:

1. Looks at whatever code you’ve selected in the editor
2. Quietly gathers a bit of context along with it
3. Sends all of that off to Google’s Gemini API with a task you pick from a menu
4. Delivers the answer straight back into your console

No copy-pasting your traceback into a browser tab. No re-explaining, for the fortieth time this term, what a data.frame is. It just knows, because you handed it the receipts.

Why this exists

A large chunk of teaching R statistics isn’t “here is the ANOVA function”. It’s “why has your ANOVA function just erupted in a language that suggests that R is doing this on purpose, possibly out of spite” Office hours are finite but error messages are not. aideR exists to narrow that gap a little.

That said, it’s worth being blunt about something since I’ve watched it happen several times. I’ve had students hand in work where the AI got the stats flat wrong and they had no way of knowing, because they’d never learned enough R or enough statistics to spot it. A tool that explains things well enough is also a tool convincing enough to be believed when it’s wrong. aideR is built to explain the code you’ve selected, not to replace the years of actually learning why a Type II error matters or when a mixed model is the wrong choice. You still need enough R in your own head to recognise when it’s talking nonsense, the same way you’d need to actually know French before you could catch a bad translation. If the only thing you ever do is ask, you’ll never build the skills to identify when the answer is wrong.

A quick word on the ethics of this, because someone will ask

I am not going to stand here and tell you that whether or not students should use AI is a settled question, because it isn’t. Anyone who tells you otherwise is generally trying to sell you something. There are real arguments worth taking seriously. Leaning on AI for explanations can quietly hollow out the productive struggle where actual learning lives. It can erode the skill of debugging your own thinking. It complicates what originality and authorship even mean once you hand in the assignment. And that’s just for starters.

I take all of that seriously. I also teach actual students in the actual year 2026, and of course they’re already using AI. Somewhere, someone is pasting error messages into whatever chat window happens to be open in another tab, with roughly the guidance and oversight of a toddler operating a forklift. Pretending otherwise doesn’t protect anyone’s learning, it just guarantees the only guidance they get is vibes and whatever the tool feels like improvising that day, with no one in the room who actually understands statistics to steer it.

So my position, as someone who has to stand up in front of a lecture theatre and mean it, is that if this is happening regardless (and it is, with the quiet inevitability of a Monday) then I’d rather it happen properly. That’s the entire idea behind aideR. It’s scoped narrowly to explaining code you’ve already selected and debugging errors you’ve already summoned, because that’s the moment a good explanation accelerates learning instead of replacing it. I’m trying to make sure that when students do reach for AI, that they’re reaching for something that shows its working and helps them develop.

And yes, about the Google of it all

The irony of a man who has spent aconsiderable amount of effort de-Googling his life - that’s me, by the way - turning around and building a teaching tool that phones home to the Gemini API on every single call is not lost on me. I have made my peace with it, in the manner of someone who has made peace with a disreputable relative. That is, reluctantly and with conditions attached.

The honest reasoning is that Gemini’s free tier is, as of writing as as far as I could discern, the most generous, most reliable, no-card-required option going, and “most generous and reliable” matters a lot when the people relying on it are students who have never set an environment variable in their lives and do not need a rate-limit error added to the pile of things going wrong at 11pm before a deadline. Principle is important. So is not making students debug a 429 on top of everything else.

But let’s be clear - this is exactly the sort of arrangement you should feel suspicious of. Not because anything sinister is afoot, but because “free” is a transaction, not a gift, and the terms are the terms whether or not anyone reads them or not. This means that anything sent through the free tier may be used by Google to improve its models and may be read by an actual human reviewer at some point. So keep the sensitive stuff off the free tier. Happily, call_gemini() also takes a model argument rather than being welded to one company’s API, so if you’d rather route it through Groq or OpenRouter instead (both with their own perfectly respectable free tiers, and rather fewer feelings about your search history) that’s a small function edit away, not a rewrite. Convenience got us here first. It doesn’t have to keep us here.

Installing aideR

# install.packages("remotes")
remotes::install_github("arcaravaggi/aideR")

First-time setup: getting your own free API key

Note the operative phrase: your own. aideR runs on Google’s Gemini API, which has a free tier but that quota is per key, which means if an entire class points itself at one shared key, you will exhaust the daily allowance somewhere around the third student’s first “please explain this for loop,” and the rest of the cohort will be left staring at a 429 error like a queue at a bakery that’s just sold its last cinnamon bun.

So, everyone gets their own:

library(aideR)
setup_gemini_key()

This pops open Google AI Studio, walks you through generating a key, and quietly tucks it away in your .Renviron.

Actually using the thing

Select some code that’s confusing you then either:

• Open Tools > Addins > Browse Addins, find “aideR Menu”, and click it like a civilised person, or
• Bind it to a keyboard shortcut once (see below) and never open that menu again as long as you live

You’ll get a small menu, politely waiting for instructions:

Select AI Task:

1: Explain (Beginner - no R experience)
2: Explain (Intermediate - code & stat reasoning)
3: Explain (Researcher - assumptions & limitations)
4: Why is this failing?
5: Fix this code
6: Add inline comments
7: What assumptions does this make?

Pick one, wait a couple of seconds, and the explanation lands straight in your console.

Setting a keyboard shortcut (do this now, not later)

RStudio, quite sensibly, does not let any package silently claim a keyboard shortcut the instant it’s installed. So this bit is manual, and it’s a one-time job:

1. Tools > Addins > Browse Addins…
2. Click Keyboard Shortcuts (top right)
3. Search “aideR Menu”
4. Click the shortcut field, press your combo of choice
5. Apply

After this, it’s select-code-then-mash-shortcut for the rest of your natural working life. Or the next couple of hours at least. Do it now; future-you will thank you. But then future-you will forget that this blog post exists, so do you really owe them anything? They’re just coasting on your hard work.

Two cautionary tales, in the grand tradition of cautionary tales

The case of the selection that wasn’t there

Early testing produced a baffling bug report: “I definitely selected code, and it still said ‘No codeselected!’”

The culprit, it turns out, was a very RStudio-specific bit of mischief. There are two different ways to ask RStudio “what document currently holds your attention”:

• getActiveDocumentContext() — whichever pane currently has focus, no questions asked, no loyalty to your intentions
• getSourceEditorContext() — the source file itself, regardless of where your cursor has wandered off to

If you select code in the editor, then click into the Console to actually type run_aider(), focus shifts to the Console the instant you click. By the time the addin runs, RStudio reports the Console as the “active document,” which, having no selection of its own, dutifully reports none, and your perfectly good highlighted code gets ignored entirely, like the instructions on a necessarily specific assessment brief.

The solution? Well, it should by all intents and purposes be part of the package. But I’d suggest mapping that shortcut and not clicking anything else once you’ve selected your code. If it doesn’t work then, it’s your fault. You could also log it as an issue on the repo too, I guess.

The vanishing model name

If you went digging through the package history (I cannot imagine why you would, nor how you would find it because I did all this locally with no version history) you’d find call_gemini() quietly swapping its default model string not once but twice in a single afternoon. Each swap returned a 404 error and its own small, private existential crisis.

This isn’t a bug in aideR so much as an occupational hazard of building on top of a fast-moving API. Google retires model names with a regularity that borders on a personality trait. So aideR now ships with:

list_gemini_models()

Run this the moment call_gemini() 404s on you and it will tell you exactly which model names your key currently has access to. You can then either edit the code yourself or log an issue for me to look into. Thank you in advance for that.

The whole toolkit

It might just work…

Install it, run setup_gemini_key(), select something baffling, and hit your new shortcut. If Google renames the model again next week (likely) list_gemini_models() has you covered.

Bug reports, feature requests, and “why did it explain my t-test using an extended pirate metaphor” reports are all welcome via GitHub Issues.

Update: For restricted networks and overly zealous IT departments

Not every computer plays nicely with remotes::install_github(). If you are working on a locked-down institutional machine, operating behind a corporate firewall with the trust settings of a toddler guarding a half-eaten biscuit, or simply disconnected from the internet, here is how to get around the most common hurdles.

Option 1: Installing from a local zip file

If your network refuses to fetch packages directly from GitHub, you can manually download the repository as a .zip file, save it locally, and tell R to build it from your drive:

install.packages("C:/path/to/yourpackage-main.zip", type = "source")

This bypasses remote fetching entirely by pointing R directly to the archive on your local file system.

Option 2: Bypassing installation entirely

If your institution’s IT permissions are set up to prevent you from writing anything into R’s system library (a setting presumably designed by someone who regards user autonomy as a serious security risk) you can skip the installation step altogether using devtools or pkgload:

devtools::load_all("C:/path/to/yourpackage-main")

# Alternatively
pkgload::load_all("C:/path/to/yourpackage-main")

Unzip the repository folder somewhere on your machine, point either of those functions at the folder path, and R will load all the package’s functions directly into memory for your active session. You will need to run this command each time you start RStudio, but it completely sidesteps administrator restriction errors.