Check out an overview video by our developer advocate William Vincent:

Now, let’s take a closer look at the key highlights.

JetBrains Air in PyCharm – One place to run your agents and verify their work 

As of this release, JetBrains IDEs ship with Air, a new layer for agentic development. Work with the coding agents of your choice, and run, track, and verify multi-agent workflows inside your IDE, where code intelligence helps agents make fewer wrong turns and gives you the tools to review every change before it ships.

Your agents, your models, your subscriptions – with Junie Lite for free

Air works with Claude Agent, Codex, Gemini, GitHub Copilot, Junie, OpenCode, and other ACP-compatible agents. It detects the agents already installed on your machine so you can connect them in a click, and you can add more from the agent registry.

Your existing setup carries over, too: provider subscriptions, API keys, and even a custom base URL all work, with no JetBrains AI subscription required. Run Claude Agent on your Claude subscription in the terminal or in a full-screen IDE tab, use other agent subscriptions in the chat or terminal, and switch between subscriptions at any moment, even mid-session.

Air includes free AI with the Junie Lite configuration, so you can use an agent without a subscription. You only need a JetBrains Account.

A central workspace to review changes and guide the agent

Review an agent’s changes with the surrounding code and your project tools in view, and send feedback straight back to the agent. Anchor a note to a specific line in the diff, or comment directly from the code, so the agent gets concrete context about the change you want. Work in the chat or the terminal, whichever suits you.

Still using AI Assistant? A notification will offer you a trial of Air. Moving to Air hides AI Assistant, if you wish to return to AI Assistant follow the steps outlined here. Air automatically migrates your IDE skills, MCP configuration, agents installed through ACP, authentication, and chat history. Chat mode history isn’t migrated.

Workspace support

A console and terminal for each subproject

Each subproject has its own Python console and terminal running in its own environment, so you run code against the dependencies that subproject actually uses. In uv workspaces, the console uses the workspace environment and adds the subproject root to sys.path.

• Right-click a subproject and select Open in | Python console to start a console for it.
• Open a terminal while a subproject file is in the editor to run commands in that subproject’s environment.

Subproject creation and conversion

You can add a new subproject or convert an existing folder from the Project tool window context menu. The subproject is initialized using uv, Hatch, or Poetry, and automatically added as a workspace member to your root pyproject.toml in uv workspaces.

Python 3.15 lazy imports

PyCharm now supports the lazy import syntax introduced in Python 3.15. A lazy import defers loading a module until it’s first used, which can noticeably cut startup time in applications and scripts with heavy dependencies. PyCharm parses and resolves lazy imports like regular ones, so you can adopt the syntax without giving up code insight on the names you import.

Learn more about lazy imports in our blog post.

FastAPI support ^[Pro]

An endpoint can depend on a chain of Depends() and Security() calls spread across many files. PyCharm draws that chain as a graph for any endpoint. Each dependency is marked as yield or return, and circular dependencies, which raise a RuntimeError at startup, are flagged in the editor. In the other direction, a dependency shows which endpoints rely on it, directly or through other dependencies.

You can open the graph from the gutter icon next to an endpoint or click the endpoint count above a dependency to see its usages.

Python interpreter widget

The redesigned Python interpreter widget in the status bar is built around the tools that manage your environments, such as uv, Poetry, Hatch, and conda. It detects the ones installed on your machine and lists the environments each one manages for your project.

Environments created from the command line also appear under their tool. To start working in one, open the widget, select the tool, and pick the environment. To recreate it with a different Python version, choose Recreate Environment under Current Environment. If the Python version you choose isn’t installed, you’ll be prompted to download it.

Pydantic support

PyCharm now provides deeper editor support for Pydantic models. Field constraints, validators, and configuration are read from the model’s declaration and used across the editor.

• Values passed to a model are checked against its Field() constraints, such as min_length, max_length, gt, and lt, with a warning displayed when one is broken.
• A field name inside @field_validator('price') now resolves to that field’s definition, letting you jump straight to it.
• Code completion suggests configuration options in a model’s class arguments, such as validate_by_name and validate_by_alias.

What you see here only scratches the surface of what is included in PyCharm 2026.3. From editing standalone files in the new Home window to full SQLAlchemy ORM support, automatic project configuration copy in Git worktrees, and remote development directly from the IDE via SSH – there is plenty more to explore across code insight, testing, environments, and version control.

Head over to the What’s new in PyCharm 2026.3 page to see the complete list of features, performance improvements, and fixes.

We would love to hear how JetBrains Air and the new workspace tooling fit into your day-to-day work – share your thoughts in the comments below or submit feedback directly in our issue tracker.

• The private keys of eight eMudhra intermediate certificates were compromised. A network attacker could use them to impersonate websites and services that JetBrains tools connect to.
• JetBrains IDEs, the Toolbox App, Gateway, and ReSharper are affected because they use the trust store of the bundled JetBrains Runtime (JBR). For IDEs, the embedded browser (JCEF) is also affected. Operating system updates don’t protect against this issue. 
• The Toolbox App and JetBrains IDEs use a background service, jetbrainsd. It has its own built-in list of trusted certificates and is fixed separately, in jetbrainsd 0.9.9728.
• At the time of publishing, we are not aware of any exploitation of this issue against JetBrains users.

Available fixed versions

The issue is fixed in the following versions:

• IntelliJ IDEA: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.4.
• PyCharm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• PhpStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• RubyMine: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• WebStorm: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.6.2, 2025.2.6.3.
• Rider: 2026.3 EAP 9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• CLion: 2026.3 RC, 2026.2.4.1, 2026.1.5.2, 2025.3.6.3, 2025.2.6.3.
• DataSpell: 2026.1.3.1, 2025.3.3.1, 2025.2.4.1.
• DataGrip: 2026.3 RC, 2026.2.6.1, 2026.1.4.1, 2025.3.6.1, 2025.2.6.1.
• GoLand: 2026.3 RC, 2026.2.4, 2026.1.5.1, 2025.3.5.2, 2025.2.6.3.
• RustRover: 2026.3 EAP 8, 2026.2.5, 2026.1.4.1, 2025.3.7.1, 2025.2.6.1.
• Gateway: 2026.3 RC, 2026.2.4, 2026.1.4, 2025.3.3, 2025.2.6.
• ReSharper: 2026.3 EAP9, 2026.2.4, 2026.1.5.3, 2025.3.5.3.
• Toolbox App 3.9.1, 3.8.2.

The 2025.2.6.* updates for all IDEs now contain only the JBR fix. They will get a separate hotfix for the JCEF problem. Until then, use a workaround to disable JCEF in your IDE (see instructions below).

IDE versions 2025.1 and earlier, and Toolbox App 3.7 and earlier, will not receive this fix. You must update to a fixed version.

Details

In October 2026, the private keys of eight intermediate certificates issued by the certificate authority eMudhra were compromised. An attacker who can intercept your network traffic could use them to impersonate websites and services.

Full details of the incident.

JetBrains IDEs check certificates against the trust store of their bundled runtime, JetBrains Runtime (JBR), so updating your operating system doesn’t protect against this issue. We’ve integrated Oracle’s fixes for CVE-2026-91403 and CVE-2026-114820 into JBR as-is. The updated runtime blocks the compromised certificates and no longer trusts these root certificates:

• emSign ECC Root CA – G3
• emSign Root CA – G1
• emSign Root CA – G2
• AAA Certificate Services

In the fixed versions of 2025.3 and later, the embedded browser now receives Chrome’s certificate updates, which block the compromised certificates (CVE-2026-118696). It downloads them from Google’s update servers shortly after the IDE starts. If your network blocks access to Google’s update servers, the embedded browser stays unprotected. In this case, turn it off as described below.

The Toolbox App and JetBrains IDEs also install a background service, jetbrainsd. Its list of trusted certificates is built into the service itself, so updating JBR doesn’t fix it. We’ve released a separate fix in jetbrainsd 0.9.9728, tracked as CVE-2026-118697. Only one copy of jetbrainsd runs for each user, and a newer version always replaces an older one. Updating any app that includes jetbrainsd 0.9.9728 fixes it for all JetBrains apps.

What you should do: Update now

The fix is available in the latest versions of JetBrains IDEs, from 2025.2 up to 2026.3 RC. The upcoming 2026.3 release will include it too. Updating to the latest bugfix release of your current version is enough. Versions 2025.1 and earlier will not receive a fix. If you use one of them, please update to one of the versions above.

If you use ReSharper or other JetBrains .NET tools, update them to the latest version.

Important for Toolbox App users: versions 3.7 and earlier won’t receive this fix. If you’re on 3.7, update to version 3.9.1 or 3.8.2.

If you use JetBrains Gateway, update it to one of the following versions: 2026.1.4, 2025.3.3, 2025.2.6.

If you use JetBrains Runtime directly, update to one of the fixed builds: jbr25.635.79, jbr25.508.41, jbr25.329.142, jbr21.1163.125, jbr21.1038.91.

In rare cases, the IDE will no longer connect to a server whose certificate chains to one of the removed root certificates. The server’s owner will need to replace the certificate.

If you can’t update right away

Also check

Your project JDKs and any tools that bring their own runtime, such as Node.js, Python, or Go, use their own trust stores. Update them as their vendors recommend.

Support

If you have any questions about this issue or have trouble updating, please contact our Support team.

But we also know a lot more about the developers who use these two languages – both from quantitative data from different surveys, as well as qualitative data from our interviews with professionals who switched from Python to Go.

In this article, we share findings from these sources, going well beyond the simple syntax comparisons you will usually find. We will look at how the two languages differ, what the surveys tell us about the people who use them, and what our interviews say about the trade-offs between Python and Go, so that if you’re considering making the leap, you don’t have to dive in blind.

TL;DR

• The article compares Python and Go across language design, performance, tooling, developer profiles, and migration experiences.
• Python favors expressive code and rapid iteration; Go favors explicit, standardized code that is easy to maintain across teams.
• Go excels in raw performance and concurrency, and is widely used in cloud infrastructure. Python remains stronger for machine learning, data science, and scientific computing.
• Go developers are typically more infrastructure-focused and more senior. Go is rarely someone’s first language, whereas Python is very beginner-friendly.
• Python leads in building AI models, yet Go developers create AI integrations at nearly the same rate: 46% vs 44%.
• Moving to Go rarely means abandoning Python. Most teams use both, with Go for services and infrastructure and Python for AI and data workloads.

A note about the data

Unless stated otherwise, all survey figures come from the JetBrains Developer Ecosystem Survey 2026 (28,945 responses, fielded May–July 2026). We compare two groups: developers who selected Go among their primary languages (1,836) and developers who selected Python (11,298). The groups overlap, with 619 respondents selecting both languages. Therefore, every gap below is a conservative estimate of the real difference. Some questions were shown to only a part of each group, so bases are provided for reference. The qualitative material comes from interviews with developers who moved production workloads from Python to Go. We conducted the interviews between April and May 2026 and included seven participants who began using Go within the past year.

Python vs Go – languages compared

Core philosophy

On paper, Python and Go sound like they’d get along. Python lays out the core principles in the Zen of Python: Simple is better than complex, readability counts, there should be one obvious way to do it, etc. Go, as per Effective Go, “focuses on simplicity, reliability, and efficiency”, and is “specifically designed to make it easy to build software at scale”.

