Ideas Worth a Longer Conversation: The JetBrains Research Podcast

Every week there’s at least one new announcement about what AI will do to software development. Most of the conversation moves fast and stays shallow, focusing on productivity gains, job displacement, or which model scored highest on the latest benchmark.

We’re more interested in the questions underneath that noise, so we created the JetBrains Research Podcast. In it, we explore questions, such as:

What does it mean to understand a system, not just generate its code?

What does psychology tell us about why teams succeed or fail?

Why does verifiability matter more than prestige in training agents?

In our podcast, we are mainly interested in research in its various forms and the people behind it. Each podcast episode goes somewhere interesting with someone who has spent serious time on things that matter. In this blog post, we highlight the ideas that came up in these conversations.

Cat Hicks: Culture is infrastructure

“Culture is infrastructure. It is not just a “nice to have”. It shapes our thinking. It shapes our problem-solving. It directly changes the quality of work that we do.”

In our latest episode, we speak with Cat Hicks, psychologist and author of Psychology of Software Teams. We ask her: What actually determines whether software teams do good work? Why study teams instead of individual developers?

Hicks has found that signals of belonging, learning, and recognition from a team can cut developers’ measured AI identity threat, i.e. the fear that their expertise is becoming obsolete, roughly in half. She emphasizes that it is important to look at the team level to better understand what is going on with individual team members.

For example, Hicks has developed a measure she calls overproduction pressure, which refers to the feeling that arises when it seems that only short-term output matters. When that pressure is high, people generate code without understanding it, distrust colleagues, and stop being honest with managers.

Hicks also challenges the “lone genius” myth: the idea that teams should be built around one highly-talented individual. Instead she argues that it is actually better to strive for “more bands, fewer rock stars”. Highly collaborative cultures, such as open-source problem-solving, can be especially effective at achieving technology breakthroughs.

Tomáš Petříček: Five cultures, one argument

“Programming has never really [been] just implementing a specification.”

In our fourth episode, we talk to Tomáš Petříček, a professor at Charles University in Prague who studies the history and philosophy of software. His book Cultures of Programming argues that programming has never been a single discipline. Instead, the following five distinct cultures have been competing and collaborating since the earliest days of computing:

Mathematical, which treats programs as formal objects to be proved correct.

Hacker, which values direct engagement with a running machine.

Managerial, which is focused on predictability and labor organization.

Engineering, which accepts that systems are complex and asks which practices make them reliable despite that complexity.

Humanistic, which begins with the question of what happens in a person’s mind when they interact with software.

Each culture has a different idea of what a program is, what good work looks like, and what matters most. These cultures explain why the same event can lead to varying diagnoses. Take, for example, the Knight Capital failure in 2012, where a software deployment error cost the company $460 million in less than an hour. Depending on which culture you approach the problem from, one diagnosis might differ wildly from another. Here are some example diagnoses from each of the five cultures:

A mathematician would ask what could have been formally guaranteed.

A hacker would ask what low-level knowledge would have caught th eproblem.

An engineer would ask about testing and rollback.

A manager would ask about processes and accountability.

A humanist would ask whether the system made its state legible to those operating it.

Petříček also talks about the current enthusiasm for AI agents, especially specification-driven development. He emphasizes the importance of looking at history. Since the 1960s, people have been trying to isolate the mechanical part of programming and automate it. But it hasn’t worked yet, because software development has always been more than just the implementation of a specification. Teams learn what they’re building through prototypes, conversations, and use.

Alexander Kulikov: What you’re building when the solution is unknown

“When you find a problem that does not get out of your head, this is probably the right problem.”

In our third episode, we chat with Alexander Kulikov, who heads the Algorithms and Complexity Theory Lab at JetBrains Research and is the Head of Computer Science and Artificial Intelligence B.Sc. program at Neapolis University Pafos. His description of the current climate is more honest than most: “amazing, exciting, and frightening at the same time.”

And the concern isn’t entirely theoretical. Chess engines, for example, surpassed every human player decades ago. Kulikov doesn’t know of any law preventing AI from eventually doing the same to theorem proving. He doesn’t expect it imminently, but he also didn’t expect AI-assisted coding to progress as fast as it has. His position is what he calls attentive uncertainty: neither denial nor resignation.

In the episode, we also talk about what it actually means to teach computer science in an era when AI can solve Olympiad problems. Kulikov’s curriculum strategy is simple: teach graduate students how to learn difficult things efficiently. The specific technologies they’ll need are unknowable. The ability to dive into an unfamiliar subject, build a mental model, and make progress is more durable than any particular skill.

