From Two Months to Three Minutes and Forty-Four Seconds: The Access Threshold Between an Idea and Its Realization

I code in R.

Some people may roll their eyes and say that R is not “programming” in the strictest sense of the word. Fair enough. Call it scripting, data analysis, applied bioinformatics, computational statistics. But in the end, it is still code: you write instructions, build functions, organize data, fix errors, and try to make a machine do something that, until a moment before, existed only in your head.

And I have spent a lot of time with R.

During my PhD, I was practically glued to my computer. I had to understand bioinformatics, learn how to handle data, build scripts, make mistakes, fix them, and start again. R was incredibly useful to me. Not only to produce analyses, but above all to learn how to think in a structured way. Because code, even when it is ugly, forces you to clarify your thinking. If you cannot explain to a machine what you want to do, chances are you have not really understood it yourself yet.

But then life changes.

Today I have a different job. R is still useful to me, but it is no longer the center of my work. It has become a utility. A tool. A lever. Not something I can afford to spend weeks on every time I have an idea.

And that is exactly the problem: ideas keep coming.

You think of a useful script, a more elegant pipeline, a system to automate an analysis, a better way to visualize data, a procedure that could save everyone time. Then you do the math and realize that, to develop it properly, you would need at least two months of almost constant work.

Two months you do not have.

Not because the idea is useless. Not because it is not valid. Not because the company would not benefit from it. Simply because there are other priorities, other urgencies, other responsibilities. And so many ideas remain stuck there, halfway between “this would be useful” and “I do not have time to build it.”

Then LLMs arrived.

ChatGPT, Claude, Gemini, and the rest. At first, I used them like many people did: to ask questions, translate, polish texts, clarify concepts. Then, one evening in 2023, I tried something different: I described to an AI the script I wanted to build.

I did not ask it for a line of code.

I explained the problem.

I told it what data I had, what analyses I wanted to obtain, what plots I needed, and what outputs I expected.

In practice, I did what today is called vibe coding: not starting from the code, but from the intention. Not writing the solution immediately, but clearly describing the desired result, adjusting the direction, having a dialogue, testing, going back into the code, asking for changes, breaking something, fixing it, and trying again.

The first result was not perfect.

There were errors, parts to fix, things that did not work the way I wanted. But the interesting thing was something else: the work had started. I was no longer staring at a blank page. I had a structure, a foundation, a tireless interlocutor to iterate with — one that stole my nights because I turned out to be even more tireless than it was.

After about 18–20 hours of intense work, through a tight back-and-forth with the AI, I came out with a working script. Not a toy. A real script. Useful, solid enough to produce results that I later presented in the company. And with decent success.

That same thing, done by myself, would probably have taken me a couple of months.

With AI, I brought it home in less than one real working day.

That alone was impressive to me.

Then something even more interesting happened.

About a year later, I went back to that script. In the meantime, I had learned new things — also through vibe learning — I had understood better what I wanted to obtain, and new needs had emerged. Instead of modifying the old code piece by piece, I decided to start from scratch.

I described again to the AI what I wanted.

This time I was more precise. I knew better how to formulate the request. I knew which mistakes to avoid. I knew which outputs to ask for. I knew how the AI thinks and how to guide it.

The result: in 3 minutes and 44 seconds, it generated the script directly.

I tested it.

It worked.

End of story.

And this, I think, is where the point really becomes clear.

It is not just that AI writes code. It is not just that it saves time. It is not even the usual lazy line: “AI will do the work for us.”

No.

The point is that it changes the access threshold between an idea and its realization.

Before, I had an idea and asked myself: “Do I have two months to develop it?”

Then I started asking myself: “Do I have twenty hours to build it with AI?”

Today, in some cases, the question has become: “Can I describe it well enough to have it generated in a few minutes?”

That is a huge difference.

Because it does not eliminate the need for competence.

Quite the opposite: it makes competence even more important.

If you understand nothing about data, statistics, code, or logic, you risk getting something that appears to work but that you are unable to evaluate. AI accelerates, but it does not replace judgment.

It gives you a Ferrari, but if you do not know how to drive, you can still end up off the road.

However, if you already have a foundation, even if you are not a professional programmer, something powerful happens: you start turning more ideas into prototypes, more prototypes into tools, and more tools into results.

In my case, over ten years, the journey has been this: from two months of potential work, to twenty hours of assisted development, to three minutes and forty-four seconds to obtain a first working version.

It is not magic.

It is a change in the interface between thought and code.

And perhaps this is exactly where vibe coding becomes interesting: not because it turns everyone into a programmer, but because it allows people with ideas, domain expertise, and a minimum of technical logic to build things that would otherwise remain stuck in the drawer of “it would be nice, but I do not have time.”