The Loop Gets Shorter

The idea loop used to look completely different for me. Having an idea meant sitting with it long enough to plan five or ten steps ahead looking at the second- and third-order impacts, what the experiment actually needed to prove, what could go wrong before a single line of it existed. Then, often, finding a thesis student, explaining the hypothesis and the material behind it, and spending months collaborating with and supervising them while they built the thing and tried to validate it. A year, sometimes two, from idea to result, and a good chunk of that year was someone else’s labor, not just mine.

Now, once I have the idea articulated and enough material to actually explain it to the AI (the hypothesis, the findings so far, what I’m testing), it can churn out the code for the experiment. A couple of days, a week at the max, and there’s something functioning. A few more rounds after that to weed out the outliers, and there’s a full experiment with results in hand. If something about the original framing was wrong, which it usually is a little, iterating on that is just as fast. The whole loop compresses, start to finish. There’s a piece by the ZBook, on the biggest mistake engineers make, that gets at why this matters beyond just speed: “encourage engineers to get something end to end launched internally as quickly as possible,” because that’s what actually shows you whether the idea holds up, not another round of planning on paper. Tomas Stropus makes the same point in “The Art of Finishing”: “Instead of aiming for perfection, I’ll aim for ‘good enough.’ I’ll get a basic version working and out into the world. I can always iterate and improve later.” Once we have that tool working, running experiments and iterating on the results is rather straightforward. Which then makes it easy to test new ideas quickly and efficiently.

Programming is a tool, what makes it interesting to me was never the syntax. The fun was in solving the problems at hand. Learning a language deeply enough to understand what’s happening under the hood always felt like a separate skill from the one I actually cared about. I have previously in a reflection on my robotics journey spoken about how I came to programming. Scala is the only language I went deep into, and it took a couple of years. The only reason I grasped it was by sitting through a course taught by Odersky himself. Programming has been a core part of my work, but not the language and its internals, they were just a choice. I would choose a language depending on my interest to try it out, or if i wanted some specific feature that was particular to that language.

These days I work with AI agents to write code. This hardly requires me to invest in learning, in depth, languages and frameworks. I can focus on getting a highlevel overview of the framework and evaluating if it fits my needs, before getting into the details. Then, I can review what comes out to a fair extent, suffcinet to catch what’s wrong, without having to write it myself from scratch. And that’s the balance, I’ve given up depth in exchange for range.

Coding isn’t solved. It won’t be, not in any way that lets a whole profession relax. But the need for merely good coders, the kind who can implement a spec cleanly and ship it, that need is thinning out fast. What’s left standing is the need for excellent ones, the people who can still out-reason the machine on the hard 10% problems, create uniques designs and efficient solutions. That was not what I was after. For people like me, where code was always in service of an idea rather than the point of the work, this shift towards AI feels less like a threat and more like permission. For me as a researcher that distinction is not really important. I am more interested in the core idea or hypothesis. Code is just a tool I would then use to validate them.

There’s an old paper, Lisanne Bainbridge’s “Ironies of Automation,” from 1983 and how well the paper has aged. Her point was about factories and cockpits: automate the routine parts of a job and you don’t remove the human, you leave them holding only the rare, hard cases, the ones the automation couldn’t handle, while quietly stripping away the daily practice that used to keep them sharp enough to catch those cases. That’s the part of this I actually worry about. My Scala instincts are real because I put in the two years. The languages I now only review, I never built that muscle for. Somewhere in a stack I didn’t sweat over there is probably something subtly wrong that I will not catch, precisely because I skipped the part that would have taught me to see it. rrwright’s “Rotating the Bar” makes almost the same argument from the other end – that AI is collapsing the old junior/senior ladder, and that almost everyone, regardless of tenure, is starting over as a kind of junior again. The excellent coders, the ones I said I was never trying to be, are exactly the ones who’d catch what I won’t.

There’s a parallel to something happening now with speech and text. People are dictating instead of typing. Talking isn’t inherently better; it’s that typing forces a stop, a small mechanical decision about how to get the thought onto the screen, and that stop is exactly where a chain of thought breaks. David Perell put it well: “Speaking is the first draft of thought… Saying something out loud gives me an initial structure that I can refine in subsequent drafts.” He goes further: “Speaking out loud doesn’t let you stop. You can only move forward.” Some people type as fast as they think and never feel the friction. Others feel it every time. AI coding is doing something similar for me. Writing the code itself was never where my thinking happened. It often interrupted my thinking process breaking my chain of thought. I had to stop and translate an idea into a syntax, or think about what data structures to come up with. That wasn’t native to how I thought. Now I let the AI handle that translation and just stay with the idea, the way dictation lets you stay in the sentence instead of stalling over a keyboard.

Code becomes a means to that faster loop now, rarely is it worth spending time and effort to getting good code.

My hypothesis now is that we have started moving to another abstraction level where ideas become more central. Assembly gave way to high-level languages; high-level languages gave way to frameworks that hide most of the plumbing underneath. Code itself might be turning into the next layer we stop having to touch directly. What sits above is ideas, and that’s a big boon for someone like me. I’m not a great programmer, but I can now use the same tools as a sufficiently good one. That distance between having an idea and testing it, iterating till it works, just got shorter; that for me as a researcher, is where the real work is.