I used to believe research had a speed limit. Not because the questions weren’t interesting or the ideas weren’t there (at least that is what I tell myself), but because there was always a practical ceiling imposed by the technical work required to turn curiosity into evidence. Before you could test a hypothesis, you had to clear a familiar obstacle course: find the right data source, figure out how to access it, learn the format, write the pipeline, debug it, clean the mess, and only then begin the analysis. Over time, I internalized that obstacle course as normal. I treated it as the cost of doing serious work.
During my PhD, that reality hit hardest with a problem that sounded simple if you said it quickly: use NASA weather satellites to get the data we need. “NASA weather satellites” isn’t a dataset; it’s a universe. It’s missions and instruments and product levels and tradeoffs: spatial resolution, temporal resolution, calibration, coverage, quality flags, file formats, distribution systems. Even choosing the right satellite and the right product is its own research project, because the details matter and the wrong choice can quietly derail everything downstream.
After selection comes access, and access is never just “download the data.” It’s different archives and interfaces, sometimes authentication, sometimes rate limits, sometimes thousands of files whose naming conventions only start to make sense after you’ve broken a few scripts. And then comes the part that consumes your time: cleaning. Aligning timestamps, interpreting coordinate grids, resampling, masking, stitching, decoding metadata, handling missing values, figuring out what “correct” even looks like. That entire process took me something like two weeks to do properly, not because I was slow, but because understanding and implementation were entangled. You don’t just write code; you build a mental model of the system while you’re building the pipeline. By the end, I knew more acronyms than any sane human should be allowed to know without a security clearance.
That experience shaped how I approached research for years. I didn’t always notice it happening, but I began filtering my curiosity through feasibility. I’d have an idea, and immediately a second voice would arrive to negotiate with it: do I really want to spend a week just getting the data? Is this going to turn into an engineering project? Do I have the time to learn one more ecosystem? Those are rational questions, but they also narrow your range. They push you toward what’s easiest to implement, not necessarily what’s most interesting to ask.
That’s the backdrop for an experiment I’ve been running recently, and it still feels a little unreal: I’m writing a paper as a side project without coding myself. I’m doing it entirely through Codex. I still design the analysis, decide what matters, and validate what comes out, but I delegate the implementation layer. I describe the goal, the constraints, the data shape I need, and the checks that would convince me the output is sound, and then I iterate from there like I would with a collaborator.
When this experiment required something eerily similar to my old NASA problem, choose the right remote-sensing product, access it, download it, clean it, and produce something analysis-ready, I braced for the usual time sink. In the past, I would have budgeted days, maybe a week, just to get to a stable pipeline. This time, I opened Codex, wrote out what I needed in plain language, and walked away to make coffee. The coffee took longer than the first draft of the pipeline, which is not a sentence I expected to write in my lifetime.
When I came back, the pipeline existed!!!
Not a vague outline. A real path from question to dataset, with a rationale for the product choice, automated retrieval, and cleaning steps structured clearly enough that I could inspect and audit them. I still reviewed everything. I still asked follow-ups. I still sanity-checked assumptions. But the two-week problem had collapsed into a morning task, and that was the moment it clicked: this wasn’t only about speed. It was about what becomes possible when the friction between intention and execution gets dramatically smaller.
The biggest change is that technical limitations no longer define the shape of my research. The work shifts away from typing and toward specifying, being precise about what you mean, what you want, and what would count as correct. Debugging moves up a level too: less time debugging syntax, more time debugging assumptions. And because the cost of trying things drops, you try more things. You take bigger swings. You explore more ambitious data sources and workflows without needing the project to become your entire life.
Codex didn’t make research easy. It made it less bottlenecked by plumbing. It compressed the parts that are mostly friction, like setup, boilerplate, and format wrangling, and created more space for the parts that matter: choosing the right questions, designing good tests, validating carefully, and communicating clearly.
If there’s one sentence that captures what changed, it’s this: Codex didn’t just help me move faster. It changed what I believe is feasible in a day.