How JetBrains Uses AI to Ship Better Software Faster

Most companies chasing “AI for developers” get fixated on one thing: code generation speed. JetBrains is taking a stricter stance—AI only matters if it helps teams ship software that’s safe, readable, and maintainable.

That’s why JetBrains’ integration of OpenAI models across its products and internal workflows is a useful case study for our series, How AI Is Powering Technology and Digital Services in the United States. Developer tools sit at the center of the U.S. digital economy: every SaaS app, fintech platform, healthcare portal, and logistics system depends on engineering teams staying productive without sacrificing reliability.

JetBrains’ reach makes this especially relevant. The company’s IDEs and toolchain are used by roughly 15 million professional developers globally, including engineers at 88 of the Fortune 100, and it created Kotlin, the official language for Android. When a platform like that changes how “work happens” for developers, the downstream impact shows up everywhere—especially in U.S. tech companies scaling digital services.

JetBrains’ AI strategy: protect flow, don’t just autocomplete

JetBrains’ approach is straightforward: use AI to reduce friction where developers lose time and attention, not to “replace” engineers.

Kris Kang, Head of Product at JetBrains, frames the core idea clearly:

“Developers don’t just write code. They review it, reason about it, and design systems. AI can help with the parts beyond simply typing.”

That’s the right framing, and it’s why the AI conversation is shifting from “faster typing” to better decision-making under constraints. In real teams, the slow parts aren’t usually keystrokes—they’re:

• Understanding legacy code you didn’t write
• Translating fuzzy requirements into crisp behavior
• Keeping tests aligned with code changes
• Reviewing pull requests under time pressure
• Debugging multi-service issues with partial context

JetBrains’ thesis: if AI reduces context switching and raises the quality of engineering work, speed follows naturally.

The tool mix: ChatGPT, GPT‑5, Codex (and agents)

JetBrains uses OpenAI models in multiple ways:

• Internally: teams use ChatGPT, GPT‑5, and Codex to support day-to-day engineering work
• Externally: customers can select GPT‑5 inside Junie (JetBrains’ coding agent) and AI Assistant (chat support inside the IDE)

What’s notable here is the split between chat and agents:

• Chat helps you answer questions and draft code in the moment.
• Agents take on multi-step tasks with more autonomy.

Kang’s line nails the difference:

“Chat gives you a lift. Agents give you a step-change.”

For U.S.-based tech teams that ship weekly (or daily), that “step-change” isn’t about replacing headcount—it’s about increasing throughput without making the codebase brittle.

Speed vs. quality: why JetBrains is right to measure both

JetBrains evaluates AI impact through two lenses:

• Speed: less boilerplate, fewer context switches, faster iteration
• Quality: code that is readable, reviewable, safe, and maintainable

I’m opinionated here: quality has to be the primary metric, because speed without quality is just deferred failure. In digital services, defects aren’t abstract—they become:

• customer churn
• security incidents
• broken billing flows
• downtime during peak usage
• on-call burnout

Practical “quality checks” for AI-generated code

If you’re adopting AI-assisted coding in a U.S. software organization, here are checks that actually hold up in real code reviews:

1. Is the behavior specified? If a ticket is vague, AI will “fill in the blanks” with plausible but wrong assumptions.
2. Is the change test-backed? AI can draft tests quickly, but teams must enforce that tests assert the right behavior.
3. Is the code idiomatic for the repo? “Technically works” isn’t enough; it needs to match patterns your team maintains.
4. Is it safe by default? Watch for insecure defaults (auth bypass, injection risks, unsafe deserialization).
5. Can a human maintain it next quarter? If reviewers can’t explain it, it’s a long-term liability.

This is where JetBrains’ DNA—developer experience and correctness—matters. IDEs already encode “what good looks like” through inspections, refactoring tools, and static analysis. Adding AI on top should amplify those guardrails, not bypass them.

Where AI delivers the most value: friction points beyond typing

JetBrains highlights a leadership lesson many teams miss: start where humans feel friction—documentation, tests, reviews, and hand-offs.

That’s also where AI has the clearest ROI for digital services, because it improves the system of delivery, not just a single developer’s output.

Documentation that stays alive

Outdated docs are a classic failure mode in U.S. product teams. AI can help by:

• Drafting module-level docs from code structure
• Generating “what changed and why” notes directly from diffs
• Producing onboarding summaries for new engineers

A useful internal standard I’ve seen work: every meaningful PR includes an AI-drafted change summary that the author edits. It’s small, but it reduces review time and makes future debugging easier.

Tests that match intent (not just coverage)

AI can write tests quickly, but your process must force alignment with intent:

