Some Thoughts on Vibecoding for UXR: Improving Project Execution Workflow with Disposable Microtools

Everyone's talking about vibecoding. If you've missed the discourse (lucky you), the idea is simple: you describe what you want to an AI coding assistant, it writes the code, you run it, and if it works, you move on without necessarily understanding every line. The term comes from Andrej Karpathy, and depending on who you ask it's either the future of software development or the end of civilization.

Most of the conversation around vibecoding has focused on developers. Software engineers building apps. Startup founders prototyping products. People whose job title already includes the word "code." But there's a version of this that's quietly relevant to UX researchers, and nobody's really talking about it.

This article isn't a tutorial on how to vibecode. There are plenty of resources for that already. Andrej Karpathy's original post that coined the term is a good starting point. The awesome-vibe-coding repo on GitHub is a solid curated list of tools, guides, and references. If you want to get your hands dirty, tools like Claude Code, Cursor, and Replit all have their own onboarding docs. What I want to talk about is something more specific: why this approach matters for UX researchers, and how disposable microtools can change the way you execute projects.

Not the "AI replaces your research" version. Not the synthetic persona version. Not the automated interview version. Those conversations are happening elsewhere, loudly, and I've written about them before. I'm talking about something much more boring and much more useful: using AI-assisted coding to build small, throwaway tools that smooth out the friction in your project execution workflow.

I've been doing this for a while now and it's changed how I work in ways I didn't expect. So here are some thoughts.

The Friction Problem Nobody Built Tools For

Here's something about UX research that makes it weird from a tooling perspective: no two workflows look the same.

A researcher running diary studies has completely different data wrangling needs than one doing moderated usability sessions. Someone doing survey research lives in a different universe than someone doing field ethnography. The researcher working on enterprise B2B has different data shapes, different stakeholders, different deliverables, and different timelines than someone on a consumer mobile app. But it goes deeper than method and domain. Even within the same team, studying the same product, two researchers will run different projects with different designs, different data sources, and different output needs. The workflow that works perfectly for one study falls apart on the next one because the research question changed, the data shape changed, or the stakeholder needs something different this time. Every project is its own little snowflake of operational requirements.

The research tooling market has responded to this by going broad. Platforms cover the common denominator: recruitment, scheduling, transcription, data capturing, maybe some analysis features. And for the things they cover, they're fine. But the common denominator isn't where the friction lives.

The friction lives in the specific, contextual, situational stuff. The part where your particular workflow hits a wall because no product manager at a research SaaS company sat in a room and said "you know what we need? A feature that searches twenty interview transcripts for every mention of a specific concept, pulls the surrounding context, tags it with the participant's segment, and outputs it as a table you can drop into a synthesis doc." That feature doesn't exist as a feature. It's too specific. Too contextual. But that doesn't make it unimportant. It just means the gap has to be filled some other way.

For years, the options were: do it manually, find some workaround, or just don't do it. That third option is the one nobody admits to. How many times have you manually copy-pasted quotes from transcripts into a spreadsheet because there was no faster way to organize them? How many times did you skip cleaning up a messy dataset and just worked around the formatting issues because fixing it properly wasn't worth the hour? How many times did you think "there has to be a better way" and then just powered through the tedious way because the alternative was learning a new tool that would take longer than just doing the thing?

Vibecoding offers a fourth option: build the exact tool you need, right now, in fifteen minutes.

What I Mean by Disposable Microtools

A microtool is a small script that does one job, runs a handful of times, and then gets archived or deleted. It is not a product. It's not going on a roadmap. Nobody is writing a PRD for it. It exists because you hit a friction point in your project execution, you addressed it, and now you move on.

Narrow scope. Clear inputs and outputs. Minimal interface, usually just the command line or a single function. Optimized for getting to value fast, not for elegance or maintainability. And critically: designed to be thrown away.

That last part is what makes this work. We've been trained to think that code should be documented, tested, maintainable, built to last. For production software, yes. But a microtool isn't production software. It's a wrench you grabbed to loosen one bolt. You don't need to engrave your name on it.

