When developers hear “AI in the IDE”, the first thing that often comes to mind is a chat window. IntelliJ IDEA includes an AI chat, but JetBrains AI features also appear in many other parts of the development workflow.

Some of those features are easy to miss because they are built into existing IDE actions: editing code, generating code in place, explaining selected code, working with stack traces, writing commit messages, and choosing which model or agent should handle a task. This overview focuses on five AI features in IntelliJ IDEA that are worth knowing about, with a few additional capabilities explained at the end. The list starts with one that can help before you even open the chat.

1. AI completion

You change a line, and the IDE points out the next line that needs to be changed to match. Rename a field, and it walks you to the other places that reference it, one keystroke at a time. Press Tab to jump to the spot, and Tab again to accept the edit. Ordinary completion guesses what should follow directly under your cursor. This type looks a step ahead, at the edit you haven’t made yet.

It runs on JetBrains’ own models, tuned for coding, and it stays out of your way. Fix the spacing after one comma in a parameter list, and it will offer to fix every other comma in the file. On a larger scale, this is also where full-method generation is handled – the editor has enough local shape to fill in a method body without turning the task into a chat session.

The feature is easiest to understand in small edits. Change one line, and IntelliJ IDEA suggests the next related change in the file.

2. In-editor code generation

Press Ctrl+\ anywhere in a file, type what you want in plain words, like “turn this loop into a stream” or “give me a builder for this class”, and the code appears right there at the cursor. The code lands in place, and you never have to switch to a chat to copy an answer back out of a conversation.

For a small, well-scoped change, the convenience is that the prompt starts where the edit happens. You type the instruction in the editor, review the generated code in place, and keep moving.

The generated code appears as an in-editor diff, so you can accept it, reject it, or refine the prompt. If the first version misses a constraint, add more context, ,like  “Keep the method name” or “use Optional instead of null”. IntelliJ IDEA regenerates the code with the extra information and shows the new diff in the same place.

It is the hidden gem in the list – a general-purpose prompt you can invoke at the cursor for small, arbitrary edits, without opening the AI chat or copying code back into the file.

3. AI Actions

AI Actions is the menu for people who never want to have a conversation with our model. Select a piece of code, press Alt+Enter, and choose from a variety of useful actions – no chat required.

Explain Code takes a regex you didn’t write, a SQL query someone left you, or a cron expression, and tells you in plain English what it does. Generate Unit Tests opens the tests in a diff, so you can argue with them before they land in your project. Generate Documentation writes the doc comment for a public method. These actions keep you in the file. Point at your chosen code, pick an action, and get an actionable response immediately.

4. Bring your own agent

At some point, the task stops being a single editor action. It needs file changes, tests, and a diff you can review. Through the Agent Client Protocol (ACP), you connect an external coding agent and drive it from the same place where you already inspect files, diffs, tests, and problems. Think of ACP as the LSP for agents: one protocol, so the IDE doesn’t need a custom integration for every new agent that appears next month. JetBrains’ own agent, Junie, shows up in the same registry as the third-party agents and receives no special treatment.

You ask the agent to change one endpoint. It proposes the steps, edits the service and the test, runs the test command, and leaves you with a diff you can open from the chat before accepting anything. That is the IDE part of the story. The agent can act, but the review still happens where you already review code.

Skills sit next to that. A skill is a reusable capability you set up once: triaging a CI failure, working through PR comments, converting Java to Kotlin, or nudging an agent away from the usual Spring Data JPA pagination mistake. You add skills from the + menu in the chat, and supported agents can use them without you having to retype the same long set of instructions every time.

That is where the IDE demonstrates its worth. The agent can make a series of edits, but you can inspect each one as it appears – open the affected files, check test outputs, and review diffs before accepting anything. The chat, code, and review stay in the same window, making it easier to stay in control while the agent handles the mechanical work.

5. Bring Your Own Key

Once agents are in the IDE, the next decision is more straightforward – which provider your organization allows the IDE to call. Bring Your Own Key (BYOK) enables you to add the API key or endpoint for any provider your team already uses.

A configured key can sit behind the AI chat and selected IDE features, such as commit message generation, depending on what features the provider and model support. For some teams, the ability to use a provider that has already passed internal review matters more than support for the one at the top of the current model leaderboard. 

You can configure your keys in Settings | Tools | AI Assistant | Providers & API keys. Choose a provider under Third-party AI providers, enter the key or endpoint, and test the connection. Once it is connected, the provider’s models will appear in the AI chat’s model selector.