In practice, Python often optimizes for the person writing the code, offering multiple ways to say the same thing. Go optimizes for the person (or, nowadays, possibly the agent) reading someone else’s code two years later, so it picks one way to say most things and makes you spell it out. The goal is for all Go code to look like other Go code.

We point this out right at the beginning, because however similar these two philosophies look, this difference in approach underlies almost all the other language design differences that follow.

Ease of use and learning curve

Python is arguably one of the easiest programming languages to learn among those widely used in production. The syntax resembles natural language, the core set of constructs is small, and beginners can focus on programming ideas instead of language mechanics, leading to less frustration and faster results. Surveys consistently show Python to be one of the most popular programming languages (if not the most popular). In 2026, 10% of Python developers have been coding for less than a year, 23% are students or working students, and 19% hold junior positions, showing the language has a strong early-stage user base.

Python’s popularity among early learners is almost self-perpetuating. Initially, the language was well-suited to introductory courses and learning materials largely because it lets beginners print “Hello, world” with little ceremony, bypassing much boring theory in favor of real outputs. It also has the added benefit of being a generalist language that can handle a variety of use cases. Later, the sheer number of introductory courses and learning materials made it a natural choice for anyone who wanted to pick up programming but didn’t know where to start.

It’s not the same case with Go. In fact, you would be hard-pressed to find courses that teach you programming through Go. There are two reasons for that. First, Go 1.0 was released in 2012, long after Python had already become firmly embedded in CS curricula. The other is that Go solves problems that beginners don’t have. Explicit error handling, static types, and interfaces, which we’ll discuss later, all pay off across a large codebase maintained by a team over years. Go also has a much narrower set of implementations than Python, which makes it even less appealing for beginners.

That said, Go was also designed to be easy to learn, but for a different reason: Any large team should be able to onboard a new engineer quickly. Many Go developers will say that if you already know general programming concepts, you can become productive in Go in a matter of days or weeks. Developers we talked to said that Go “feels as easy to write as Python” and that it “strikes a good balance between Python’s simplicity and Java’s explicit nature”.

Syntax and readability

When you read Python, you can often follow it even without programming experience, because it reads relatively close to English. Python is dynamically typed, so type declarations are optional, though in practice, many companies and large codebases now write Python with type hints throughout, checked by tools like mypy or Pyright. Most of the ecosystem follows the formatting conventions set out in PEP 8, but they are still optional, and so some teams diverge from them.

Go, by contrast, is explicit and deliberately limited, which contributes to the cross-team readability we mentioned. It is statically typed, which makes it noticeably more verbose than Python. That was the main syntactic complaint raised by the developers we interviewed. Formatting in Go is not a matter of preference: gofmt will shape your code into the canonical form, whether you like the conventions or not.

One syntactic difference that developers consistently pointed out as a big adjustment when moving from Python to Go was error handling. Python lets you push failure handling to the edges of a function with try / except. Experienced Go developers clutch their pearls at the sight of that.

# Python: handle failure where it is convenient
try:
    profile = get_user(user_id)
except UserNotFound:
    return render_404()

// Go: handle failure where it happens
profile, err := getUser(userID)
if err != nil {
    if _, ok := errors.AsType[*UserNotFoundError](err); ok {
        return render404(w)
    }
    return fmt.Errorf("get user %s: %w", userID, err)
}

The Go version is longer, and in a large handler, developers will find themselves writing the if err != nil boilerplate ad nauseam. In return, they get control flow with no invisible jumps: Every path a value can take is explicit. Both approaches come with trade-offs.

Type system

Python’s dynamic typing checks types at runtime. This gives developers flexibility in writing and can speed up iteration, but it also means some type errors only show up when the code runs. The flexibility extends to the object model, which relies on duck typing: The code cares less about what an object is than what it can do. The developers we interviewed said they sorely missed duck typing, as it makes testing and mocking more difficult in Go.

Go checks types before the program runs. This results in fewer type-related failures reaching production and makes refactoring safer, but also causes code verbosity, as we touched on earlier.

Object model and polymorphism

Python is object-oriented in the way that most developers first learn the term. Everything is an object, and classes inherit from other classes (several at once, if you insist). Polymorphism works in two ways: down the class hierarchy when a subclass overrides its parent’s method, and sideways through duck typing, where anything with a read() method can be handed to code that expects a file.

Go has none of that hierarchy. There are no classes, no inheritance, and no way to declare that one type is a subtype of another. Instead, structs have methods attached to them, as well as interfaces that types satisfy implicitly without ever naming them.

# Python: the implementation announces its role
class Store(ABC):
    @abstractmethod
    def get(self, key: str) -> bytes: ...

class RedisStore(Store):
    def get(self, key: str) -> bytes:
        ...

// Go: the consumer declares what it needs; RedisStore never mentions Getter
type Getter interface {
    Get(key string) ([]byte, error)
}

func handleRead(g Getter, key string) ([]byte, error) {
    return g.Get(key)
}

Notice how the dependency runs. In Python, RedisStore inherits from Store, so the abstraction sits with the implementation. In Go, handleRead declares the one method it actually calls, and RedisStore never learns that Getter exists. That’s why Go developers say to “accept interfaces, return structs”, and that’s why interfaces stay small – io.Reader and io.Writer have a single method each.

Performance and speed

Go follows a traditional compilation model, producing a native binary. Python, on the other hand, takes a hybrid approach: Source code is compiled to bytecode, which the interpreter then executes.

As most compiled languages do, Go wins in terms of raw speed. You can compare the patterns across latency, throughput, and startup time on The Computer Language Benchmarks Game. Microbenchmarks like these don’t really translate directly to real workloads, and we wouldn’t be surprised if you made nothing of them. Our interviewees told us what the difference meant in production for them: One team migrated to Go after cold starts on AWS Lambda in Python exceeded 10 seconds; another measured a tenfold improvement in request times after rewriting their Python service in Go.

But raw language speed matters only when your service is actually compute-bound or latency-sensitive, and plenty of services are neither. Equally importantly, the Python interpreter is not slow where it counts most for one of its largest user bases. In machine learning, data work, and numerical computing, libraries like NumPy and PyTorch offload expensive operations to optimized native code, making interpreter overhead much less relevant. When we asked migrating developers where they decided to keep Python code, they confidently listed all AI and ML workflows – LLMs, chatbots, RAGs, and model training.

Memory management

Memory management is another important part of the performance discussion. Both languages manage memory for you, but differently: Go uses a tracing garbage collector, while CPython uses reference counting alongside a cyclic garbage collector. This affects what developers can fine-tune and what they need to design around.

Go’s GC runs concurrently with the program and is designed to minimize stop-the-world pauses. Developers can tune this behavior: GOGC and GOMEMLIMIT set the pacing, and the memory profile (heap and allocs) tells you when a service allocates too hard.

In CPython, an object is typically freed the moment its last reference disappears. Memory use is predictable, and pauses are rarely worth measuring, but the cost is spread across every operation, and there’s little to room tune it.   

Concurrency and parallelism

Even though both languages support concurrency, developers we talked to cited better concurrency as the reason why they switched from Python to Go.

Goroutines are central to Go’s design. They are lightweight threads managed by the runtime. They are cheap to create, carry little overhead, and scale to thousands of concurrent operations. The runtime handles the scheduling, which makes the model simpler than in Python – there is no separate async/await syntax, so a function is just a function. However, if you start to spawn goroutines without controlling their lifecycle, you’d better be ready to deal with race conditions, leaks, and deadlocks before long.

The other half of the concurrency model in Go are channels – typed conduits that pass values between goroutines and synchronize them. Instead of guarding shared state with a lock, Go can pass the value to whichever needs it next. A select statement waits on several channels at once, which is how Go expresses timeouts, cancellation, and fan-in using built-in language constructs. These very same primitives also produce common Go bugs: goroutine leaks and more deadlocks. 

Meanwhile, Python relies on standard libraries, single-threaded event loops, and sub-processes to work around interpreter constraints. It offers threading, but in CPython, the global interpreter lock (GIL) has historically prevented threads from running Python bytecode simultaneously, making it ineffective for CPU-bound parallelism. For I/O-bound concurrency, there is asyncio, and for real parallelism there is multiprocessing, but that adds memory overhead and requires inter-process communication.

It’s worth noting that the GIL itself is no longer a necessity – starting with Python 3.13, PEP 703 introduced an officially supported free-threaded build, and 3.14 continues that work. Most production code still runs with the GIL in place, but with each new release, the claim that “Python can’t do real threading” is becoming less true.

# Python: async/await, and the coloring that comes with it
async def fetch_all(urls):
    return await asyncio.gather(*(fetch(u) for u in urls))

// Go: ordinary functions run concurrently
var wg sync.WaitGroup
for _, u := range urls {
    wg.Go(func() {
        fetch(u)
    })
}
wg.Wait()

The approach to concurrency gives Go much of its practical advantage in high-throughput services, and having experienced both, our interviewees praised Go for being “async by default” and better suited for high-concurrency components, and they described it as having a superior concurrency model that’s highly performant and appealing for real-world use cases.

Libraries, frameworks, and IDEs

Go’s self-contained ecosystem

Go was never built as just a programming language, but as an ecosystem. As the Go team puts it, the goal was “an end-to-end platform with tooling all around the software development lifecycle” (Google for Developers), with formatters, test frameworks, dependency management, and security tools included in the toolchain, alongside a standard library that’s comprehensive enough to make external frameworks optional, if not irrelevant.

The Developer Ecosystem 2026 survey shows how successful the Go team has been in achieving that goal. For example, among Gophers, the standard html/template and text/template library packages are used by 31% and 22% of developers respectively, whereas the only other significant alternative – templ – is used by 11%.

Almost half of Gophers either don’t write unit tests or don’t use testing frameworks: 14% don’t write unit tests at all, and 35% don’t use frameworks for testing – the testing package provides everything they need in that regard. Others may also reach for tools such as Testify (31%) or GoMock (25%). The remaining libraries are far less popular.

For web development, 46% of developers use the standard net/http library, compared to 48% who use Gin. This proves that where a third-party framework exists, it doesn’t compete with the many other frameworks, but only with the standard library. Oftentimes, it loses.

Python’s broad ecosystem

Python’s ecosystem works the other way around. The Python Package Index (PyPI) is vast and mature, and where the standard library stops, several strong alternatives tend to compete.

Take web frameworks, for example. Half of Python developers use FastAPI, and Django (31%) competes closely with Flask (30%). The data science landscape is more fragmented, and developers use those libraries simultaneously: 69% use NumPy, 68% use pandas, 50% use PyTorch, 49% use Matplotlib, etc. With Python, there’s often no clear leader, and choosing the right framework or library is part of the job.

IDEs & editors

When it comes to editors, we see a similar pattern unfold. Go has an excellent language server, which makes general-purpose editors a viable alternative to a Go-specific IDE. When asked which IDEs or editors they use for Go development, 49% reported using GoLand, while 48% reported using VS Code. 

