Standalone CLI agents vs an IDE integrated AI coding agent for Kotlin on a large legacy codebase (Claude Code, Cursor, Codex, and Junie /ide) comparison
when i run a terminal AI coding agent on a self-contained service or a greenfield script, ripgrep plus a big context window is usually enough to get a clean patch. i wanted to share a comparison sheet i put together for our backend team while we were evaluating an AI coding agent for large codebases, specifically comparing standalone terminal/editor setups against an IDE integrated AI coding agent using the public benchmark numbers and current documentation for Claude Code, Cursor, OpenAI Codex, and JetBrains Junie.
even on the public 105-task Kotlin benchmark across real issues from ktlint, detekt, ort, and okhttp (where the agents ran inside isolated Docker containers with only bash tools and no IDE connected), pure CLI agents did great. those benchmark runs used an earlier model generation (Opus 4.7 and GPT-5.5), and Claude Code (Opus 4.7) took first place solving 90 / 105 tasks (10.59M avg tokens, ~118K per task), while JetBrains Junie (Opus 4.7) and OpenAI Codex (GPT-5.5) tied at 86 / 105 (Junie used 19.98M tokens vs Codex's 38.78M for the same solve count; Cursor wasn't included in that 105-task run).
where that headless container setup stops matching my day-to-day experience is when you need an AI coding agent for legacy code on a 10-year-old multi-module Java, Kotlin, and SQL repository. if you are looking for an AI coding agent for Java developers or an AI coding agent for Kotlin on an older monolith, a NullPointerException in OrderProcessor is usually caused by a constructor-injected bean in a Spring Configuration class three modules away that only returns null under a specific profile, or a method name that is overloaded 14 times across different packages. if an AI agent for debugging code only has text search or chunked vector embeddings, it spends 10 minutes grepping the file tree, misses an overload in a test fixture, or spams temporary println logs across eight files while acting as an AI coding agent that runs tests in a loop to figure out why a build failed.
here is the side-by-side sheet i made of how Claude Code, Cursor, OpenAI Codex, and Junie (specifically when Junie CLI is connected to a running IDE via /ide or run via the IDE plugin) handle context, refactoring, debugging, and database schemas on a large legacy codebase:
Workflow Dimension on Large / Legacy Repos Claude Code (CLI + LSP Plugins) Cursor (Standalone Editor + CLI / ACP) OpenAI Codex (CLI + codex exec) JetBrains Junie (IDE Plugin or CLI /ide Bridge)
Headless Container Baseline (105-Task Kotlin Eval) 90 / 105 solved (85.71%) · 10.59M avg tokens (Opus 4.7 xhigh — #1 solve rate & token efficiency) Not included in the 105-task Kotlin Benchmark run 86 / 105 solved (81.90%) · 38.78M avg tokens (GPT-5.5 xHigh — tied #2 solve rate) 86 / 105 solved (81.90%) · 19.98M avg tokens (Opus 4.7 max — tied #2 solve rate, ~1/2 of Codex's tokens)
How It Resolves Symbols & Call Graphs Connects to language server (LSP) plugins for definitions, references, and post-edit type errors; falls back to file search Queries an automatic semantic embeddings index + fast literal text search (or runs a subset inside JetBrains IDEs via ACP) Reads files and greps on demand through shell tools; relies on compiler/test runs to catch broken references Passively tracks open files/recent edits and queries the running IDE's AST symbol index (Find Usages, inheritance hierarchy, at-mention class/symbol completion) on demand via /ide
Multi-File Refactoring Generates coordinated text edits across files and checks types via LSP Generates multi-file diffs from semantic/text search results; verification relies on your test suite and diff review Generates text edits across files and validates by running the build Calls the IDE's native refactoring engine (resolving overloaded methods and scope through the compiler's project model) an
Источник: reddit.com ↗when i run a terminal AI coding agent on a self-contained service or a greenfield script, ripgrep plus a big context window is usually enough to get a clean patch. i wanted to share a comparison sheet i put together for our backend team while we were evaluating an AI coding agent for large codebases, specifically comparing standalone terminal/editor setups against an IDE integrated AI coding agent using the public benchmark numbers and current documentation for Claude Code, Cursor, OpenAI Codex, and JetBrains Junie.
even on the public 105-task Kotlin benchmark across real issues from ktlint, detekt, ort, and okhttp (where the agents ran inside isolated Docker containers with only bash tools and no IDE connected), pure CLI agents did great. those benchmark runs used an earlier model generation (Opus 4.7 and GPT-5.5), and Claude Code (Opus 4.7) took first place solving 90 / 105 tasks (10.59M avg tokens, ~118K per task), while JetBrains Junie (Opus 4.7) and OpenAI Codex (GPT-5.5) tied at 86 / 105 (Junie used 19.98M tokens vs Codex's 38.78M for the same solve count; Cursor wasn't included in that 105-task run).
where that headless container setup stops matching my day-to-day experience is when you need an AI coding agent for legacy code on a 10-year-old multi-module Java, Kotlin, and SQL repository. if you are looking for an AI coding agent for Java developers or an AI coding agent for Kotlin on an older monolith, a NullPointerException in OrderProcessor is usually caused by a constructor-injected bean in a Spring Configuration class three modules away that only returns null under a specific profile, or a method name that is overloaded 14 times across different packages. if an AI agent for debugging code only has text search or chunked vector embeddings, it spends 10 minutes grepping the file tree, misses an overload in a test fixture, or spams temporary println logs across eight files while acting as an AI coding agent that runs tests in a loop to figure out why a build failed.
here is the side-by-side sheet i made of how Claude Code, Cursor, OpenAI Codex, and Junie (specifically when Junie CLI is connected to a running IDE via /ide or run via the IDE plugin) handle context, refactoring, debugging, and database schemas on a large legacy codebase:
Workflow Dimension on Large / Legacy Repos Claude Code (CLI + LSP Plugins) Cursor (Standalone Editor + CLI / ACP) OpenAI Codex (CLI + codex exec) JetBrains Junie (IDE Plugin or CLI /ide Bridge)
Headless Container Baseline (105-Task Kotlin Eval) 90 / 105 solved (85.71%) · 10.59M avg tokens (Opus 4.7 xhigh — #1 solve rate & token efficiency) Not included in the 105-task Kotlin Benchmark run 86 / 105 solved (81.90%) · 38.78M avg tokens (GPT-5.5 xHigh — tied #2 solve rate) 86 / 105 solved (81.90%) · 19.98M avg tokens (Opus 4.7 max — tied #2 solve rate, ~1/2 of Codex's tokens)
How It Resolves Symbols & Call Graphs Connects to language server (LSP) plugins for definitions, references, and post-edit type errors; falls back to file search Queries an automatic semantic embeddings index + fast literal text search (or runs a subset inside JetBrains IDEs via ACP) Reads files and greps on demand through shell tools; relies on compiler/test runs to catch broken references Passively tracks open files/recent edits and queries the running IDE's AST symbol index (Find Usages, inheritance hierarchy, at-mention class/symbol completion) on demand via /ide
Multi-File Refactoring Generates coordinated text edits across files and checks types via LSP Generates multi-file diffs from semantic/text search results; verification relies on your test suite and diff review Generates text edits across files and validates by running the build Calls the IDE's native refactoring engine (resolving overloaded methods and scope through the compiler's project model) an