Beyond the top five

Aside from the top five headline features, a couple of smaller capabilities are still worth knowing about because they appear where the IDE already has context.

When the stack trace is already in the console

The run console is where optimism goes for a reality check. When your app throws an error and the stack trace lands there, the Explain with AI action is on hand. The IDE reads the trace and then gives you a likely cause and a suggested fix. That is a better use of thirty seconds than pasting the top line into a search engine and opening three tabs from 2017.

When the staged diff needs a sentence

Generate Commit Message reads your staged diff and writes the message for you. Edit it, commit, and move on. It is a small feature, but it is exactly the kind you keep using once you know it exists.

The part you may have missed

The AI Chat window is still here, and has gotten more interesting with agents and skills. The easy-to-miss part is the layer of AI-powered productivity features around it: edits suggested as you type, code generated at the cursor, explanations for selected code and stack traces, and commit messages written from the staged diff.

The final effect is boring in the best way: IntelliJ IDEA, doing a little more than it used to, without making a ceremony out of it.

If you tried AI Assistant a year ago and mostly remember the chat, this is the part you may have missed.

Agent Skills have become a key building block of the Agent Harness for AI-driven agentic development. They give AI agents additional capabilities and knowledge, enabling them to complete tasks in a way that aligns with your preferences.

If you are new to Agent Skills, I recommend reading AI-Assisted Java Application Development with Agent Skills first.

IntelliJ IDEA and other JetBrains IDEs include AI Assistant, which helps developers with AI agentic development. AI Assistant provides an elegant and secure way to use and manage Agent Skills.

If you missed the announcement, see Introducing the Skill Manager and Skill Repository.

In this article, we will explore:

• How to install Agent Skills via the Skills Manager.
• Managing skills with the Skill Repository.
• Installing skills globally, per project, or per agent.
• Adding your own Skill Repository.

Skills Manager

AI Assistant supports a wide range of AI agents through ACP (Agent Client Protocol).

The Skills Manager in AI Assistant lets you view the list of available skills and install them.

If you have already installed Agent Skills globally, the Skills Manager detects them and helps you install them as IntelliJ IDEA agent skills.

You can install a skill globally, at the project level, or per agent.

Skill Repositories

The Skill Repository lets you manage a list of locations where your verified skills are stored.

By default, JetBrains provides a Skill Repository hosted at https://github.com/JetBrains/skills.

These skills are verified by JetBrains for security vulnerabilities.

It is essential to check for security issues before using agent skills downloaded from the internet. A better approach is to maintain an organization-wide Skill Repository, verified by your team, and add it to the Skill Repository list.

Agent Skills in action

Based on the prompt description, the AI agent automatically detects and uses relevant agent skills.

For example, I installed spring-boot-skill, and when I asked the AI agent to write tests for Spring Boot REST API endpoints, it used the spring-boot-skill.

You can also explicitly invoke an agent skill using $skill-name [prompt] with Codex or `/skill-name [prompt]` with Claude.

Summary

AI Assistant’s Skills Manager makes agent skills part of your regular IDE workflow. You can discover, install, and manage skills without leaving IntelliJ IDEA, then make them available globally, for a specific project, or only to a particular AI agent. The AI agent can automatically select a relevant skill from your prompt, while explicit invocation gives you control when you need it.

Just as importantly, the Skill Repository provides access to skills verified by JetBrains for security vulnerabilities. Teams can also add their own repositories containing internally reviewed skills. This makes it easier to benefit from reusable agent capabilities while maintaining control over which skills developers use in their projects.

Autonomous coding agents ignore contribution rules in open source communities, finds a new study from researchers at Peking University. 

That’s not great news for maintainers who are fast becoming overrun by sloppy AI-generated contributions. If coding agents aren’t even following contributor guidelines, then a simple rewrite isn’t going to do much good for reining in agent activity. 

The study experiments on four frontier models, curating 106 issues from 49 repositories containing AI contribution rules and then judging each run against the repository’s rules. Researchers measured four forms of compliance: 1) refusal to contribute; 2) truthful disclosure of its assistance; 3) clearing verification gates; 4) escalation to humans. 

How’d the agents perform? Not well. As the researchers wrote, “today’s agents almost never proactively retrieve the contribution rules.”

With some prodding via reminder prompts, quoted policies, and verifier feedback, the agents did improve on disclosure and verification — but they never refused to contribute to AI-banned repositories.

Christian-Alexandru Staicu, senior security researcher, Endor Labs, describes the conflict as an “ethical dilemma” for the agent:  