One reason is how much of Go’s surrounding ecosystem developers can access without having to assemble it themselves. GoLand installs with a test runner, debugger, coverage, and profilers wired into the toolchain. The analysis runs across the whole project, rather than only the open file. Interprocedural nil checks and unhandled-error inspections can catch the mistakes a Python developer might otherwise only see at runtime. Suffice it to say, Alan Donovan of the Go team has also described traditional IDEs like ours as setting “the gold standard” for refactoring because of their tight integration between the analysis logic and the user interface.

The Python side is more fragmented and has more Python-specific options, such as Jupyter Notebook and, of course, PyCharm. The latter is used by 30% of Python developers (PyCharm – 22%, PyCharm Pro – 8%), with VS Code at 41%. Notebooks explain much of the fragmentation, since data and service work don’t necessarily require the same toolset. Whatever you build in Python, PyCharm has first-class support for your stack, your frameworks, and your workflow – for web, data, and ML workflows – with notebooks running alongside a debugger and type checker. It parses your code and resolves usages, types, and dependencies throughout your entire project. So you always know exactly what your code does and what will break if it changes, for you and your agents alike.

If you use both Go and Python – as a quarter of Gophers do – it’s worth noting that both GoLand and PyCharm are built on the same platform, so keymaps, shortcuts, and settings sync between them. GoLand also supports Python functionalities through the Python Community Edition plugin.

Python vs Go – broader landscapes

The language itself is one thing, but many other factors go into deciding which language you choose to work with. Developers consider what the languages are used for, who uses them, and how they’re maintained. In this section, we’ll provide insights on the factors that shape the broader landscapes of Python and Go.

Go developers are more senior

Across all questions about age, experience, and seniority in the Developer Ecosystem 2026 survey, Gophers tend to be further along in their career than Python developers.

On overall professional coding experience (not just experience in their main programming language), 20% of Go devs report 16 years or more, compared to 12% among Python developers. At the other end, 9% of Gophers have 1–2 years of experience, compared to 20% of Python developers.

Most Go professionals have senior roles, at 60%, with only 2% being trainees and 10% juniors. Meanwhile, 42% of Python professionals are seniors; trainees (6%) and juniors (19%) make up a quarter of the cohort.

72% of Go developers are employed full-time, compared to 51% of Python developers. Students and working students make up 8% of Gophers, compared to 23% of the Python population.

Finally, by age, the largest group of Go developers is aged 30–34 (23%), compared to Python’s largest group, aged 21–24 (22%).

These differences align with the point we made earlier: Python is a very popular first language for learners, while Go is almost never chosen as a first language and instead is picked up by more experienced developers later in their careers.

It’s important to keep this in mind as you read the following sections on developer demographics, because a lot of these numbers may look like differences between two languages, where in reality, they’re just differences between a senior population vs a general one that you would see regardless of what ecosystems you compare.

Salary follows seniority

Salary bands clearly show how experience affects other demographic data. Go developers are better represented in the top bracket: 9% report earning more than $180,000 a year, compared to 6% of Python programmers. Meanwhile, Python users cluster more in the lowest brackets.

However, if we look only at full-time developers, the differences are no longer statistically significant. The premium is attached to the seniority and employment status, not the primary language. In other words, learning Go itself will not guarantee you a higher salary, but the roles that require Go generally pay better.

What they build

The Developer Ecosystem survey also asks people what functionality their code implements.

Go developers more frequently reported:

• 69% – providing APIs and services (Python – 41%)
• 63% – integrating with APIs and services (Python – 47%)
• 51% – application logic and workflows (Python – 37%)
• 47% – user interface (Python – 41%)
• 35% – libraries and frameworks (Python – 26%)

Meanwhile, Python developers reported higher rates for:

• 38% – data processing and analytics (Go – 30%)
• 36% – artificial intelligence and machine learning (Go – 20%)
• 32% – data science and data analytics (Go – 15%)