That’s also why he still takes mathematics seriously in a world of AI-assisted coding. A student who understands the structure of a problem can test an AI-generated answer, identify missing assumptions, and recover when the first attempt fails. A student who only knows how to request an answer may not know whether the answer is trustworthy.

Kulikov also draws a distinction between researchers who are “birds” (i.e. ranging across fields, spotting connections from above) and “frogs” (i.e. digging deep into one area). In this analogy, he would be a frog. But AI, he thinks, could act as an artificial bird for specialists: lowering the cost of looking beyond your immediate field without requiring you to become a generalist.

Ibragim Badertdinov: From dentistry to coding agents

“Vibe checks don’t scale.”

In our second episode, we talk with Ibragim Badertdinov, the Lead Research Engineer at Nebius. He took a somewhat unusual path to AI research: he first graduated from medical university with honors, completed a dental residency, and then gave himself a year to try something else. In this episode, he talks about how he made that switch, what he learned at School 21 and on Kaggle, and the work that followed. Most notably, we talk about his work on building SWE-rebench.

SWE-rebench is an automated pipeline for evaluating coding agents on real software engineering tasks. Accepted to NeurIPS 2025, it also has over 12 million Hugging Face downloads and a million leaderboard visits a month. Its key design feature is decontamination, or pulling tasks from GitHub only after a model’s release date, so agents can’t be trained on the answers. This way, SWE-rebench isolates the model’s problem-solving ability from any potential exposure to training data. After its release, it made headlines when many models performed substantially worse on SWE-rebench tasks than on SWE-bench Verified ones (see the paper for more details).

This is especially important, because the standard up to now has been SWE-bench Verified, and the reported scores from this benchmark carried significant weight, both in research and the wider industry. As was discussed in a recent blog post, this tendency to focus on only SWE-bench Verified scores can give us a misleading picture of model performance. The post also suggests ways to evaluate models more accurately.

Badertdinov also talks about why reinforcement learning with verifiable rewards has driven such dramatic gains in coding and math specifically. The insight is deceptively simple: in domains where you can verify whether an answer is correct, you can generate vast training signals automatically. Code runs or it doesn’t; tests pass or they don’t. That’s what makes software engineering tasks so valuable for post-training: not their prestige, but their verifiability.

Anna Kogan: The library that became infrastructure

“Right now, computer vision is not cool. LLMs are very cool.”

Our pilot episode is a conversation with Anna Kogan, founder and CEO of FitWise and former CEO of OpenCV.ai. She’s been in computer vision for 15 years and still believes in its scientific value: in computer vision, researchers gather a dataset, train a model, measure metrics, and solve specific tasks. In our conversation, we discuss challenges in the field, including monetizing open-source tools and slow adoption of AI in various industries despite the technology already existing.

The gap between impact and resourcing for open-source tools is one thread in the conversation. An example we discuss is OpenCV, the open-source computer vision library she helped build into a global standard. It runs on billions of devices and gets 32 million Python downloads a month on PyPI alone. Because of these numbers, many people assume the library is maintained by several hundred developers, while in reality it’s been only two to eight developers at any given time.

Another conversation thread concerns a harder question: Why does computer vision adoption still move so slowly, even when tools such as OpenCV are clearly very popular? In response, Kogan brings up human movement in sports. Even though the technological advances are far enough along that people in sports could stop manually clicking through and annotating broadcast footage, organizations are resistant to adopting AI support. One reason is that it is still cheaper to hire workers in the Philippines to do this manual work, than it is to figure out an AI system to take it over.

With FitWise AI, Kogan is interested in helping sports organizations see the value in computer vision adoption. They provide the data, 3D digital replicas of athletes’ body shapes and movements in real time; this data is collected via stadium cameras that are already streaming visual data. Sports organizations can apply their expertise to the visual data, and so far there have been interesting results. For example, one company extracted the angular velocity of a quarterback’s arm during a throw and showed that this is a strong predictor of elite performance.

Tools like FitWise AI can change how teams understand performance and injury risk. It’s a domain where the technology is genuinely ahead of the industry’s willingness to absorb it, and Kogan is not waiting for the industry to catch up on its own.

Explore these ideas and more on our podcast

These are some of the ideas we discuss on the JetBrains Research Podcast. If you find a question you can’t stop thinking about, that’s by design.

All episodes are available on YouTube and Spotify (and any other major podcast platform). We publish new episodes about once a month.

Suggest a speaker