I don’t start with perfect code. I start with momentum. Somewhere between cleaning 800,000-row datasets, reshaping SAF industry tables scattered across impossible Excel ranges, and arguing (again) with ggplot2 about Times New Roman, I realized something important about how I work now. I don’t code line by line anymore—I code in motion. I vibe code.
Not recklessly. Not carelessly. But conversationally, iteratively, and with enough intuition to let structure emerge instead of forcing it too early. That shift has quietly changed how I do research, how fast I move, and how much I actually enjoy the work.
Vibe coding isn’t about skipping fundamentals or lowering standards. It’s about how you arrive at rigor. Instead of waiting for a perfectly formed plan, I start with a rough idea and let the code help me think. I talk through problems as I write scripts, let plots and tables surface new questions, and refine continuously rather than freezing in the search for perfection. Coding becomes a thinking partner instead of a gatekeeper.
Most of my recent work—on sustainable aviation fuel, agrivoltaics, and economic impact analysis—never arrives clean. It shows up as massive Excel files with multiple tables buried in a single worksheet, AtJ, FT, and HEFA technologies split across awkward cell ranges, and column names that seem to change depending on who last touched the file. Old me would have overplanned. New me opens R and starts moving.
I’ll say something like: pull these three tables, label the technologies, stack them, and make the output manuscript-ready. We iterate. Ranges get corrected. Variables get renamed. The structure tightens. Slowly, the chaos resolves into a clean, tidy dataset that actually supports interpretation. That moment—when the data finally aligns with the research question—is the vibe.
The same thing happens with figures. If you’ve ever made plots for an economics journal, you know the aesthetic contract is strict. Fonts matter, and yes, it must be Times New Roman. Colors should be conservative, not decorative. Legends need intention, not default placement. Log scales need justification, not vibes. Ironically, vibe coding is how I get there.
I don’t start with the perfect figure. I start with a working one. Then the conversation begins. Break the x-axis by five. Fix the subtitle spacing. Give me journal-safe blue, orange, and green—and the hex codes for Excel. Each iteration nudges the plot closer to publication quality, not because I memorized every ggplot argument, but because I stayed engaged long enough for clarity to surface.
Vibe coding has also changed how I deal with things breaking, which they inevitably do. GitHub refuses to push because of LFS. R throws warnings about missing values during factor reordering. Packages fail mid-update for reasons known only to CRAN. Instead of panicking, the questions are calmer now. What’s actually blocking progress? Can I fix this surgically instead of burning everything down? Is this structural or just noise?
That mindset turns debugging into problem-solving instead of self-judgment. It keeps momentum alive.
The biggest shift, though, hasn’t been technical. It’s been emotional. Coding used to feel like an exam where you either knew the syntax or you didn’t, where errors felt personal and progress felt fragile. Now it feels like collaboration. I think out loud. I ask half-formed questions. I refine ideas while the code runs. That frees mental space for what actually matters in research: interpretation, economic intuition, policy relevance, and storytelling.
Let me be clear: vibe coding doesn’t replace rigor. The final outputs are still reproducible, transparent, clean, and ready for peer review. The difference is the path. I don’t force structure prematurely. I let it emerge. I don’t fight confusion—I work through it conversationally. That’s how complex, interdisciplinary research actually gets done.
I’ll keep vibe coding because modern research is cognitively heavy enough already. Because creativity and rigor are complements, not opposites. And because my best insights—about SAF industry impacts, agrivoltaics adoption, and spatial economic patterns—didn’t come from perfectly planned scripts. They came from momentum, iteration, and staying curious long enough to let the work talk back. I vibe code. And honestly, my research is better for it.
I’ve come to accept that my best work doesn’t emerge from perfectly planned scripts or immaculate first drafts. I don’t wait for perfect structure anymore. I build it as I move. It emerges from movement—trying, adjusting, listening to what the data and the code are telling me along the way. Vibe coding gives me permission to think in public with my tools, to let uncertainty be part of the process, and to arrive at rigor without burning myself out on the way there. honest accounting of how ideas actually form. That’s not laziness—that’s fluency. I let the data talk back, I let the code shape the questions, and I trust the process enough to stay in motion. In a research world that often rewards polish over process, choosing to work this way feels less like a shortcut and more like an That’s how rigor actually gets built in complex research. I vibe code, not because it’s easy, but because it works.
Leave your comments and suggestions.