I want to be honest with you from the start: I don’t know if what I did was the right call. What I can tell you is that I tried something, watched a cohort of undergraduate psychology students work through it, and came away with more questions than answers. This post is an invitation to think alongside me, not a prescription for how to run your course.

The assignment was called “Vibe Coding.” The students had to build a working, full-stack reaction time experiment from scratch, using generative AI (specifically Google Gemini) as their primary tool. No prerequisite coding experience. Just natural language, a browser, and a lot of trial and error.

The experiment itself was technically sophisticated: a 10-trial task where participants click a stimulus circle, with data logged in real time to a Google Sheet and results displayed as a histogram compared against community data. Frontend in HTML and JavaScript. Backend in Google Apps Script. Hosted on GitHub Pages. Students who had never written a single line of code were being asked to orchestrate all of it, using AI as the engine.

“The project would have taken weeks without AI assistance.” — student reflection

Was I asking too much? Maybe. But the rationale was direct: behavioral researchers increasingly need to design and deploy digital experiments. Platforms like jsPsych, Gorilla, and Pavlovia have lowered the barrier considerably, but they still assume a certain fluency. What happens if the barrier drops all the way to zero, and the only skill required is the ability to communicate clearly?

What actually happened

The range of experiences was striking. Some students reported smooth, almost frictionless workflows. Others hit walls that felt completely intractable. One student described the process as “daunting and frustrating.” Another called it “the magic of a working tool.” Both descriptions referred to the same assignment.

The technical failures were instructive. The most common bugs had almost nothing to do with code logic. They were about the connective tissue between systems: a file named experiment.html instead of index.html causing a 404 error on GitHub Pages. A Google Apps Script left on the default permissions instead of deployed as “Anyone.” A Mac’s TextEdit app quietly saving code in rich text format, causing the browser to render it as literal characters on the screen.

“One issue I ran into was when I wanted my website to be pink and cute. To differentiate it from the old boring one, I did cute.index.html — which I found out was my first problem.” — student reflection

These failures might look trivial, but they are pedagogically significant. Each one required the student to develop what I’d call technical intuition: an understanding that naming conventions, file formats, and deployment settings are not flexible, even when the code itself is generated for you. The AI writes the logic. The human still has to provide the correct container for that logic to live in.

Five things the students taught me

The students who struggled most with prompting tended to treat Gemini like a vending machine: insert general description, receive working app. The students who succeeded treated it more like a collaborator who takes instructions extremely literally. Asking for a “welcome screen” as a discrete prompt, then separately asking for a “trial loop,” then for “data export” — that modular approach consistently produced better results than describing the whole system at once.

One student discovered something counterintuitive about the debugging process: being “overly nice” — saying please, saying the errors were not a problem — seemed to help the AI resolve a stubborn histogram issue that direct technical prompts had failed to fix. The more plausible explanation is not that the AI responded to politeness, but that slowing down and being more patient forced the student to describe the problem more precisely. Either way, the lesson held: a collaborative, iterative tone tends to outperform a demanding one.

The most powerful debugging tool, it turned out, wasn’t a cleverly worded prompt at all. It was a screenshot. Several students found that verbal descriptions of what was going wrong failed completely, while a single screenshot of the error allowed the AI to immediately diagnose the issue. This has real implications for how we teach students to interact with these tools.

The question I keep coming back to

Critics of AI-assisted coding worry, reasonably, that students are bypassing the learning that comes from wrestling with syntax. I think that concern is worth taking seriously. But what I observed in this assignment was something different from bypassing. Students were learning concepts — batch processing, CORS restrictions, asynchronous requests, API endpoints — not by studying them in a textbook, but by hitting them as obstacles at midnight and having to resolve them. One student described the process as “high-speed immersion.” That framing stuck with me.

The deeper question for our field specifically is this: what does it mean to design a behavioral experiment? Is the skill in the coding, or is it in the understanding of what you are measuring and why? If AI can handle the former, does that free researchers to focus more deeply on the latter — or does it erode something important about the process?

“AI use and learning are not mutually exclusive.” — student reflection

I don’t have a settled answer. What I do believe is that the question is worth asking seriously in our curriculum design conversations — not after the tools have already reshaped the landscape, but now, while we still have agency over the pedagogical choices.

An open invitation

If you have tried something similar in your course, or if you are thinking about it and want to talk through the tradeoffs, I would genuinely welcome the conversation. This was one attempt, at one institution, in one semester. The students surprised me — mostly in good ways. I suspect they would surprise you too.

* This post draws on student reflections and technical briefings from PSYCH 505: Learning and Decision-Making (A Neuroscience Perspective), Spring 2026. The thoughts are mine and the writing is Claude’s.