“Imagine that an agent is asked to ‘fix an annoying bug and make a pull request’ to a project that has the clause listed in Figure 1 of the study, ‘This project does not accept pull requests that are fully or predominantly AI-generated,’” Staicu tells The New Stack. “Now the agent is in an ethical dilemma. Should they comply with the user’s request or with the policy?” 

Agents aren’t not listening. They’re just hyper-focused on the task at hand.

Pointing to the recent Hugging Face incident, where autonomous AI systems escaped a sandbox and breached the production infrastructure, Mike McNeil, CEO, Fleet Device Management, and founder, The Sails Company, reminds developers that agents don’t always follow prompts, which is why they might fail to respect repository-specific contribution rules. 

“Disclosure and verification are additive: The agent can complete the user’s task and comply. A ban requires the agent to abandon the task, which collides head-on with the user’s explicit instruction and with the agent’s training to be helpful.”

“The AI is very focused on trying to do its prime directive,” he tells The New Stack. “It wants to get the task that it’s been given done, and as we saw with Hugging Face, it’s willing to do anything to get that done.”

Analyzing contribution policies is simply not part of how agents are typically built and trained, says Staicu: “Agents almost never open the policy files on their own, so the rules never enter their reasoning at all.”

Still, why do reminders, quoted policies, and feedback help push agents to respect disclosure and verification requirements but not those for AI bans and escalation? Staicu tells The New Stack the difference is in the rule’s ultimate impact on the task: 

“Disclosure and verification are additive: The agent can complete the user’s task and comply. A ban requires the agent to abandon the task, which collides head-on with the user’s explicit instruction and with the agent’s training to be helpful.”

In other words, the agent doesn’t abide by some rules that tell it to give up because it’s so hard-wired to get the task done. 

Timo Bozsolik-Torres, head of AI, SandboxAQ, agrees, saying that the behavior isn’t a question of whether or not the agent understands the rules: “If this were a comprehension problem, a stronger model would close the gap. Instead, the opposite happens; GPT-5.5, the best model tested, is also the most stubborn refuser.”

Does this mean rewriting contribution policies is a waste of time? What else maintainers can do

In a move to curb AI slop, Godot Engine, the open-source game engine, is rewriting its contribution policy to bar most AI-generated code from its repositories. It’s not alone. Programming language Zig and terminal emulator Ghostty are also updating policies to control AI use in contributions. 

But if the Peking University study shows that coding agents, when acting autonomously, largely ignore contribution guidelines, then simply rewriting policy may not be enough. 

Instead, experts advise putting controls outside the agent.

“Stop expecting the model to remember to go read CONTRIBUTING.md and instead make policy discovery part of the harness, as opposed to the model’s judgment call,” says Staicu.

That may help agents proactively retrieve contribution rules, but what about AI bans, which agents dismiss, even when reminded? “Labs would need to go further,” Staicu acknowledges, “and fine-tune models with reinforcement learning, explicitly penalizing policy violations.”

Bozsolik-Torres suggests a simpler control: “Don’t give the agent a create_pr tool call it’s allowed to make against a repo flagged as banned.” He also says maintainers can route AI-flagged PRs for heavier reviews by default.

Another common strategy is to include an AGENTS.md file in repositories to tell agents how to behave, but some poo-poo this idea, too. Jeffrey Paul, VP of open source solutions, Fueled, tells The New Stack: “Sadly, these instructions tend to be regurgitated from other human-based files in repos,” he says, “which means that documentation for humans and agents is duplicated and requires maintainers to update things in multiple places.” 

Instead, he’s been experimenting with a different approach, using an ~/.agents/AGENTS.md file locally and then copying that content directly into whichever agentic tool he’s using. “This way, I maintain a single local file,” he explains, “and then as I shift tools, I ensure that I update that tool’s specific user-level agent instructions file.”

Paul admits that this approach doesn’t have a 100% success rate but says it does a better job of ensuring the agent looks for and respects repo-specific contribution guidelines.

Existing SDLC controls should do most of the heavy lifting 

When asked for his take on what maintainers can do to enforce contribution rules, McNeil indicates that enforcement doesn’t need to be overly complicated, pointing to code owners as a longstanding way to control merges. 

“At the end of the day, the repository is already protected if you have a proper SDLC in place.”

“That’s a classic control that we’ve used pre-AI for humans, [where] only approved people can merge in code,” he says. “And those are truly deterministic,” he adds. “You can’t break them without an admin login to GitHub.”

