AI for Research

There is a project from my PhD that is very dear to me. MIDES, a tool I spent the better part of two or three years building in Scala. The algorithm at its core was not the hard part. What took all that time was the foundations — getting the structure right, figuring out the data model, the class hierarchies, building the scaffolding before I could even get to the thing I actually cared about. By the time the interesting work began, so much of the energy had already gone into just preparing the ground. And even then, with everything I put into it, I look back now and see the places where the design could have been better, the output better optimized, if I had spent less time fighting the language and more time thinking about the problem.

Though I was always interested in coding, I never formally learnt programming. I took up Electronics in my bachelor’s, designing PCBs, frying capacitors, programming microcontrollers, tinkering at the edge where hardware and software blur. At one point, I had perfected the process for printing PCBs with a home laserjet printer and copper sulfate solution, iterating 7 designs in a day. Then, as a master’s student, I went into mechatronics, hoping to blend my knowledge of electronics with the physical world. Here, most of the coding was in MATLAB, which is really just math written fancily. The focus was always on the math. The code was almost a formality. I did take part in Chalmers Formula Student and Carolocup, which were cool projects where I put my electronics and embedded software skills to use. Then, formal methods in my PhD, more specifically supervisory control, which was more rigorous with math and less computational. That is where I built the MIDES tool. I was never bad at reading code. I could look at a codebase, understand what it was doing, identify patterns, and know what kind of solution a situation called for. Having worked for a year as a backend software developer at Nokia did help. But when producing code from scratch, I always got stuck on the project structure, the right data structures, and the boilerplate.

I tried AI-assisted programming. The first real test was ScenarioDB, a tool for storing, searching, and retrieving test scenarios. I know nothing about JavaScript, nothing about UI/UX, nothing about the modern frontend ecosystem. None of that mattered. I knew what I wanted the thing to do. I could read what the AI produced, run it, identify where it went wrong, and redirect it. A few sessions of back-and-forth later, I had something functional, something I could actually use. So my main bottleneck in setting up the base project and the correct data structures was almost nonexistent.

There is guilt in this, though. I won’t pretend otherwise. Things move fast— sometimes too fast. Code accumulates that you haven’t fully traced through, and there is a feeling that you have skipped something you were supposed to learn. When a chunk of logic appears and solves your problem in one exchange, it can be hard to say with real confidence that you understand why it works, not just that it does. For production software, this would worry me more than it does. I am not the person who has to maintain this or debug when something breaks in deployment. But I notice the feeling anyway. A kind of unease at how much ground gets covered before I’ve had the chance to understand and internalize it.

For research, though, where what you need is to test a hypothesis, get quick feedback, prototype rapidly, and iterate, the trade-off feels different; it’s more like a boon. The focus can stay where it belongs: on the core algorithm, the experiment, and the question you’re trying to answer. You don’t need to put in extra effort to set up and maintain the boilerplate. In that sense, it is a net positive, and I think I am honest enough with myself to say I wouldn’t have gotten ScenarioDB built at all without it. Not in any reasonable time.

I have come to see AI for research prototypes as overseeing several very capable students. You set the direction for them, you read their output, you guide them toward what you need. Your domain knowledge, your research instinct, your ability to work across different fields. You let these students implement and come back with results. Your task is to review the results and update the hypothesis/experiments. The parts of the work that required skills you lacked don’t become a bottleneck. In my case, programming the frontend and spending time solving for the good.

However, real students surprise you. They can push back in ways that make you rethink the problem. Some of them are lazy and figure out interesting ways to solve the problem. They get interested in something you hadn’t noticed, pull out a thread you would have taken for granted. They go on to do their own work and become the next generation within the field. An AI assistant does none of this. It executes. It does not grow, does not carry the problem home with it, does not show up the next week having thought of something new. And I wonder sometimes what is lost when the friction of learning—like my years of wrestling with Scala, or perfecting my PCB designing workflow–gets bypassed all at once. Not just for researchers like me who came to programming sideways, but for everyone, including the people who might have become very good at it given the chance to struggle through.

I don’t have a clean answer to that. What I know is that I am at a point where the tools that were just slightly out of reach are now within reach. The gap between having a hypothesis and testing it is much shorter than it used to be. Something shifted when I could finally move as fast as I could think. Whether that is a crutch or what progress looks like, I am still figuring it out.