• Use AI to propose test cases (happy path, edge cases, negative cases)
• Require the developer to select and justify which cases matter
• Treat “snapshot-y” tests with suspicion unless they protect UI contracts

For SaaS and digital services, this is gold because it lowers the cost of change. Teams ship more often when they trust their test suite.

Code review and PR throughput

JetBrains is explicit: developers review and reason as much as they write.

A practical workflow many teams adopt with AI inside IDEs:

• Ask AI to flag risky areas in a diff (auth, money movement, data deletion)
• Ask AI to propose reviewer questions (“what could go wrong?”)
• Ask AI to translate complex changes into plain language for cross-functional partners

That last piece matters more than people admit. In U.S. companies, engineering velocity is frequently blocked by misalignment across product, security, compliance, and operations.

Agents in the IDE: what changes when tasks get delegated

Agents are the most consequential shift because they allow developers to delegate work that’s annoying, repetitive, or time-consuming.

Kang describes assigning “increasingly difficult tasks” to an agent backed by GPT‑5 and being surprised at how many complete successfully. That matches what I’ve seen: agents are great at bounded tasks with clear definition.

The best tasks to hand to an agent

If you’re evaluating an AI coding agent (in JetBrains or elsewhere), start with tasks that meet three criteria: clear scope, measurable outcome, limited blast radius.

Good examples:

• Add logging around a specific workflow
• Implement a small internal tool or script
• Migrate a deprecated API call across a few files
• Create a new endpoint that follows an existing pattern
• Draft a set of unit tests for an existing function

Less suitable early on:

• Re-architecting a distributed system
• “Make it faster” performance work without profiling data
• Security-sensitive authentication/authorization changes without strict review

Guardrails that keep agents useful (and safe)

Agent adoption fails when teams treat it like magic. It works when teams treat it like a junior teammate who’s fast but needs direction.

Guardrails worth implementing:

• Definition of done that includes tests and linting
• Small PR limits (cap changes by files/lines until trust is built)
• Mandatory human review for security and payment flows
• Structured prompts embedded into tickets (inputs/outputs, constraints, non-goals)

Here’s a snippet-worthy rule I like:

If you can’t describe the task precisely, don’t delegate it to an agent—clarify it first.

What this means for AI-powered digital services in the U.S.

JetBrains is not just adding AI features; it’s shaping how software gets built. For U.S. companies delivering digital services at scale, that matters for three reasons.

1) Developer workflow improvements compound

When AI reduces context switching, improves docs, strengthens tests, and speeds reviews, the benefits don’t show up once—they compound across:

• every sprint
• every release
• every incident response
• every new hire’s ramp-up

That’s why Kang’s point about experimentation is so practical:

“Those who experiment well with AI will see compounding advantages over time.”

2) “Hybrid workflows” are the real operating model

JetBrains pushes a hybrid model: AI drafts; humans design and review. That’s the operating model that fits regulated industries and high-availability services common in the U.S. market.

Hybrid is also how you prevent the two predictable failures of AI-assisted development:

• shipping plausible-but-wrong behavior
• accumulating unmaintainable code debt

3) Fundamentals matter more, not less

AI raises the premium on fundamentals: architecture, intent, clear interfaces, and strong specifications.

A team with vague tickets and weak tests will get faster at producing confusion. A team with clear intent and strong review culture will get faster at producing durable software.

A practical adoption plan you can copy next week

If you’re leading engineering or product at a U.S. tech company and want outcomes like JetBrains is optimizing for, start with a small, structured rollout.

1. Pick one workflow: PR summaries, test generation, or doc updates.
2. Set a quality bar: readability, maintainability, and test requirements.
3. Measure two numbers for 2–4 weeks:
   • PR cycle time (open → merged)
   • post-merge defects (bugs, rollbacks, hotfixes)
4. Introduce agent use for bounded tasks with PR size limits.
5. Codify prompts and guardrails into templates so success is repeatable.

If you only measure “lines of code” or “tickets closed,” you’ll miss the real value.

Where this is headed in 2026: engineers as designers and agent wranglers

JetBrains’ vision of what’s next is blunt: developers will spend more time designing systems, guiding agents, reviewing, and reasoning—not doing less work, doing better work.

That aligns with what many U.S. digital service teams need right now: shipping faster without turning reliability into a coin flip. AI in developer tools is becoming a baseline expectation, but the winners will be the teams that treat AI as a force multiplier for good engineering habits.

If you’re planning your 2026 roadmap, here’s the question I’d use to pressure-test it: Are you investing in AI features that increase trust in what ships—or just increasing output?