In this way, McNeil seems to be advocating for a return to basics to control AI-generated contributions, explaining that linting and CI/CD processes already act as checks to control merges. “The SDLC [software development lifecycle] continues to be the same systems that we’ve already used and trusted for other kinds of non-deterministic contribution from the humankind,” he says. “At the end of the day, the repository is already protected if you have a proper SDLC in place.”

Though the Peking University study’s findings may startle maintainers, they’re also a helpful reminder. If your SDLC is already doing its job, then you don’t need to count on autonomous agents policing themselves. 

The post Coding agents ignore open source contribution guidelines, researchers find. appeared first on The New Stack.

Everything I am doing with the Spectral ruleset format right now is a move I have watched work before, and I want to write down how it worked, because the people arguing with me about it are making the same argument that was made in 2012.

Swagger did not start life as a specification. It started as a configuration file. It was the thing that told the code generator and the documentation UI what to render — a serialization of one tool’s internal model, useful precisely because those tools were useful. The people who created it were building tooling, and the file was a byproduct of the tooling. That is not a criticism. That is how almost every important format in our industry begins.

And then a group of us started saying, out loud and repeatedly, that this thing needed to be a format in its own right. Not a config file for a code generator. A document you could write without ever touching that code generator, that another vendor could implement against, that you could cite in a contract, that could outlive whoever happened to be maintaining the tool that read it first.

The pushback then sounded exactly like the pushback now. Why would you separate it — the tool works. Nobody is asking for a spec, they are asking for features. A specification is paperwork; the code is the truth. If you want it to do something different, send a pull request.

That argument was wrong, and it took roughly 2012 to 2014 to prove it wrong. The elevation of the spec was the single most consequential thing that happened to that format, and everything after it — the donation, the rename to OpenAPI, the initiative, the second and third and tenth implementations, the whole industry that now assumes an API has a machine-readable description — was the continuation of one decision. A format that exists independently of its tool can be adopted by people who do not use the tool. That is the entire mechanism. There is nothing else to it.

I bring this up because I am watching the identical situation, one layer up the stack, with the rules people write to govern those descriptions.

The Spectral ruleset format is, today, exactly what Swagger was in 2011: a configuration file for one program. It is described nowhere except in that program’s source, its meta-schemas are internal implementation detail coupled to that program’s runtime, and the only available definition of a valid ruleset is “whatever the linter accepts this week.” Meanwhile that config file has escaped its container completely. It is what national governments write their mandatory API design rules in. It is what large vendors run inside their governance products. It is what a dozen tools I have built — registries, baselines, scorecards, coverage reports, waiver reconcilers, federation layers — have to parse, merge, publish, and reason about.

Every single one of those tools had to answer the same question: what exactly is a valid ruleset? And every one of them answered it by reading somebody else’s source code. That is a workable answer for one tool. It is not a workable answer for a registry that publishes rulesets, or a federation layer that merges them, or a certification tool that has to prove what was checked, or an agent export that has to translate them into something else entirely.

So the move is the same move. Lift the format out. Write it down normatively — not “here is what happens when you write given as an array,” but “an implementation MUST treat an array given as a set of independent path expressions.” Give it a conformance definition, a public test suite, a versioning policy, and a stable identity that is safe to cite. Let the tool become one implementation among several, and let the several be measured against the document rather than against each other’s bugs.

There is a difference worth naming between then and now, and it cuts in favor of moving faster. In 2012 there was essentially one implementation and a nascent ecosystem, and elevating the spec was mostly an act of faith about what would come. Today there are already multiple engines, at least two hyperscaler-adjacent products embedding the format, national standards written in it, and an entire category of in-house implementations nobody can see. The ecosystem showed up first this time. The specification is not getting ahead of adoption — it is running years behind it.

The second difference is less comfortable. Swagger’s elevation happened while the company behind it was still actively investing in it, which made the donation a decision somebody could take. That is not the situation here, and it is why the work is happening from outside rather than inside. I would still rather it happen inside; the invitation I made publicly in January 2025 to donate the linter to the OpenAPI Initiative stands, and it would make most of what I am doing unnecessary.

But the lesson from the first time around is that you do not wait for permission to write down what people are already depending on. Nobody asked permission in 2012 either. A group of people decided the config file was actually a format, started treating it like one in public, and kept treating it like one until enough of the industry agreed that the question stopped being interesting.

That is the whole play. It worked once, on something far more consequential than a linting format, and the argument against it has not gotten any better in fourteen years.