The disposable part prevents the over-engineering trap that kills momentum. You know the trap. You start writing a "quick script" and two hours later you're debating folder structures and building a config file for something you'll use twice. Disposable means you give yourself permission to be scrappy. Build it, use it, park it, move on. Research questions change week to week. Your tooling should be able to keep up.

How This Actually Works in Practice

I'll walk through a few real examples from my own work. Not to say "do what I do" but to make this concrete. Your friction points will be different. Your tools will be different. That's the entire idea.

Extracting screenshots from participant workflows. I needed to pull screenshots captured at specific intervals from participant workflow recordings for further analysis. Dozens of participants, multiple screenshots per session, each one needing to be labeled with the participant ID, the task, and the timestamp. The manual approach: open each recording, scrub to the right moment, screenshot, save, rename, repeat until your eyes glaze over and you start mislabeling things. Instead I described what I needed to an AI coding assistant, got a Python script that extracts frames at the specified intervals, names them with the relevant metadata, and generates an index file. Fifteen minutes. A task that would have eaten most of a day became a single command.

Structuring open-ended responses for coding. I had a few hundred open-ended survey responses that needed to be prepped for qualitative coding. The export was a mess: inconsistent line breaks, responses split across multiple columns for no apparent reason, Unicode characters masquerading as regular punctuation, and participant metadata in a completely different file that needed to be joined in. Before I could even start reading the responses, I needed an hour of spreadsheet surgery. I wrote a script that cleans the text, joins in the metadata, standardizes the format, and outputs a single file ready for coding. The prep step that used to eat the first morning of every survey analysis now takes thirty seconds.

Merging participant data with behavioral telemetry. I needed to take my participant list from a study and match each person against their actual product behavior from our telemetry exports. Which features did they use before the session? How often? What was their activity pattern in the two weeks prior? The telemetry export used different identifiers than the research tracker, the timestamps needed to be converted, and I needed to segment participants based on behavioral flags so I could compare what people said in interviews against what they actually did in the product. Doing this manually means hours of VLOOKUP hell across mismatched spreadsheets, praying that your ID matching didn't silently drop anyone. I built a script that takes both files, matches participants across identifier formats, pulls the relevant behavioral metrics, applies the segmentation flags, and outputs a single merged file ready for analysis. Twenty minutes. What used to be a painful half-day of spreadsheet wrangling became a single command, and I could actually trust the output because the script logged every match and flagged every participant it couldn't reconcile.

Interactive visualizations for modeling and simulation. This is the one that's changed my work the most. Dashboards answer the questions someone anticipated when they built them. They almost never answer the question you actually have today, and they definitely can't model what happens next. I've been building interactive visualizations that let you adjust variables and watch the effects in real time. For a recent project I built a mathematical model based on a set of behavioral and business variables, then wrapped it in an interactive tool where stakeholders could move the sliders themselves: what happens if we change this threshold? What if this segment behaves differently? What does the impact look like if adoption hits 20% versus 40%? Instead of presenting a static chart and hoping people trusted my assumptions, I handed them a tool that let them pressure-test the assumptions live. The readout went from "here's what I think will happen" to "let me show you what the model says happens as these variables shift." Stakeholders stopped debating whether the analysis was right and started debating which scenario to plan for. That's a fundamentally different conversation.

Data cleaning and wrangling. Normalizing messy text fields. Deduplicating records. Converting timestamps from whatever format the analytics platform decided on into something readable. Merging datasets that share a key column but disagree about everything else. Each one is a quick tool that prevents an hour of spreadsheet work and, more importantly, prevents the errors that come from doing fiddly data manipulation by hand.

None of these are problems worth building "real tooling" for. They're too specific, too temporary, too tied to the context of one project. But they're also too time-consuming to keep doing manually. Microtools sit in that gap.

The Process I've Settled Into

This has become a routine for me. Not a framework, not a methodology. A routine.

Name the friction in one sentence. What's slow, error-prone, or annoying right now? If you can't say it in one sentence, you're probably trying to solve too many things at once. "I need all images from this deck with slide references." One sentence. One tool.

Define what goes in and what comes out. A PDF goes in. A folder of named images and an index CSV come out. That's the contract.

Time-box it. If it won't be useful within an hour, shrink the scope. You are not building a product. You are clearing a bottleneck so you can get back to the actual work.

