Before Skynet Took Over

A few days ago, I came across a post by a researcher reflecting on how her way of working had changed since the arrival of large language models. I recognized quite a lot of it. Not everything: I am not a full-time researcher, I am a physician first, and research has to fit into whatever time is left around that. But looking back over the past few years, I realized just how much my own way of using these tools has changed.

My first contact with all of this goes back to well before ChatGPT. I was already spending time in OpenAI’s old Playground, playing with davinci and the other completion models available at the time. The mechanics were much more visible than they are today: you gave the model the beginning of a text, it continued it, and you could directly adjust temperature, top_p, and other sampling parameters.

I spent quite a lot of time doing exactly that. Running the same prompt at different temperatures, changing a few words, comparing outputs, watching the point at which the model became more creative, more repetitive, or simply went completely off the rails. I mostly wanted to understand what was behind that rather strange impression of having a machine capable of producing coherent text from almost nothing.

Those parameters are much less visible in consumer applications today. You can obviously still control them when using models through APIs or directly in code, but for general-purpose use I find them much less interesting than I used to. They still matter when you are building something specific — a domain chatbot, a RAG system, a voice assistant, or any application where you want tighter control over behavior — but I no longer spend my evenings looking for the perfect temperature for talking to a model. There are more interesting things to look at now.

Back in the davinci days, there was another fairly obvious lesson: trust nothing.

The early models could produce an answer that sounded perfectly plausible, was beautifully written, and was completely wrong. In medicine and genomics, that became problematic very quickly: invented papers, approximate biological interpretations, imaginary Python functions presented with remarkable confidence. So the fascination came with a fairly simple rule: verify everything.

That problem has not disappeared. Models still hallucinate, and they can still make surprisingly strange mistakes. But it would be equally wrong to pretend that they have not improved enormously. Hallucinations are much less frequent than they used to be, complex instructions are followed more reliably, context windows are on a completely different scale, and above all, the kinds of tasks you can give them have changed entirely.

The Cambrian explosion

When ChatGPT arrived, I obviously used it a lot, but I never really stayed loyal to a single family of models. I tested the successive OpenAI generations, practically every version of Claude, both Sonnet and Opus, the successive Gemini releases, and quite a few open models along the way.

For a long time, I even made a habit of giving exactly the same problem to several models, sometimes simply out of curiosity. It is probably one of the best ways to get rid of the idea that there is such a thing as “the best model.”

At one point, one model could be clearly ahead for coding, another much better with very long documents, and another simply more useful for discussing a scientific hypothesis or spotting weaknesses in an argument. Then a new version would come out three months later and reshuffle everything.

I still do this today. When a result matters, comparing several models is often useful. They do not necessarily fail in the same way. And when they reach different conclusions, that is at least a good reason to go and check what is actually happening.

Over time, my attention shifted. I still follow new model releases — I would probably be incapable of not doing so — but raw model intelligence interests me less than it used to. What increasingly matters is what you build around the model: the context it gets, the tools it can use, its memory, the data it can access, and the way its work is organized.

Moving some of it out of the cloud

That question became very concrete during the workshop we organized with BioInfoDiag at the French Genetics Meeting in January 2026.

One of the goals was to show what could be done with models running locally. In healthcare, that is obviously an important question. It is no longer simply about whether GPT, Claude, or Gemini gained a few extra points on some benchmark. Keeping data inside infrastructure you control, understanding the technical chain, and potentially adapting a system to a specific use case can matter a great deal.

The open models we used already showed quite a lot of potential. But the workshop also reminded us of something that tends to disappear behind the slightly magical phrase “local model”: the model still has to run somewhere.

You need GPUs, enough memory, infrastructure capable of handling multiple users, deployment, maintenance, security, and above all people who actually know how to operate the whole thing. Downloading the model weights is only the beginning. Once you do that, it becomes very clear that the model itself is only one component of the system.

What sits around the model