The API security problems we have now are not new. Broken object-level authorization–the flaw where your API happily hands over record 1002 to someone who was only ever supposed to see record 1001, because it checked that you were logged in but never checked that the record was yours–has topped the API security lists for years. We have known about it, written about it, and built entire tooling categories around it. What has changed is not the vulnerability. What has changed is who is knocking on the door, how fast, and how many times.

A human attacker exploiting a broken-authorization flaw has to work at human speed. They enumerate identifiers by hand, or script something clumsy, and there is friction and time and noise at every step. An agent has none of that friction. Point automation at an API with a broken object-level check and it will walk the entire keyspace–every record, every ID, every field you accidentally left reachable–faster than your monitoring can raise an eyebrow. The flaw that used to leak a handful of records to a determined human now drains the whole table before lunch. Same bug. Radically different blast radius.

I brought up Optus in my Nordic APIs conversation for a reason, because it is the concrete version of this abstract fear. In 2022, an exposed API with insufficient authorization controls leaked the personal data of millions of Optus customers. That breach did not require exotic tooling or a nation-state–it required an API that trusted the caller more than it should have, and a caller willing to iterate. Now imagine that same class of flaw in a world where iterating is the default behavior of every agent on the network, where automation is cheap, tireless, and everywhere. The Optus-shaped hole was bad enough at human speed. Agents are the speed multiplier we did not have in 2022.

And it is not only malicious actors you have to design for, which is the part teams keep underweighting. A perfectly well-intentioned agent, wired up by a perfectly well-intentioned developer, can hammer your API thousands of times a second, ignore the rate limits you thought were advisory, retry aggressively on errors, and blow straight past the access patterns your contract quietly assumed everyone would respect. It is not attacking you. It is just doing what it was told, at a scale no human integrator would ever have generated by hand. The faulty agent and the malicious one produce remarkably similar traffic, and your infrastructure has to survive both without being able to tell them apart in the moment.

This is the shift I want teams to internalize: the agentic world does not introduce a new category of API vulnerability so much as it removes the friction that was silently protecting you from the ones you already have. All those latent flaws–the missing authorization check, the endpoint that returns more fields than it should, the rate limit that was never really enforced, the contract you assumed people would honor–were survivable partly because exploiting them at scale was tedious. Agents delete the tedium. The security debt you have been carrying because “nobody’s actually going to sit there and enumerate all of it” just met something that will absolutely sit there and enumerate all of it, without getting bored.

So the defensive work is not glamorous and it is not new–it is the fundamentals, finally taken seriously because the cost of skipping them just went up. Check authorization at the object level, on every request, for every record, no exceptions. Return only the fields the caller is entitled to, never the convenient superset. Enforce rate limits as real limits, not polite suggestions, and assume every consumer is capable of machine-speed traffic whether or not they mean any harm. Treat your API contract as something that will be tested to its literal edges, because it will be. The agents are not going to be more careful than your weakest authorization check. They are going to find it, at speed, and the only thing standing between that and the next Optus headline is whether you did the boring work before they got there.

Nathan Sobo joins Scott and Wes to explain why Zed was built in Rust, how GPUI works, and what happens to editors once agents write most of the code. They also talk about DeltaDB, Zed’s new Git-compatible version control system, and Delta, the collaborative agentic editor it powers.

Show Notes

• 00:00 Start
• 00:35 Welcom to Syntax
• 01:13 The Journey to Zed: Building the Ultimate Tool
• 03:26 Why Rust was chosen for Zed?
• 06:29 Brought to you by Sentry!
• 07:07 Building a UI from scratch in Rust
  • GPUI
• 15:55 AI’s role in coding and development
• 18:42 The role of text editors in the age of AI
• 21:52 Delta DB: The vision for collaborative development
  • DeltaDB
• 29:06 The Evolution of Collaborative Coding
• 44:45 The Future of User Interfaces
• 52:42 Sick Picks + Shameless Plugs

Sick Picks

• Scott:
• Wes:
• Nathan Sobo:
  • Keychron Q11
  • Grant Green - Idle Moments

Shameless Plugs

• Scott:
• Wes:
• Nathan Sobo:
  • DeltaDB

Hit us up on Socials!

Syntax: X Instagram Tiktok LinkedIn Threads

Wes: X Instagram Tiktok LinkedIn Threads

Scott: X Instagram Tiktok LinkedIn Threads

Randy: X Instagram YouTube Threads

Download audio: https://traffic.megaphone.fm/FSI5646050512.mp3