The data scientist is dead — long live the data science conductor

A friend of mine once played at the Laeiszhalle in Hamburg. The hall was sold out, the gentlemen looked elegant in their double-breasted suits, and the ladies wore heirlooms around their necks. From my seat, I had a good view of my friend, who sat near the front of the orchestra and played the violin virtuously. He looked strained, pizzicato; the conductor raised his baton, vibrato.

After the performance, I met him as he was putting away his instrument. I told him how much I had enjoyed the piece, praised his skillful playing, and asked him how he felt about his performance. I was surprised when he said he had made a few mistakes. To my questioning look, he simply replied, “Luckily, our conductor quickly brought me back on track — he’s keeping an eye on all of us.”

As a layperson when it came to music, I hadn’t really understood the conductor’s role until then. After all, he has more than 40 musicians in front of him, all of whom are more skilled at their instruments than he is himself. Now it became clear to me: Without the conductor, the piece wouldn’t harmonize nearly as well. Because no matter how technically accomplished individual musicians may be, you need someone who has the big picture in mind. Someone who doesn’t just know how a single instrument should sound, but how everything should work together.

Another realization: An orchestra and a data science team have significantly more in common than it might seem.

The conductor’s day

Nowadays everyone in data science uses large language models (LLMs) to write faster and better code. In the pre-GPT era, it usually took me one to two weeks to develop a prototype that could be presentable to stakeholders. Now it takes me less than two days. The productivity gains are enormous. But that’s just a superficial change. Anyone who looks more closely will see a much more fundamental shift.

The InnoGames data science team, to which I belong, consists of seven people. About a year ago, we decided to outsource the majority of our programming work to Claude Code. This set in motion something that, sooner or later, would affect everyone.

Data scientists have now become conductors. Previously, we had seen ourselves more as musicians: We knew exactly how to play our instruments. We knew our code and data pipelines inside and out — and we knew which techniques to use for which use cases.

Today we’re taking a step back to get a better view of the bigger picture. We’re coordinating AI agents that build parts of the whole for us. In doing so, we need to ensure that this big picture looks the way it should: Architecture and design patterns are increasingly coming into focus.

While reflecting on our new self-image, I asked myself if I had ever written anything as simple as a decision tree entirely in pure Python. The answer was no. However, this isn’t unfamiliar to our role: Data scientists have always imported code written by others to use in their own code.

The agentic paralysis

The new path our team took simply elevated the underlying idea to the next level. Almost a year after switching to fully agentic, my role as scientist is becoming more like what I originally imagined. What’s truly at the heart of a data scientist’s work is iteration: We build models, check the results, weigh the options, consider what we can adjust (or whether we should try a different approach), and then start the next iteration. We continue until we’re satisfied with the result. By delegating programming tasks, we can iterate faster and more frequently. It also makes it easier to discard a potentially hopeless approach and start completely from scratch.

Given such a shift in the role of the data scientist, a revised job description isn’t enough. This transformation also entails a change in working methods. At the heart of this new way of working, for us, was the idea of ​​viewing Claude Code more as infrastructure — or even a team member — rather than as a program that’s opened in the morning and closed again in the evening.

AI agents need context — the implicit knowledge we’ve accumulated over years — and coding guidelines. They need smaller tasks that they can execute perfectly and that, in the grand scheme of things, form the bigger picture. Much of our work now takes place in the concept phase — and when it comes to architecture. That is, before any code is even written. It’s crucial to understand that it’s not just about writing better prompts. The essential thing is to build an environment where the agents function as an integral part.

After embarking on our new path, we very quickly noticed something that felt counterintuitive: We were slowing down — the productivity gains were gone. From today’s perspective, this apparent paradox is easily explained: We had to train the agents. They lacked context, which is why the generated code was flawed — and we had to look very closely at everything.

But with time and better context, the agents improved steadily. After about three months, we reached the same productivity level as before the change and were becoming increasingly confident in our new roles. We were also fortunate: Our boss gave us the time we needed. It wasn’t expected that the change would immediately make us more productive. And that was a good thing.

Counteracting AI temptations

Has everything improved almost a year after the switchover? No. New problems keep arising, requiring fresh solutions. While newer LLMs and more context do improve the agents, this can quickly lead to a situation where the agents’ coding suggestions are accepted too readily. This not only harms your own programming skills: One can easily imagine the problems that will arise when only the AI ​​agents understand the code.

Those starting out in the field of data science are finding it particularly difficult: Firstly, because junior roles are now less in demand. Secondly, because newcomers lack the necessary in-depth understanding, and it’s incredibly tempting to simply hand over any bugs to Claude Code. Claude will fix those bugs, but without the data scientist gaining valuable learning experience.

Even experienced team members aren’t immune to this. That’s why we at InnoGames are trying to counteract these temptations with creative ideas. For example, we’ve introduced a monthly “No AI” day and joint pair programming sessions. Whether this is sufficient, or whether other methods will prove more effective, remains to be seen.

When I recently told my musician friend about my journey to becoming a conductor, he chuckled and revealed that conductors are often the butt of jokes behind their backs. And who knows, maybe the AI ​​agents are even talking about me among themselves? If so, I’d love to hear something like this: “Luckily, our conductor quickly brought me back under control; he’s got us all under control.”