Vibecode it, but steer. Give the AI a small example input and the expected output. Flag the edge cases you know about. Ask for error handling and logging. The more specific your description, the less cleanup afterward. "Vibecoding" doesn't mean "accept whatever the model produces without thinking." It means you focus on intent and validation while the AI handles the boilerplate.

Validate like a researcher. Run it on a small sample. Spot-check results by hand. Add at least one integrity check: a row count, a total that should match, a random sample you verify manually. You do not need a test suite. You need confidence that the tool isn't silently eating your data or introducing errors. This is the step where your research training actually matters. We know how to check things. Apply that here.

Save it or trash it. If it works, park it with a one-line README. If not, delete it. You spent an hour or less. That's a meeting. You've wasted more time on meetings that could have been Slack messages.

Staying Honest About the Risks

Scrappy doesn't mean reckless. A few guardrails I've learned to keep in place.

Correctness over cleverness. Every microtool I write is boring on purpose. If I can't read it and immediately see what it does, I rewrite it. This is research infrastructure, however temporary. Nobody gets points for elegant code that produces wrong results.

Data integrity checks are not optional. I have a PhD, I am quite technical, and over thirteen years of experience and I still don't trust code I wrote twenty minutes ago. Counts before and after transformations. Totals that should be preserved. Random samples verified by hand. Every time.

Reproducibility basics. Save the inputs. Log the parameters. Note which libraries you used. Not because this is going into production, but because future you will open this folder in three months wondering what happened.

Privacy is non-negotiable. Keep raw data local. Don't paste participant quotes or PII into prompts. Use synthetic examples when generating code. If it touches anything sensitive, it runs on your machine. This is basic research ethics, and the fact that vibecoding makes things fast doesn't mean it makes privacy optional.

Watch for tool drift. If you're reusing a microtool more than a few times, it's not a microtool anymore. Either harden it into something real (error handling, documentation, tests) or admit you've built infrastructure. The worst outcome is a critical workflow dependency held together with duct tape and a variable called thing2.

Why This Matters Beyond Saving Time

The time savings are real, but the more interesting thing is what happens to your work when friction drops.

When prep cost goes down, you iterate more. You do the extra segmentation cut. You run the sensitivity analysis you would have skipped. You triangulate from a second data source instead of hoping the first one tells the full story. You explore questions that previously weren't worth the setup cost. The threshold for "is this worth looking into?" drops, and you start asking better questions because the cost of exploring them approaches zero.

For UXR project execution specifically, four things shift.

The gap between signal and decision gets smaller. Less time wrangling data into shape means more time thinking about what it means. The thinking is the job. Everything else is overhead, and microtools shrink the overhead.

Mixed methods gets smoother. Qualitative artifacts like recordings, images, and field notes become structured inputs faster. Qual findings actually make it into the same conversation as quant findings instead of arriving a week late with a "sorry, transcripts took a while" caveat.

Research velocity goes up in ways that compound. When you can go from raw data to a usable format in minutes instead of hours, you don't just do the same work faster. You do more passes. You check one more segment. You run the comparison you would have cut for time. You pull in a second data source to triangulate instead of relying on one and hoping it tells the whole story. Each project gets a little more thorough, a little more rigorous, and the cumulative effect over a quarter is that your team is making decisions on substantially better evidence than they were before.

And you can audit analytics instead of accepting them. When you can quickly pull raw data, transform it, and build your own view, you stop being dependent on whatever someone decided was important when they configured the dashboard six months ago. You can check things yourself. For a discipline built on rigor, that matters.

Your Move

Pick one thing in your project execution workflow that makes you sigh every time it comes up. The manual step. The format conversion. The "there has to be a better way" task that you've been doing the tedious way for months.

Build a microtool. Time-box it to an hour. Validate it with a couple of checks. Save it or trash it.

Then pay attention to what happens next time a similar friction point appears. Your first instinct won't be "I'll just power through it." It'll be "I can build something for that."

That shift in instinct is worth more than any individual tool.

👉 Subscribe for weekly essays on UX research, workflow, and the occasional rant dressed up as practical advice.