The question of where their code is executed adds more context: A vast majority of Go developers target server, infrastructure, or cloud environments (74% compared to 57% of Python developers. On the other hand, 66% of Python developers target the desktop (Go – 47%).

Python is clearly a general-purpose language with a stronghold in AI, ML, and data work that favors local execution, while Go is heavily oriented towards networked services and infrastructure.

There is, however, a particularly interesting line item in the set: integration with AI. While AI development per se is a Python domain, integrations are not. 46% of Go developers report implementing AI integrations, against Python’s 44%, almost equal numbers. Asked about the types of development they do at work, 51% of Python developers reported working with AI and AI tools, compared to Go’s 48%. Go engineers may not train the models, but they are building AI-powered products at roughly the same rate as Python developers.

DevOps: Same job, different toolbox

One other point of convergence between Python and Go developers that deserves its own section is DevOps. Both groups are involved in that area, though Python developers (31%) somewhat less than Gophers (45%). The two groups also tend to use different tools.

• For orchestration, Go developers are more likely to use tooling overall, and especially Kubernetes. Only 8% of Go developers don’t use container orchestration tools (compared to 17% for Python); 58% use Kubernetes (compared to 39%). The engineers we talked to cited Go’s deep integration with Kubernetes as one of the reasons they migrate entire services from Python to Go.
• For configuration management, Terraform leads both groups. However, Python developers lean more toward cloud-native IaC tools (29% for Python, 23% for Go) or use nothing (21% for Python, 15% for Go), while Go developers choose GitOps more often (27% for Go, 21% for Python).
• When it comes to DevOps practices, Go developers report using them more often overall, with one exception: AI-driven operations (12% of Go developers and 18% of Python developers). Python developers are also more likely to use no DevOps practices at all (6% for Python, 2% for Go).

So even if you move from Python to Go in the same type of role, the toolset change might be as big an adjustment as the language change itself.

Operating systems

A curious difference surfaced when we asked developers about the operating system they use for their development environment. Go developers work on macOS (70%) and Linux (57%) significantly more than on Windows (44%). Meanwhile, Python developers use Windows first (66%), then split almost evenly between macOS (54%) and Linux (52%).

For developers planning to migrate to Go, sticking with Windows doesn’t have to complicate deployment, even when the target is a Linux server. For pure Go, building a Linux binary from any of the three operating systems takes no more than two environment variables, while a Python deployment still has to find a matching interpreter and native packages, wherever it ends up.

Two different approaches to AI

We’ve already discussed using Python and Go for AI development, but what about using AI for Go and Python development? Both groups use AI heavily at work, but there’s a difference in how and what they use it for.

Go developers report using AI daily for tasks such as editing code across multiple files (60% vs 52%), agentic development of features or programs (51% vs 41%),  generating commit messages (51% vs 36%) and tests (47% vs 34%), or performing code reviews (39% vs 34%).

Meanwhile, Python developers lead on one task: learning new things about coding and software development (38% of Python developers vs 31% of Go developers), which is consistent with earlier data showing a larger early-career population among Python developers.

There is, however, a long list of tasks where the two groups are indistinguishable: refactoring, debugging, checking code for potential issues, asking general questions, or generating boilerplate – even though you’d expect Go developers to jump on the last one much more, considering the verbosity of the language.

So AI-assisted coding is common in both ecosystems. Go developers have simply wired it into the production chores of a maintenance-heavy codebase: commits, tests, reviews, and multi-file edits.

The groups also tend to use different tools. Go developers are more likely to use terminal and agentic tools like Claude Code (45% vs 40%), OpenAI Codex (24% vs 17%), Cursor (17% vs 12%), and OpenCode (12% vs 6%). Python developers, in turn, reach more for general-purpose assistants and Google or Microsoft surfaces like ChatGPT (20% vs 16%), Google Antigravity (9% vs 5%), and Microsoft 365 Copilot (4% vs 1%).

One number that has to change

Software development remains a heavily male-dominated field, and the gap is particularly pronounced in Go, which – as it’s typically people’s second language – inherits whatever the pipeline hands it and exacerbates it further. In our sample, only 1.8% of Go developers identify as female, compared to 5.8% of Python developers.

Transitioning from Python to Go

One-way path well traveled

You may ask why we’re focusing on transitioning from Python to Go, not the other way around. The data leaves little doubt about the path developers are taking. Python is already the most common second language among Go developers – 35% of Gophers declare it as their other primary language. But most Go developers (70%) say they have no intention of adopting another language in the next 12 months, and if they do, they name Rust (16%), rather than Python (2%). On the other hand, 10% of Python developers (a much larger cohort in terms of absolute numbers) plan to pick up Go, roughly 5.5 times the rate at which Go developers plan to pick up Python.

Why make the switch from Python to Go?

Despite working in different roles and on different products, the developers we interviewed gave consistent reasons for transitioning from Python to Go. These were:

• Better performance and speed, including cold starts, latency, and operating cost.
• Easier and more effective concurrency model.
• Type safety that catches failures that would otherwise reach production at compile time.
• Proximity to the platform, since Kubernetes and much of the cloud-native toolchain are written in Go, so teams working on that infrastructure already interact with Go daily.

What they gained and what they lost

Perceived potential gains are one thing, but did Go actually deliver? According to the developers we interviewed, it did in the areas described above. But they also found benefits they weren’t expecting: predictable formatting and linting that contributed to “clean code”, out-of-the-box tooling, and simplicity comparable to Python’s.

But Go also has flaws that are obvious to developers coming from Python. Just like the reasons for adopting Go were consistent, so were the complaints:

• Explicit error handling that’s fundamentally different from Python, less intuitive, and more repetitive.
• Overall verbosity and opinionatedness, with more lines needed to convey the same behavior and fewer ways to express it.
• An object model that makes testing and mocking noticeably more difficult.
• Library gaps, especially for testing.

Did they really leave?

“Migrating”, “transitioning”, and “switching over” may all sound like final decisions to leave Python behind, but that’s not really the case. Not one of the developers we interviewed removed Python from their stack completely. They kept it for artificial intelligence and machine learning, data science, and pipelines on platforms that only support Python, as well as simply because they work on larger teams that already know Python and are productive in it.

The realistic outcome of “moving to Go” is not becoming a monoglot, but having a polyglot codebase where each language is used for what it’s best suited for.

Conclusions

So, which language should you choose? Is it worth dropping Python in favor of Go? We hope that by now the answer is clear – it’s not a matter of which language is better, but which one is a better fit. Based on our data and developer testimony, here’s what we found.

Go may be a better fit if:

• Performance is crucial for your app: Latency, throughput, or cold starts are problems you actually have and can measure.
• The workload is concurrent, especially if it is I/O-heavy.
• The service is long-lived and maintained by a team, not one person.
• The system already depends heavily on Kubernetes and the rest of the cloud-native toolchain.

Python may be a better fit if:

• The work is machine learning, data science, or numerical computing.
• Your platform only accepts Python, as managed ETL and notebook environments frequently do.
• Iteration speed matters more than runtime speed, which is often the case for internal tooling and prototypes.
• The library you depend on has no Go equivalent; for a lot of the scientific stack, there isn’t one.

Language features alone rarely determine the best choice. When deciding what to build with, the teams weigh in the toolchain they already run, the languages their colleagues already know or are willing to learn, and how much of the existing system they are willing to change. Those things carry more weight than any benchmark, and they are why developers we talked to ended up using both languages, instead of choosing one.

Frequently asked questions

Can Go replace Python completely?

For a lot of backend work, yes, in principle. In practice, it doesn’t. None of the developers we interviewed removed Python from their stack completely. They kept it for machine learning and data science, for pipelines on platforms that only accept Python, and because the teams around them already know it. In the Developer Ecosystem 2026 survey, about a quarter of Go developers report using Python in the same project.

Is Go good for data engineering?

It depends on which end of the pipeline you mean. Go works well for moving data around, including ingestion services, stream processing, API integrations, and CLI tooling, and 30% of Go developers report working on data processing and analytics, compared with Python’s 38%. The analytical end is a different story: Only 15% of Gophers do data science and data analytics, against 32% of Python developers, and the library ecosystem reflects that.

How long does it take a Python developer to learn Go?

Days to weeks for the language itself. The syntax is small, gofmt settles the formatting arguments, and developers we talked to said Go “feels as easy to write as Python”. What takes longer is everything around it: system concepts such as pointers, interfaces, goroutines, and channels, as well as the habits Go asks you to change, from explicit error handling to designing test seams instead of patching at runtime.

The bigger adjustment may not be the language after all. Go work tends to sit closer to Kubernetes, Terraform, and GitOps, so if you’re moving into a Go team from a Python one, budget as much time for learning the toolchain as for the syntax.

Is Go good for machine learning?

For training models, probably not. 20% of Go developers work on artificial intelligence and machine learning, against 36% of Python developers, and the developers we interviewed were blunt about why: Python has the libraries, while Go lacks equivalents.

When it comes to building products around the models, it’s a different story. 46% of Go developers implement AI integrations, against Python’s 44% – a negligible difference. Gophers generally aren’t training the models, but they sure are serving them.

Can Go and Python be used in the same project?

Not only can they be used together, they often are. 27% of Go developers report using Python alongside Go in the same project, behind TypeScript (43%) and just ahead of JavaScript (24%). We know from interviews that the usual division of labor follows each language’s strengths: Go for the networked services and infrastructure, Python for data work, machine learning, and anything that depends on the scientific library stack.

Figuring out how a complex system actually fits together is a classic engineering headache. You can try to figure it out manually (if you have faith in yourself and enough time to spare), or you can use static analysis to explore the codebase (which often fails to capture how services are actually wired together at runtime).

But there’s a third way: dynamic analysis. What if we could just watch the system run and draw the map based on what is actually happening?

Since the OpenTelemetry plugin is already collecting a wealth of runtime data – logs, metrics, and traces – we realized we had the perfect opportunity to auto-generate this architecture map for you. Here’s a look under the hood at the Service Map feature, built as part of a collaboration between the Rider Execution team and Software Engineering Research.

The magic ingredient: traces

If you’re familiar with observability, you know the “three pillars”: logs, metrics, and traces.

While logs tell you what happened and metrics tell you how much, traces show you the journey of a request through your system. Traces are made up of individual units of work called spans.

Because OpenTelemetry standardizes these spans (for instance, explicitly defining HTTP Client and HTTP Server spans), they are the ultimate cheat code for understanding system architecture. Relying on the OpenTelemetry standard means the plugin can visualize your system completely independently of your technology stack, as long as your app and libraries emit spans the way OTel expects.

Building a map from traces has one massive advantage: it’s the source of runtime truth. We aren’t guessing based on source code or outdated specs. We are looking at data generated by the live system.

How it works

So, how does this actually work inside your JetBrains IDE?

When you start your IDE with OpenTelemetry plugin enabled, the plugin starts a lightweight local OpenTelemetry backend that can process your application telemetry data. 

When you hit Run in your IDE: 

1. Plugin provides standard OTel environment variables to the application, so it knows that data should be sent to the local backend.
2. Your app (already configured to emit spans) starts sending telemetry data to our local backend.
3. The backend asynchronously crunches these incoming spans, continuously building and updating an internal model of your architecture.
4. When you click on the Service Map tab, the OpenTelemetry plugin fetches the latest structural model from the backend and renders the visual diagram.

The messy reality of telemetry data

If you look at an architecture diagram, it looks static and orderly. But the stream of telemetry data generating that diagram is anything but. Before we could write an algorithm to connect the dots, we had to solve a few hidden challenges:

Chaos in the wire 

Spans arrive completely independently, and their order is never guaranteed. A parent span might finish and arrive after its child span has already been processed.

No finish line 

A trace never explicitly says “I’m done.” At any given moment, we can never be 100% sure that a late-arriving span isn’t about to show up.

Untyped payloads

OpenTelemetry doesn’t provide a strictly typed version for each span type. Instead, each span carries a key-value map with attributes that describe the semantics of the operation. We had to deduce what kind of interaction they represent purely by inspecting their attributes.

The reconstruction algorithm

To handle this asynchronous, out-of-order data, we built the architecture reconstruction as a stream processing algorithm. Instead of waiting around for a complete trace – which, as we just established, is impossible to guarantee – we process every span the moment it arrives.

First we figure out what we’re looking at. We pull the basic metadata off the span, then inspect its semantic attributes to classify it: attributes such as http.request.method and http.response.status_code tell us it’s an HTTP call, while others point to a database query, a message queue interaction, and so on.

Next we ask which service emitted it. New service we haven’t seen? It goes on the map. Already there? We merge the new data in and update its statistics.

Then comes the interesting part: connecting the dots across service boundaries. A fully instrumented HTTP call has two sides: the calling service emits a CLIENT span, while the receiving service emits a SERVER span. The trace context travels with the request, so the downstream SERVER span is created as a child of the upstream CLIENT span.

So when an outgoing HTTP Client span shows up, we go looking for its child on the server side. When an incoming HTTP Server span shows up, we look for the parent that called it. If the partner span is already in our system, we draw (or update) the connection between the two services right away. If it isn’t, we park the span in memory and wait for its other half to arrive. 

Other kinds of dependencies require slightly different rules. A database call is usually represented by a single CLIENT span, so we infer the database node directly from its semantic attributes. Messaging is more varied: producer and consumer operations may be connected through a parent-child relationship or through span links, depending on the messaging system and instrumentation. In every case, the backend processes spans as they arrive and incrementally enriches the map as more evidence becomes available

That last step is what lets the plugin build an accurate, real-time map, even when the network delivers everything late and out of order.

This way we can process and show you information about http requests, database requests and message queues.

Because the map is built from standard OpenTelemetry spans and the reconstruction algorithm relies on semantic conventions rather than framework-specific APIs, the feature is language- and vendor-agnostic. The same logic works across JVM, .NET, Python, Go, and other OpenTelemetry-instrumented applications, as long as their instrumentation emits the expected spans and propagates context correctly. This also means you can use the feature in the JetBrains IDE that best fits your stack, including IntelliJ IDEA, GoLand, PyCharm, WebStorm, and Rider.

See your own architecture

Want to see your own architecture mapped out in real-time? Expected one HTTP call or database query, but the diagram shows several? Finding that during development gives you time to fix it before release.

You can install the OpenTelemetry plugin right now and stop guessing how your services talk to each other.

This post is the practical follow-up: how to actually use these models, how to fine-tune them on diverse, specialized datasets that look nothing like their training data, and how to evaluate the results – all within PyCharm.

Why fine-tune at all?

Every pretrained detector you download was trained on some distribution of images, almost always COCO, which is ~118k training images of everyday scenes containing 80 common object categories (people, cars, dogs, chairs, etc.).

Real-world deployment data rarely looks like COCO. Things that object detection might actually be applied to, such as damaged industrial cables, bone fractures on X-rays, or densely stacked soda bottles on a shelf, are:

• Out of vocabulary: “Bone fracture” is not one of COCO’s 80 classes, so the model literally has no output category for it.
• Out of visual distribution: X-ray imagery, industrial close-ups, and heavily occluded shelf scenes differ drastically from consumer photos in texture, viewpoint, and object density.

Deploying a detector on off-distribution data therefore requires fine-tuning. But before we break the models, let’s establish that we get similar results on our hardware to the ones reported by developers.

The models

For the purposes of this experiment, we’ll focus on three current SOTA object detection families and examine two sizes of each model:

Sanity check: Reproducing COCO val2017 baselines

We’re going to be working with six pretrained checkpoints: Two different sizes of each of the three models. To check that these models are behaving as expected, we evaluated all of them on the full 5,000-image COCO validation dataset (val2017) to verify the numbers reported in the previous post:

Three things stand out even before we leave COCO behind:

1. Larger models (mostly) have better performance. RF-DETR Base leads (0.5325 mAP50-95), but the medium YOLOs get remarkably close (0.5259 / 0.5181) with ~10M fewer parameters.
2. YOLO26’s NMS-free design pays off in throughput. YOLO26-N is the fastest model in the lineup (12.3 ms latency) at essentially the same mAP50-95 as YOLOv12-N, which, despite being the smallest model here, is considerably slower (23.9 ms latency). Attention is expensive. (If you want more detail on the model architectures and how they affect performance, see the previous blog post in this series.)
3. RF-DETR Nano is not “nano” by parameter count (~30M – more than YOLO26-M), but it is well-optimized: With 12.4 ms latency, it is the second-fastest overall.

Published papers report optimized inference latency: That is, they measure the model’s forward pass in isolation, stripped of the surrounding stages of the object detection pipeline. We deliberately skipped that aggressive optimization so our numbers reflect what you’d actually see when deploying these models.

As a result, our latency figures don’t line up with the benchmarks in the models’ white papers. There are two main reasons for this:

• Hardware: We used different hardware from the NVIDIA T4 GPU that serves as the de facto standard in object detection benchmarking.
• Unoptimized computation graph: We ran the models in their native framework rather than converting them to TensorRT. TensorRT compiles a network into a hardware-specific engine, fusing layers, selecting the fastest kernels for the target GPU, and optionally running in reduced precision. That can cut latency substantially, but the resulting engine is tied to one GPU and requires an extra build step, so it doesn’t represent how these models perform out of the box.

Accuracy is a different story: While our latencies diverge from the published ones, our mAP50-95 results fall within reasonable noise bounds of the reported figures.

Now that we’ve seen what our pretrained models can do on COCO, the dataset they were trained on, let’s see what happens when they’re tested off distribution.

The datasets

For evaluation, we used RF100-VL, a large-scale collection of 100 multimodal datasets covering concepts deliberately chosen to be rare in object detection models’ pretraining data. These datasets contain exactly the off-distribution targets we care about. These targets also mirror common real-life applications for object detection, giving us a realistic test of these models’ capabilities out in the wild.

We picked three datasets that stress test the models in different ways:

Tutorial: Fine-tuning all three models in PyCharm 🙂

Step 1: Setting up the project

One of the first challenges we had to overcome in this project was that the three implementations do not share a compatible set of dependencies. In particular, the two different generations of YOLO require different versions of the ultralytics package. PyCharm offers a clean solution for this: one PyCharm project with three isolated uv environments – one per model family.

We’ll run our computations on a remote GPU. Configuring a remote interpreter in PyCharm follows the same workflow as a local one: the same dialog and the same dropdown as in the local case. Note that remote interpreters require PyCharm Professional; Community Edition supports local environments only.

Firstly, we need to instantiate our three uv virtual environments via:

cd yolov12 && uv venv .venv --python 3.11 

cd yolov26 && uv venv .venv --python 3.11 

cd rf-detr && uv venv .venv --python 3.11

Once your uv virtual environments exist, register each one as an existing interpreter. Go to Settings | Python | Interpreter, click Add Interpreter → Add Local Interpreter, choose Environment as Select existing, and point the interpreter field at that environment’s bin/python. PyCharm doesn’t create anything here, it just picks up the environment uv already built.

Repeat for each environment. From then on, switching is a matter of picking one from the Settings | Python | Interpreter dropdown, or from the interpreter widget in the bottom-right-hand status bar.

You can find the full list of dependencies required for each model in their respective project repositories. You can either install all the projects’ dependencies in PyCharm’s built-in Terminal tool window or install individual packages using the Python Packages tool window (including selecting specific versions of packages). You can access both of these tool windows by clicking the relevant icons in the lower left-hand corner of the PyCharm toolbar. 

For a step-by-step guide on setting up the environments for all three models, see our GitHub implementation of this tutorial.

Step 2: Getting the datasets

To obtain the out-of-COCO-distribution datasets, we can install our datasets via the rf-detr virtual environment, since it has roboflow as one of its core dependencies. We then set the Roboflow API key as an environment variable so that it is available to the API when downloading the datasets.

pip install roboflow

export ROBOFLOW_API_KEY="your_key_here" # you can get API key here: https://docs.roboflow.com/reference/authentication/authentication/find-your-roboflow-api-key 

After setting everything up, now you can run the Python script below to get the three datasets we’re going to use in our tutorial:

import os
from roboflow import Roboflow

api_key = os.environ.get("ROBOFLOW_API_KEY")

if not api_key:
    raise RuntimeError("ROBOFLOW_API_KEY is not set")

DATASETS = [
    "bone-fracture-7fylg",
    "cable-damage",
    "soda-bottles",
]

VERSION = 2          # RF100 projects are generally published at version 2
FORMAT = "yolov8"    # or "coco", "voc", "yolov5"
rf = Roboflow(api_key=api_key)
workspace = rf.workspace("rf100")

for slug in DATASETS:
    print(f"Downloading {slug} ...")

    try:
        project = workspace.project(slug)
        dataset = project.version(VERSION).download(FORMAT)
        print(f"  -> {dataset.location}")

    except Exception as e:
        print(f"  !! failed: {e}")

This script connects to the Roboflow cloud service via its Python API client and downloads three specified RF100 datasets in YOLOv8 format. It loops through each dataset, reports where successful downloads are saved, and prints an error if any download fails.

Step 3: Getting a zero-shot baseline by using pretrained models on custom data

Before fine-tuning, we’re going to evaluate the COCO-pretrained checkpoints directly on our three datasets, to see whether the fine-tuning is actually necessary. The result was unambiguous: The models predicted essentially nothing.

Zero-shot mAP50-95 on the test splits of our three datasets:

This is to be expected; it’s not a bug! As the models are closed-vocabulary detectors, that is, they have a finite number of predefined target classes, they physically cannot output a class like fracture that isn’t in their 80-class COCO head. 

This is the punchline of this whole post: A model scoring 0.72 mAP50 on COCO scores 0.00 on bone fractures. Pretrained ≠ deployable, even when the model is state of the art. Basic machine learning principles still apply, even in the age of AI!

Step 4: Fine-tuning

All models were fine-tuned on a single A100 GPU for 10 epochs. We used standard Ultralytics/RF-DETR fine-tuning pipelines in order to fine-tune the models on our three datasets. We fine-tuned a model for each dataset. The full fine-tuning pipeline can be found in finetune_rf100.py scripts in the project repo, under the folders for each model.

You can see the core of the training setup below. Both YOLO and RF-DETR are built on PyTorch under the hood, but the training loops are abstracted behind higher-level library APIs: Ultralytics’ YOLO.train() for the YOLO models, and RF-DETR’s own train() functionality.

YOLO12 and YOLO26

train_model = YOLO(args.model)

train_res = train_model.train(
                data=str(yaml_path),
                epochs=args.epochs,
                imgsz=args.imgsz,
                batch=args.batch,
                device=args.device,
                project=args.project,
                name=run_name,
                exist_ok=True,
                verbose=False,
            )

RF-DETR

ModelClass().train(
                dataset_dir=str(coco_dir),
                output_dir=str(output_dir),
                epochs=args.epochs,
                batch_size=args.batch_size,
                grad_accum_steps=args.grad_accum,
                lr=args.lr,
                resolution=resolution,
                early_stopping=True,
                checkpoint_interval=1,
            )

Step 5: Results

Fine-tuning transforms the picture. You can see the results on the test set after training:

On the left, we have the pretrained models’ results for the COCO validation dataset. As we showed earlier, accuracy (mAP50-95) fell between 0.39 and 0.53, and all models except for YOLOv12-M showed low latency. The fine-tuned models on the right showed a similar range of accuracy for the cable-damage and soda-bottle detection tasks, only falling lower for the bone-fracture task. Moreover, the fine-tuned models were comparable in latency to the pretrained models for their intended tasks, and for YOLOv12-M, they were even faster. This suggests that, after fine-tuning to the target domain, the models achieve performance that’s broadly comparable to the pretrained performance on their original training domain.

Let’s now have a closer look at the fine-tuned models’ performance, breaking it down by mAP50 and mAP50-95 for the three separate RF-100 datasets:

What the numbers say:

• The soda-bottles target is the easy win. Every model lands in the 0.91–0.97 mAP50 band. This is likely due to the fact that the domain (consumer products in photos) is visually close to existing classes in COCO, so only the vocabulary was new. Interestingly, the attention model family does great here, with YOLOv12-M taking the top spot (0.6422 mAP50-95).
• cable-damage: Detection is easy, but localization is hard. mAP50 reaches 0.93, but mAP50-95 tops out at 0.446. It appears that the models find the damage reliably, yet they struggle to box thin, elongated defects precisely. If your application needs tight boxes at high IoU, this gap would be a significant issue.
• bone-fracture remains genuinely hard. The best model (RF-DETR Base, 0.447 mAP50) is far from production-ready, and the performance spread across models is huge. The modality shift from photos to X-rays means the pretrained backbone features transfer poorly. The different image modality and small, sometimes almost indistinguishable bone fractures make the detection task way harder than the one employed on common objects identification. This is the dataset that would most benefit from domain-specific pretraining, more data, or longer fine-tuning. 
• RF-DETR Base is the most consistent performer, winning on two out of three datasets and challenging seriously for the third. The DETR-style architecture seems to transfer more robustly to unfamiliar domains. 

Qualitative results

To visually assess how these models perform, we can overlay the predicted bounding boxes on the images. Let’s look at the objects our models detected in six random images per class:

We can see this confirms the accuracy values we saw above: The noisy images of soda bottles in fridges are labeled accurately, with tight bounding boxes for each object. The cable damage is identified less consistently, with some models failing to find the damage altogether, and others creating unnecessarily large bounding boxes. Finally, the images of broken bones contrast sharply with the other two, with less than half of the images having any break identified, and different models identifying different potential breakage points.

Conclusions 

Pretrained object detectors are powerful, based on advancements in model architecture over the past five years, but as we’ve seen here, pretrained does not necessarily mean deployable. All six models performed well on COCO, yet when we applied those same checkpoints directly to our specialized datasets, their performance fell close to zero. However, fine-tuning completely changed that picture.

After only 10 epochs of fine-tuning, all three model families were able to adapt well to both the cable-damage and soda-bottle datasets. As we noted, the soda-bottle task was particularly transferable, likely because it contained objects similar to those contained in COCO. cable-damage was also detected relatively reliably, although the larger gap between mAP50 and mAP50-95 showed that precisely locating these tiny defects was still challenging for all of the models. However, bone-fracture was a completely different story, likely because moving from the sort of natural images contained in COCO to X-rays is a much larger domain shift. While RF-DETR handled this jump best, even its performance shows the limits of fine-tuning, and there are times when you might need to consider more data, longer training, or even domain-specific pretraining.

The broader takeaway is that there is no single “best” detector: It is dependent on the task. Model size, latency requirements, licensing restrictions, and most importantly, the similarity between the model’s pretraining data and your target domain all affect the outcome. It is important to refrain from unquestioningly trusting the numbers reported by model providers and explore the fit of a specific model for your own particular task.

Get started with PyCharm today

In this post, we’ve gone from validating pretrained YOLO12, YOLO26, and RF-DETR checkpoints on COCO to testing them zero-shot on specialized data, to fine-tuning them on three very different object detection tasks, and then finally, comparing the resulting accuracy and latency. Along the way, we’ve seen how PyCharm can help manage the practical side of a project like this, where multiple model families require different dependency sets and training environments.

PyCharm helps you keep these workflows together in a single project while using isolated Python environments for each model family. Its interpreter management, built-in terminal, Python Packages tool window, and support for remote development make it easier to move between environments and run training on remote GPU hardware without having to manage each part of this workflow separately.

If you’d like to try these experiments yourself, maybe look into fine-tuning these models for your own specific object detection use case! PyCharm is available to download and try. You can use the accompanying project code to reproduce our COCO baselines, download the RF100 datasets, fine-tune the models, and evaluate them using the held-out test splits.

You can find the full code for this project on GitHub. And if you’d like to learn more about object detection, including the architectures behind the models we used in this post, check out the previous post in this series.

In software, “boring” is a compliment. It means a technology works so reliably you can stop thinking about it. By that standard, Django in 2026 is thriving: PostgreSQL has been the database of choice for 76–79% of respondents for five consecutive years, Django’s template engine has held steady at around 80%, and nearly half of developers upgrade with every stable release — 43% are already on Django 6.0, months after it shipped. The core is boring in the best possible way. Mature, but not static.

Everything around that core, though, is moving fast. AI is now an everyday tool for most developers, and agents are beginning to move beyond answering questions to editing files, running commands, and completing larger tasks. Newer tools are consolidating workflows that once required several separate utilities, typing is becoming standard practice, and the boundaries between editors, terminals, automation, and AI are getting blurrier.

That may be Django’s particular advantage in 2026: it is mature enough to be dependable, active enough to keep moving, and stable enough to give developers room to change almost everything else.

As an open-source framework, Django depends on its community and needs funding to remain healthy and secure. The PyCharm team runs an annual fundraiser to support Django.

Until September 10, get PyCharm at 30% off, and JetBrains will donate 100% of your purchase amount to the Django Software Foundation.

1. AI is mainstream, but no workflow has won

AI has become part of the normal Django development workflow. Only 10% of respondents said they regularly use no AI tools for coding, while 58% of AI users use them every day and another 27% several times a week.

What remains unsettled is how developers use them. The interfaces are split almost evenly across the browser, the IDE, and the command line, and no tool dominates: Claude Code leads at 35%, with ChatGPT just behind at 33% and GitHub Copilot at 23%. And for all the attention on agents, a majority of AI users — 56% — still use it purely for chat and advice.

2. Dominating AI workflow is still supervised

Nearly half of AI users already work with AI through an IDE integration. But despite the growth of coding agents, the dominant workflow is still supervised: 59% have AI generate code and then apply the changes themselves, 44% let it edit files or run commands when instructed, and only 27% use it to autonomously complete multi-step tasks.

The emerging pattern is therefore less “replace the IDE with an agent” and more “bring the agent into the development environment.” Developers are adopting AI quickly, but the editor remains their home base for understanding the codebase, reviewing changes, and deciding what makes it into the project.

Nowhere is the shift clearer than in how developers learn. Django’s official documentation remains the top resource at 67%, but AI tools are now second at 51% — ahead of YouTube, reading source code, and Stack Overflow.

AI is already routine for writing code, debugging, research, and learning. But developers are still experimenting with where it belongs: in the browser, inside the IDE, at the terminal, or increasingly, acting directly on the codebase.

AI is changing the IDE faster than it is replacing it.

3. Python tooling is consolidating fast

Two tools that barely existed a few years ago are already near the top of the survey.

uv, released in February 2024, is already used by 43% of respondents for managing Python environments—second only to venv at 63% and ahead of Docker at 31%.

Ruff tells a similar story. At 43%, it is now the most widely used code-quality and formatting tool in the survey, ahead of IDE inspections at 27%, Black at 25%, pre-commit at 20%, and Flake8 at 17%.

The shift is not that Python’s older tools have disappeared. It is that newer tools increasingly cover jobs that once required several separate utilities. The result is a Python toolchain beginning to consolidate around fewer, faster, more capable tools.

4. Type hints are winning. The type checker race is wide open.

Type hints are becoming the norm in Django development: 57% already use them, and another 26% plan to. What is much less settled is how developers check those types.

Among developers who use type hints, the most popular option isn’t a standalone type checker at all: 40% rely on the checker built into their IDE. Mypy follows at 32%, Ruff at 29%, and Pyright/Pylance at 22%. Newer entrants are already appearing too, with Astral’s ty reaching 12% and Meta’s Pyrefly at 4%.

The practice, in other words, is converging faster than the tooling. Django developers increasingly agree that types are useful, but there is still no consensus on which tool should enforce them—or whether a separate tool is necessary at all.

That makes type checking an interesting space to watch in 2027: will one of the newer standalone tools break away from the pack, or will type checking increasingly become something developers simply expect their IDE to provide?

5. As AI writes more code, verification matters more

AI is moving beyond suggestions and into the codebase. That makes automated verification more important, not less.

The survey can’t tell us whether AI is driving greater adoption of tests or CI. What it does show is that most Django developers already have the infrastructure agents need: pytest is used by 45% of respondents and unittest by 43%, with pytest-django at 34%.

That testing culture sits alongside widespread CI/CD adoption — GitHub Actions is now used by a majority of respondents at 51%, with GitLab CI/CD at another 26%. Together, these create a natural feedback loop for agentic development: an agent can make a change, run the test suite, respond to failures, and hand the developer a result that has already passed the project’s checks.

Not everyone has that loop in place: 19% of respondents write no automated tests at all. As more code is delegated to agents, that fifth of developers is working without the safety net that makes delegation trustworthy.

The emerging agentic workflow may depend as much on verification as generation. The more code we delegate, the more valuable it becomes to have tests and pipelines that can quickly tell both developers and agents whether a change actually works.

Agents can generate code. Tests and pipelines tell them whether it works.

6. One framework, two ways to build

Two distinct ways of building with Django are now firmly mainstream: letting Django render the interface, or using it as the backend for a separate frontend. 72% of respondents use server-rendered templates, while 53% use Django for API-only applications and 46% use it as the backend for a single-page application or dedicated JavaScript frontend.

The balance is even clearer when developers are asked for their primary approach. Half primarily build server-rendered applications, while 44% primarily use Django for either APIs or dedicated JavaScript frontends.

The JavaScript numbers tell the sharper story. React has barely moved in five years — 37% in 2021, 38% today. What’s changed is everything around it: jQuery has fallen from 37% to 23%, Vue from 28% to 17%, while htmx has climbed from just 5% to 34%. htmx isn’t taking share from React — it’s modernizing the server-rendered side of the divide that jQuery used to own.

That flexibility is one of Django’s strengths. The same framework can sit at the center of a hypermedia application or behind an API consumed by React, mobile apps, or other clients.

Django remains unusually comfortable on both sides of the frontend divide.

Conclusion

Across the survey, the pattern is consistent: developers are changing their tools and workflows far faster than they are changing the framework underneath them. The parts of Django they value most remain familiar — models, the admin, authentication — and even deployment stays defiantly unfashionable, with 54% shipping monoliths and 44% self-hosting.

Even where Django itself is evolving, it does so deliberately: 33% of respondents use its async features and another 40% plan to — change offered as an opt-in, not a rewrite.

That stability is increasingly valuable. Developers can experiment with a new agent, replace several tools with Ruff or uv, add htmx to a template, or adopt a new type checker without having to rethink the framework underneath their application.

Django’s advantage in 2026 is not that it is the newest thing. It is that it gives developers a solid, dependable — yes, boring — place from which to try the newest things. Boring is so back.

PyCharm for Django Fundraiser

Get a new PyCharm Pro license or renew your existing one at 30% off, with 100% of your purchase amount going to the Django Software Foundation.

Explore the complete 2026 Django Developers Survey Results.

We contacted affected users directly and took steps to contain the incident.

This post provides the latest information about the incident, its potential impact, and the actions we recommend Cadence users take. We will update it as our investigation progresses and additional information becomes available.

Last updated: September 3, 2026, 19:00 CEST

September 3, 2026, 19:00 CEST

Our investigation has identified additional potential exposure involving storage used by the current Cadence environment.

We confirmed that the threat actor obtained access that could have allowed them to reach storage containing data associated with current Cadence users, including email addresses, project source code, and credentials. This affects the same group of users we previously contacted directly. These findings did not identify any additional affected users. As a precaution, we are treating the data stored there as potentially exposed. 

Our investigation has now concluded. The recommended actions for affected users remain unchanged.

September 1, 2026, 12:05 CEST

Our investigation is nearing completion, and most mitigation and response actions are now finalized. We have not identified any additional compromised resources or data since our last update, and we are wrapping up a small number of remaining verification activities. The recommended actions for affected users remain unchanged.

August 31, 2026, 12:56 CEST

Our investigation remains ongoing. At this time, we have not identified any additional compromised resources or data.

We have confirmed that the threat actor accessed data contained in the Cadence server backup from 2024. At this time, there is no evidence to suggest that the threat actor extracted data, including secrets, from the current Cadence environment.

The recommended actions described below remain unchanged.

August 28, 2026, 11:50 CEST

Cadence was a JetBrains-hosted service integrated with PyCharm through an optional plugin, that let you run your projects on cloud compute resources. Its sunset was announced on March 31, 2026, and the service was scheduled to be shut down on August 31, 2026. Cadence used JetBrains TeamCity to orchestrate this work. We recently disclosed CVE-2026-63077, a critical vulnerability in TeamCity that can allow an unauthenticated attacker to execute arbitrary commands on a vulnerable server.

We have since confirmed the Cadence environment was vulnerable to CVE-2026-63077 and was exploited through this vulnerability.

Cadence users should immediately revoke or rotate all credentials and secrets that may have been used to run their Cadence executions. They should also treat all executions, including their inputs and outputs in your Cadence project, as potentially untrusted.

Actions required immediately

We strongly recommend that Cadence users:

• Revoke and rotate all credentials and secrets that may have been used to run Cadence executions.
• Review connected systems for suspicious activity, particularly AWS accounts, S3 buckets, deployment environments, package/container registries, and other systems accessible using credentials mentioned above.
• Review source code repositories for unauthorized changes made during the affected period.
• Review any source code or project files synchronized to Cadence from PyCharm and rotate any credentials, tokens, or other sensitive information contained within them.
• Treat all executions, including their inputs and outputs in your Cadence project, as potentially untrusted.

Cadence users can contact us to request an inventory of the credentials and secrets associated with their Cadence usage. This may help users identify which credentials need to be revoked or rotated, but the inventory should not be considered exhaustive.

We have collated a list of Indicators of Compromise (IoCs) below. These indicators are not exhaustive, and the absence of these indicators does not confirm that an account or system was unaffected:

• Activity occurring from August 8, 2026, onwards, particularly authentication or activity using credentials previously stored in or accessible through Cadence.
• IP addresses associated with observed exploitation activity:
  • 150.109.230.104
  • 43.153.227.206
  • 62.210.127.48
  • 210.247.242.190
  • 15.235.225.205
  • 152.233.30.18
• Authentication or other activity from unexpected IP addresses or locations.
• Unexpected repository clones or downloads, and unexpected commits to repositories.
• Changes to repository secrets, webhooks, collaborators, or permissions.
• New or modified personal access tokens, API tokens, or SSH keys in external services.
• New service accounts created in external services.
• Unexpected changes to cloud IAM roles, policies, or permissions.
• Unexpected access to cloud storage, including S3 buckets and objects, in services such as AWS and Google Cloud.
• Unexpected publication or modification of packages or releases.

Affected server

We have confirmed that the following Cadence server was successfully exploited: api.cadence.jetbrains.com.

Affected period

August 8, 2026, to August 24, 2026.

What happened

The Cadence server used TeamCity to orchestrate workloads and was vulnerable to CVE-2026-63077. Threat actors exploited the vulnerability and gained unauthorized access to the affected Cadence environments, with activity identified from August 8, 2026. We discovered the exploitation on August 23, 2026, and took the affected server offline on August 24, 2026, while we continued our investigation.

What we know

Our investigation is ongoing, but we have confirmed that the threat actors:

• Accessed personal data and extracted it from the affected environment. Confirmed affected personal data includes usernames, real names, email addresses, last-login timestamps, and last accessed IP addresses.
• Compromised a full backup of the Cadence server dating from 2024. This means credentials, configuration, artifacts, logs, or other data present in that backup must also be treated as potentially exposed.
• Compromised multiple AWS IAM users and associated credentials/secrets used with Cadence, including IAM users belonging to JetBrains employees who used the service. These credentials were present in the compromised 2024 backup.
• Accessed files stored in S3 buckets within JetBrains AWS accounts used by Cadence. We are still determining the full scope of the data accessed. We do not currently know whether the threat actors accessed storage buckets in customer accounts. However, some users may have configured Cadence to access their own storage buckets, and the credentials used for those connections may have also been exposed.
• May have accessed source code synchronized from PyCharm projects to the affected server. If you used PyCharm to upload or synchronize project files for execution in Cadence, you should treat that code, and any credentials or configuration contained within it, as potentially compromised.

The likely consequences of the personal data exposure include an increased risk of targeted phishing, social engineering, impersonation, and other unsolicited or malicious communications using the affected names and email addresses.

As the threat actors gained access to the Cadence server, any credentials or secrets stored in Cadence, contained in the compromised backup, or made available to executions on the affected server should be considered compromised and must be revoked or rotated.

This includes but is not limited to:

• Cloud credentials, including AWS, Azure, and Google Cloud.
• Source control credentials and tokens, including GitHub, GitLab, and Bitbucket.
• Package repository credentials, including npm, Maven, NuGet, PyPI, and similar services.
• Container registry credentials, including Docker Hub, ECR, GCR, ACR, and other registries.
• Slack tokens, webhooks, API tokens, SSH/deployment keys, service account credentials, signing keys/certificates, and credentials for any other external systems used by your Cadence executions.

Actions JetBrains has taken

We took the Cadence server offline on August 24, 2026, while we continue to investigate the incident. At present, we have confirmed that the incident is limited to data associated with the Cadence host mentioned above.

The server should have been patched as part of our response to the vulnerability, but it was not. We sincerely apologize for this failure and the impact it may have on you.

We have invalidated all access tokens used by the JetBrains Cadence plugin in PyCharm to connect to Cadence, and took the server offline on August 24, 2026.

We are also notifying the relevant authorities and taking the necessary steps to protect the data of Cadence users.

Further updates

We will publish further findings and guidance here as our investigation progresses. We recommend checking this page frequently for the latest information. We will also contact affected users directly if we identify any important new information that may require action on their part.

For more information about the underlying vulnerability, please see our original security advisory to TeamCity customers and users.

If you previously used Cadence and need assistance identifying which credentials may have been exposed or have any questions regarding this incident, contact the JetBrains Security team at security@jetbrains.com.

We recognize the seriousness of this incident and apologize again for the impact.

The OpenTelemetry plugin has broken out of the confines of JetBrains Rider. No sandbox exploit was involved – this escape was planned by our developers. With the 2026.2 release, the OpenTelemetry plugin is now available in IntelliJ IDEA, GoLand, PyCharm and WebStorm. Rider users needn’t worry – it still works there too.

The plugin brings logs, metrics, traces, and the service map from local applications into the IDE. You can inspect them without setting up a separate local observability backend.

What is the OpenTelemetry plugin?

While developing with your IDE, you can use the plugin to:

• Find what happened immediately before an error.
• See which services and dependencies a request reached.
• Pinpoint where a request spent its time.
• Check whether the application emitted the expected logs, metrics, and traces.
• Ask your coding agent to do all of the above via MCP.

The plugin’s functionality complements what the IDE offers out of the box. Use a debugger to step through code, a profiler to analyze performance, and a production monitoring platform to watch deployed systems. Use the OpenTelemetry plugin to inspect runtime behavior while you build or test the application.

Imagine this

Say you are testing a feature that calls several services and a database before publishing a message to a queue. The request fails, and the console shows the exception, but not the path that led to it.

In the OpenTelemetry tool window, you can search the logs for the error. Open the relevant trace to see how the request moved through the system and where it failed. The Service Map shows the services and infrastructure involved.

Explore runtime data in the IDE

Search and inspect logs

Console output is manageable until several services start writing at once. The Logs view puts OpenTelemetry log records in a searchable table. You can filter by severity or content, then open a record to inspect its attributes.

Check metrics

Select a metric from the metric tree to plot its values while you use the application. This view is not a replacement for your production dashboards, but it lets you inspect what the application will export before you send the data to a production observability platform. If a new library adds noisy or unnecessary metrics, you can catch them locally and adjust the instrumentation before your DevOps and SRE colleagues have to handle them.

Follow a request through its trace

Open a trace to see its spans across services. Each span includes timing and attributes, so you can follow the request from start to finish and zero in on the operation that failed or slowed things down. Development is also a good time to look at the trace itself. Does it contain the spans and details you’d need during a real incident? It’s much easier to fix those gaps now than to discover them in production.

See observed relationships in the Service Map

Architecture diagrams go stale. The Service Map builds its relationships from collected traces, so it reflects the traffic the plugin has seen between services, endpoints, databases, and message queues.

Expected one HTTP call or database query, but the diagram shows several? Finding that during development gives you time to fix it before release.

Connect an instrumented application

The plugin does not add OpenTelemetry libraries or agents to your application. It configures where an already instrumented application sends its data.

Start an instrumented Java, Python, Go, or .NET application from a supported IDE run configuration, and the plugin passes OpenTelemetry Protocol (OTLP) environment variables that point to its built-in receiver. It passes the same variables to new integrated terminal sessions.

You can also point the application’s OTLP exporter at the endpoint shown by the plugin. If you already use a local OpenTelemetry Collector, add the plugin as an OTLP destination and keep the rest of your pipeline.

Runtime context for coding agents

The plugin has experimental MCP support through the JetBrains MCP server. A compatible coding agent can query the telemetry collected in the IDE with these tools:

• get_log_records
• get_spans
• get_services
• get_service_map

These tools give the agent evidence from a particular run, so that it can inspect the logs and spans or query the observed service relationships.

Getting started

1. Install the OpenTelemetry plugin from JetBrains Marketplace for your favorite IDE.
2. Instrument your application with OpenTelemetry libraries or agents.
3. Start it from a supported IDE run configuration or a new integrated terminal session. The plugin will pass the OTLP environment variables. Alternatively, point the application’s exporter or your local collector at the endpoint shown by the plugin.
4. Open the OpenTelemetry tool window and exercise the part of the application you want to inspect.

The plugin shows the signals it receives. If your application exports only traces, the Logs and Metrics views stay empty.

Full setup instructions are available in the OpenTelemetry plugin documentation.

Install it and tell us what you find

Try it on a real project, then tell us in the comments or through the issue tracker what worked and what still sent you to another tool.

Some final notes

This plugin is the product of a collaborative effort between the Rider Execution team and the Dynamic Program Analysis Research team at JetBrains Research. This launch is the first step in exploring how telemetry analysis can help us build development tools that better adapt to real-world developer workflows.

That makes your IDE more important, not less. PyCharm gives you the freedom to choose the agents and models you want, as well as extensive Python and Django support for understanding and reviewing the code they produce.

1. Bring your own agent

Leading agents such as Codex, Claude Agent, Junie, and Gemini run natively in PyCharm, while the ACP registry gives you access to dozens more, installable in a click from the same dropdown menu. You can use a JetBrains AI subscription or bring your own tools – the choice is yours.

Want to use your own model? Bring Your Own Key technology lets you connect existing provider credentials, while Ollama and LM Studio let you work with local models.

You choose the AI tools that fit your workflow. PyCharm doesn’t lock you into one provider.

2. Teach your agent your conventions

Skills give your agent reusable instructions and context. In PyCharm 2026.2, native skill support for Claude Agent and Codex lets you add a skill directly from the AI chat, either for a single project or across your entire codebase.

The curated Skill Repository also gives you a way to add official skills for technologies, including React, Postgres, and Playwright.

Skills let you encode useful context once and reuse it, so you spend less time repeating instructions to your agents.

3. Django 6+ support

PyCharm keeps up with Django’s release cycle, including Django 6.0 template partials. The IDE understands the new partial template tags and completes them as you type.

This matters especially when frameworks evolve. An agent’s training data may not reflect the exact Django version you’re running. PyCharm’s Django support is tied to the version in your project.

4. Review with confidence

AI generates code quickly, which makes reviewing and undoing changes more important than ever.

PyCharm gives you visual diffs, merge tools, integrated conflict resolution, and Git history in the IDE, so you can inspect changes before committing or merging.

Local History works independently of version control, recording changes as you work. You can compare a file with an earlier state and restore a version from before the agent touched it – even if you never committed the change.

5. See your Django architecture

Django applications can get big. Django Logical Structure presents your project from Django’s point of view rather than as a flat collection of Python and HTML files. You can follow a model to its serializer, its views, and the endpoints they serve.

Whether the code you’re reading was written by you six months ago, another developer, or an agent, PyCharm helps you understand how the pieces fit together.

6. Verify your API and your data

The Endpoints tool window gives you a structured view of your Django endpoints, including documentation, examples, generated HTTP requests, and OpenAPI information. You can send those requests directly with the built-in HTTP Client.

The same idea applies to your database. The data editor and viewer let you browse and query application data without leaving the IDE. After an agent generates a migration, you can inspect the resulting data and verify that the change did what you expected.

The IDE outlasts the agent

AI tooling is changing fast, but your developer workflow can stay consistent. PyCharm combines deep Python and Django support with access to the agents and models you choose.

Get 30% off PyCharm, and JetBrains will donate 100% of what you pay to the Django Software Foundation.

SQLAlchemy 2.0 support

SQLAlchemy has been a long-standing source of false positives – enough that several duplicate tickets have accumulated over the years. This release resolves a batch of them for the 2.0 style.

String forward-references inside Mapped[...] resolve correctly:

posts: Mapped[list["Post"]] = relationship(back_populates="author")

# "Post" now resolves to the model class

PyCharm also correctly infers the mapped type returned by Session.get(), instead of treating the result as the model class itself:

report = session.get(Report, report_id)

reveal_type(report)  # was: type[Report] | None   now: Report | None

Modern hybrid_property setters written as @name.inplace.setter are recognized, so assigning to the property no longer produces a warning. Model class attributes defined via mixins are picked up again, too, clearing the old unexpected argument reports on model constructors.

(PY-78816, PY-65142, PY-59732, PY-51906, PY-28762)

Code insight and type inference

Control-flow narrowing and “unreachable code”

Several false This code is unreachable reports and instances of lost narrowing across loops have been fixed. The common issue: flow analysis either gave up or over-eagerly narrowed to Never in branches it should have kept alive.

isinstance on a numeric union no longer kills the else branch:

def foo(y: int | float) -> None:

    if isinstance(y, float):

        pass

    else:

        print(y)  # was flagged unreachable, y inferred as Never

Narrowing also survives a while loop, so re-narrowing an optional attribute inside the loop body no longer reports a bogus has no attribute error.

(PY-83206, PY-83354, PY-88265)

Strings inside type annotations

A string used as metadata inside Annotated[...] – a Pydantic discriminator field name, for instance – is no longer parsed as a forward reference and flagged as unresolved.

(PY-48749, PY-82245)

Iterable unpacking and star expressions

PyCharm’s analysis of tuple and star unpacking could lose type information and fall back to Any. Unpacking a starred value into a tuple lost its element types, *-expansion collapsed to Any, and several genuine errors went unreported. Starred expressions preserve their element types:

def a() -> tuple[int, int]:

    return 2, 3

def b() -> tuple[int, int, int]:

    return (1, *a())  # no more bogus "Expected tuple[int, int, int]"

(PY-12592, PY-27205, PY-43585, PY-90219)

Augmented assignment

A cluster of false positives came from augmented assignments being misanalyzed. A simple /= on an int produced the wrong type:

foo = 5

foo /= 2

reveal_type(foo)  # was: int   now: float | int

(PY-80622)

Self and constructor return types

Self binds correctly through classmethod parameters typed as type[Self]:

class A:

    @classmethod

    def bar(cls, y: type[Self]) -> Self: ...

x = A.bar(A)      # was a spurious "Expected type[A], got type[A]"

reveal_type(x)    # was: Any   now: A

Construction also respects __new__, __init__, and metaclass __call__. When __new__ returns something other than an instance, that’s the constructed type – even when an __init__ is present. The same fix covers explicitly parameterized calls like MyClass[int]() and __new__ assigned as a class attribute.

(PY-89296, PY-77611, PY-88644, PY-89571)

Enum members: Literal types for .value and .name

Reading an enum member’s .value or .name yields a precise Literal instead of a widened str or int, so assignments to Literal[...] target type-check. This matches mypy’s inference:

from enum import Enum

from typing import Literal

class E(Enum):

    a = "a"

b: Literal["a"] = E.a.value   # was: Expected 'Literal["a"]', got 'str'

n: Literal["a"] = E.a.name    # .name is a Literal too

(PY-61028, PY-79198)

Parameter types inferred from decorators

When a decorator constrains the callable it accepts, the decorated function’s parameters are inferred from that constraint instead of falling back to Any:

from typing import Callable

def d(fn: Callable[[int], str]): ...

@d

def f(a):

    reveal_type(a)   # was: Any   now: int

(PY-79204)

Also fixed

• Keyword arguments in a class header are validated against the base class’s __init_subclass__ signature, and offered in completion (PY-79173).
• An ellipsis in a Callable used as a PEP 695 type-parameter bound no longer reports a bogus Invalid type expression (PY-83570).
• Type-checker findings are split into granular suppression codes rather than a single PyTypeChecker id, and # noinspection directives accept a simplified name form. PyTypeChecker still works as a blanket ignore (PY-90265).

Completion and auto-import

Smarter auto-import 

Auto-import is now noticeably less noisy. Previously, if a module was already imported, PyCharm would offer to add a second, redundant import instead of qualifying through the one you already had. The quick-fix – and the completion popup – prefer to reuse the existing import.

Given pkg/src.py containing MyClass, and a file that already imports the module, Alt+Enter produces this:

from pkg import src  # no longer flagged as unused

src.MyClass

instead of adding from pkg.src import MyClass. The same reuse logic applies to plain import pkg.src, and to the auto-import completion on a second Ctrl+Space.

Nested classes can be auto-imported too, which is something PyCharm didn’t previously support:

# mod.py

class Outer:

    class Inner:

        pass

# main.py – Alt+Enter on Inner now offers "Import Outer from mod"

from mod import Outer

value = Outer.Inner()

(PY-87970, PY-87971, PY-87972, PY-88009, PY-88016)

Completion for unittest.mock.patch() targets

Patching by string target previously offered no code assistance, so dotted paths had to be entered manually. The string argument to mock.patch(...) gets code completion for modules, classes, and their attributes, and it no longer suggests the invalid as keyword mid-path:

from unittest import mock

# sample.py defines: class Foo: my_attr = 42

with mock.patch("sample.Foo.my_attr", 14):

    ...

# completion now offers `sample`, `Foo`, and `my_attr`

(PY-89189, PY-89191, PY-89192)

Typed signatures when overriding built-in methods

Completing an override of a dunder or built-in method fills in the full annotated signature – and auto-imports the types it needs – instead of bare parameters:

from types import TracebackType

class A:

    def __exit__(self, exc_type: type[BaseException] | None,

                 exc_val: BaseException | None,

                 exc_tb: TracebackType | None): ...

# was: def __exit__(self, exc_type, exc_val, exc_tb):

(PY-79218)

Editor and inspections

Type inlay hints

Inferred type arguments are shown inline at the call site, so you can see what a generic resolved to without hovering over it:

class A[T]:

    def __init__(self, t: T): ...

A[int](1)     # [int] shown as an inlay hint

Type names rendered inside inlay hints – return types and solved arguments alike – are also clickable, so you can jump straight to a type’s definition from the hint.

(PY-90411, PY-90293)

f-string format-spec validation

PyCharm already validated the str.format() mini-language. Those checks apply to f-strings too, and PyCharm flags formatting a type that doesn’t implement __format__:

data = 1

f"{data:.2f}"   # ok

f"{data:.2q}"   # now flagged: unsupported format spec

class A: ...

f"{A():d}"      # now flagged: A doesn't support the 'd' format

(PY-51322, PY-89760)

Refactoring

The Rename refactoring also updates references to a module when the module itself is renamed. Previously, the renaming left importing sites pointing at the old name:

# rename provider/provider_module.py → some_module.py

from ..provider import provider_module  # this reference is updated too

(PY-53274)

The Refactor | Field action is now Attribute, and the documentation says “instance attributes” to match Python terminology (PY-85828).

Conclusion

Taken together, these changes make PyCharm’s understanding of Python more precise and predictable: fewer false positives, better type inference, smarter completion, and less time spent working around cases where the IDE gets valid code wrong.

Many of these improvements started with real-world examples reported by users. If PyCharm still misunderstands a typing pattern, framework API, or other valid Python code in your project, let us know in YouTrack – a small reproducer can help us turn that friction into the next fix.

Try PyCharm 2026.2 and let us know which improvements make the biggest difference for your workflow.

Thank you for using PyCharm!

The course is now available and uses PyCharm and its AI Chat. Here’s a peek into the course.

Claude Code: Subagents and cheaper models

We start the course with, well, not-local. Instead, we use what you already know – Claude Code and its Anthropic models – to introduce some of the techniques and “levers” that help bring choice, control, and even cost reduction. (Yes, I wrote emdashes.)

We did a previous course on Spec-Driven Development (SDD) so of course, we wanted to start there. Smaller models struggle with big, open-ended “vibe coding.” Dividing and bounding the work keeps smaller models on track. Important note: this course’s example app is really basic. You might say “that’s too easy.” But that’s part of the takeaway: big brain models can do the upfront work, forming right-sized steps for smaller models.

We then illustrate this division with a Claude Code subagent. The main chat prompt implements each roadmap phase in a fresh subagent, to better manage context. This then gives the payoff: a cheaper model for the implementer. Use a “big brain” (Opus) for main conversation thinking and a “little brain” (Haiku) for implementation.

Each lesson finishes with metrics about the change in tokens, turns, cost, and estimated wall time. Which brings us to the main course goal: learning the ideas instead of the specifics, which change weekly.

New agent, inference, and model

That covers the four levers:

• Specs shaped for the model size
• Specialist subagents to divide work
• Cheaper models for the routine work
• Collect metrics as evidence to guide thinking

The course then introduces choice and control:

• New agent: OpenCode
• New inference router: OpenRouter
• New model and inference host: DeepSeek (via OpenRouter) by moving to a new agent (OpenCode) using inference routing (OpenRouter) to inference hosting and models (DeepSeek)

We first move to OpenCode, running in PyCharm. JetBrains wants our IDEs to be open platforms for agents and models. This makes the move from Claude Code to OpenCode straightforward: it’s the same UI. We add OpenRouter (a paid step), connect it to OpenCode, and choose DeepSeek as a model.

Next we repeat our sequence: all in one chat, then context isolation using a subagent. But this time, with a different agent and model.

We finish by making a dedicated implementer subagent in Markdown. This gives quite a number of levers of control: in the frontmatter for mandatory controls, and in the subagent body for “persuasion” guidance. Most importantly, we have the implementer use the smaller DeepSeek v4 Flash model as the “little brain.”

Compared to the Claude Code version, the metrics were, unsurprisingly, a lot cheaper.

Hybrid and Local

Now for the main attraction: for routine development, can we do some – or even all – of the work locally?

We start with a lesson on setting up local AI: LM Studio as the inference server and Gemma 4 12B as the local model, targeting a 32 GB laptop.

We then configure the implementer subagent to use this local Gemma 4 model, promoting DeepSeek v4 Flash from last lesson’s “little brain” up to “big brain.” The results? Quite good, as it turns out.

Then the big test: fully local, with Qwen 3.5 27B as the “big brain.” The results: better than expected, showing that guardrails help.

How did hybrid and local do? Both of these lessons finish with a review of the metrics. That’s one of the big course takeaways: look at the evidence. You can see how small models struggle, and see the effect of helping them succeed.

Hybrid and Local AI Are Heating Up

Much thanks to DeepLearning.AI both for working with us again and for pushing to get this out fast. This topic is now red-hot in the news: Sovereign AI, privacy and security, and of course cost. The innovations are coming really fast and it is important to have a gentle introduction to the fundamentals.

We’ll do more updates here on Local AI for control, choice, and cost. Most of all, we at PyCharm believe in the human-in-the-loop. Stay tuned for more on this.

We’re also welcoming marimo notebooks into the IDE and introducing changes to bundled plugins to keep PyCharm fast and focused.

Release highlights

Jupyter notebook skill for AI agents

Let AI agents such as Claude Code and Codex create, edit, and run .ipynb notebooks via PyCharm’s notebook model and a live kernel, so variables, models, and data persist across cells instead of disappearing when the agent shells out. For you, this means more reliable notebook and ML work – with fewer tokens used. To start, just open the AI chat and ask the agent to work in your notebook.

Agent environment coordinator

Tired of AI agents installing packages into the wrong Python environment? This new skill gives the agent your project’s configured interpreter and tool – uv, Poetry, pip in a venv, or conda – so commands target the right environment, not a system one. If none exists, it can set one up via PyCharm, and the agent decides how to use the information. To start, ask the agent to run or install something in your project.

marimo notebooks in PyCharm [third-party plugin]

You can now open, edit, and run marimo notebooks directly in PyCharm with the new plugin developed by the marimo team. 

Work with reactive cells and interactive UI elements in a dedicated notebook without leaving your IDE. Because marimo notebooks are stored as Python files, they are Git-friendly, executable as scripts, and easy to integrate into your existing Python projects.

Changes to bundled plugins in 2026.2

As part of ongoing maintenance, we are unbundling and deprecating low-usage plugins, including Data Wrangler, Hugging Face, and Google Colab support. You can continue to install compatible versions from JetBrains Marketplace, but these plugins are no longer bundled or actively maintained by the PyCharm team. A more focused set of bundled plugins means a leaner codebase, helping us keep PyCharm fast and responsive and invest our effort where it has the most impact.

Redesigned Python Packages tool window

• Packages now appear in a collapsible tree alongside their dependencies so you can see what’s installed and why – with new icons, right-aligned versions, and inline Install/Update links.
• A new floating search popup (think “Search Everywhere” but for packages) makes finding and installing fast. It also shows you which environment will be used and lets you pick a module and dependency group.
• You can install a package into specific uv/Poetry dependency groups like dev or test per workspace member, change versions inline or through the new Change Version dialog, and install from VCS via Custom Installation.
• Package repositories can be enabled or disabled, with state remembered across sessions. In addition, unreachable URLs show a clear error, and Remote Development support is substantially improved.

Clearer type checking

Get clearer, more actionable type messages:

• Richer type-mismatch errors, now with a breakdown of why the types don’t match.
• A type diff for callables and other composite types, so both sides read the same way.
• Fully rendered names and types in inspection tooltips, with clickable links.

Bug fixes

• Virtual environments for end-of-life Python: PyCharm no longer creates venvs for Python 2.7, 3.6, and 3.7. You can still create a new env from a command line and add it to the IDE manually.
• SQLAlchemy 2.0 Session.get() inference: Session.get(Entity, id) (and SQLModel) is now inferred as a model instance rather than the class.

Download PyCharm

All of these updates are available in PyCharm 2026.2.1. Update right from the IDE or the Toolbox App, or download the latest version to try everything out on your own projects. As always, we’d love to hear your feedback.