That is probably why I have become increasingly interested in agent harnesses. I have not found a French translation I really like, and even in English the term is still slightly fuzzy. Broadly speaking, it refers to the infrastructure around the model that allows it to actually work: the agent loop, tools, terminal access, files, memory, permissions, sub-agents, context management, verification mechanisms, task recovery after failure, and so on.

This has become especially obvious with Codex, which I now use practically every day for development.

The difference compared with older coding assistants is quite radical. I no longer simply ask it to write a function that I will then copy into my editor. I can give it a Git repository, ask it to understand the structure, modify several files, run the tests, inspect what breaks, revise its implementation, and continue until it reaches something coherent.

Of course, I still supervise the result. But we are very far from the old workflow of copying a Python traceback into a chatbot, getting three lines of code back, pasting them into the terminal, discovering that they do not work either, and then returning with the next error.

Codex is a good example of how much the harness matters when the model itself has also been trained to work in that kind of environment. Reinforcement learning on tasks where the model has to modify code, use tools, execute something, observe the result, and react to it produces very different behavior from simply placing a model behind a chat window.

I also use Hermes, from Nous Research, several times a week for more general tasks. I like it for a different reason: persistent memory, tools, reusable skills, scheduled tasks, and the ability to switch model providers or use local models. It is not exactly the same use case as Codex, which is precisely what makes it interesting.

And then there is DeepSeek’s new harness. I have not tested that one yet, so I will avoid reviewing it from my sofa. But its architecture looks particularly promising.

The idea of making almost every component interchangeable — model, memory, tools, sandbox, session, agent loop, scheduling — seems like a fairly logical direction. Agent trajectories can also be recorded, resumed, forked, or replayed. If the approach works as intended, it could change the way these systems are designed: instead of treating an agent as a more or less closed block, the harness itself becomes something you can compose, modify, and experiment with.

I find that potentially much more interesting than yet another chatbot interface.

For several years, almost all attention was focused on the next model. How many parameters? How large a context window? How many points gained on the latest benchmark? I do not think those questions have become irrelevant, but they are increasingly only part of the story.

An excellent model in a poor environment can be surprisingly mediocre. Conversely, a slightly weaker model that has been trained to use its tools properly and placed inside a well-designed harness can be far more useful.

And what does this change for research?

None of this means that I now run an automated laboratory with an army of agents working while I drink coffee. Not yet, anyway.

I am still a physician, and that imposes a very simple constraint: time. I do not have the schedule of a full-time PhD student or researcher who can spend several consecutive days exploring a hypothesis, learning a new tool, or rebuilding a pipeline until it works.

That is precisely where these systems have changed things for me.

In the past, a research idea could remain just an idea because it took several evenings simply to find out whether it was worth pursuing. Retrieve the data, understand its structure, write a few scripts, discover that the format was not what you expected, fix the pipeline, read the relevant literature, start again.

A large part of that initial cost has now come down.

That does not mean a scientific study can suddenly be done in a few prompts. Bad data remain bad data. Bias remains bias. A poorly defined cohort does not become valid because an agent analyzed it very quickly.

But these tools increasingly allow me to reach the point where the interesting question begins: is this idea actually worth pursuing?

And contrary to what one might assume, this does not make me regret learning to program or doing bioinformatics. Quite the opposite.

An agent can now produce in a few minutes code that would have taken me hours, sometimes days, to write. But you still need enough understanding to notice that it merged the wrong tables, used the wrong statistical unit, introduced leakage between groups, or simply gave an impeccable answer to a question that made no sense in the first place.

The code can run perfectly and the analysis can still be wrong.

That may be the biggest change in the way I think about these tools.

A few years ago, I spent a lot of time trying to understand the model itself: its temperature, its sampling behavior, its hallucinations, the limits of its context window.

I obviously still test new models, but increasingly I look at what surrounds them.

What environment should the model work in? What tools should it have? How should its work be checked? And, above all, which part of the problem is actually worth handing over to it?

I find those questions much more interesting now than finding out who gained three points on this week’s benchmark.