CLI agents (Claude Code, Codex) as primary

CLI agents - Claude Code, OpenAI Codex CLI, Aider, and similar tools - run in your terminal rather than inside an IDE plugin. This architectural difference is more significant than it appears. A CLI agent is a programmable tool: it can be invoked by scripts, chained into workflows, run in CI/CD pipelines, triggered by git hooks, and executed in remote environments without a graphical IDE. An IDE plugin is a convenience feature; a CLI agent is infrastructure.

At L3 (Systematic), CLI agents become primary - not supplementary. The developer's main AI interaction is no longer the chat sidebar or inline suggestions, but a terminal session where they describe tasks, the agent executes them, and the developer reviews results. The IDE still exists (with Copilot still running for inline assistance), but the high-leverage work happens in the CLI.

Claude Code is the canonical example: run claude in your project root, give it a task, and it uses tools to read files, make edits, run tests, and iterate until the task is complete. As of March 2026, Claude Code also supports Computer Use (interacting with GUIs, browsers, and desktop applications) and Auto Mode (dynamically choosing between tool use strategies), extending CLI agents beyond pure code tasks into full-environment automation. OpenAI's original Codex CLI is no longer actively developed - OpenAI shifted investment to Codex integrated within ChatGPT, which operates as a cloud-hosted agent rather than a local CLI tool. Aider supports multiple backends and is especially strong for pair-programming style interaction. Gemini Code Assist Agent Mode, now GA on IntelliJ (and other JetBrains IDEs), blurs the CLI/IDE boundary by offering terminal-grade agentic capabilities from within the IDE. All of these tools share the same core architecture: a language model with tool access, running autonomously.

By June 2026, the same CLI architecture also runs on self-hostable open-weight models, which makes a locally-run agent a credible primary path rather than a fallback. Z.ai's GLM-5.2 (MIT-licensed, ~June 13) beat GPT-5.5 on SWE-bench Pro at roughly one-sixth the cost; Kimi K2.7-Code (Moonshot, June 12) shipped with day-one vLLM/SGLang support; and DeepSeek V4 now leads open-weight SWE-bench. All of them run through llama.cpp, vLLM, or Ollama and plug into the same CLI-agent loop as hosted models. The sovereignty case got concrete the same week: Anthropic's hosted Fable 5 and Mythos 5 launched June 9 and were disabled worldwide June 12 under a US export-control order. Fable 5 was restored July 1 after the export controls lifted June 30, but the three-week outage proved the point: teams that depend on a CLI agent for primary work should keep a self-hostable model wired into the same workflow so a single vendor or policy change cannot stall delivery.

July 2026 refreshed the entire model layer underneath these harnesses. Claude Opus 5 (July 24, $5/$25 per 1M tokens, low/medium/high effort toggle) became the new Claude Code default, marketed as near-Fable performance at half the price. GPT-5.6 went GA July 9 in Sol/Terra/Luna tiers, with Sol 54% more token-efficient on coding and a 1.05M context window. Grok 4.5 (July 16, $2/$6) shipped with Grok Build, a terminal agent whose agent loop is open-sourced and speaks the Agent Client Protocol, and Zhipu released the ZCode harness for GLM-5.2 (July 6). The more important shift is the dominant usage pattern that emerged with them: model routing, or "frontier plans, cheap executes." Cursor's Router/Auto (July 22) exposes Intelligence/Balance/Cost modes; open-weight GLM-5.2, Kimi K2.7-Code, and DeepSeek V4 increasingly serve as cheap execution workers under a frontier planner; and the mixmod demo of GPT-5.5 supervising local Qwen workers cut frontier-token spend by 75.5%. At L3, "which model" is becoming a routing policy inside the CLI harness, not a single procurement decision.

August then inverted that routing policy in four weeks. Anthropic made Sonnet 5's introductory pricing permanent on August 10, cancelling the scheduled 1 September rise from $2/$10 to $3/$15 per MTok, and retired Claude Opus 4.1 from the first-party API on August 5. OpenAI cut GPT-5.6 Sol from $5/$30 to $4/$20 on August 21, promotional through at least November 21, having already cut Luna about 80% to $0.20/$1.20 and Terra about 20% to $2.00/$12.00 on July 30. Grok 4.6 arrived on August 12 with a 500K context at $2/$6 and an Artificial Analysis Intelligence Index of 61, tied with GPT-5.6 Sol - the cheapest frontier-class coding model of the month. Meta shipped its first coding agent, Muse Code, on August 5: terminal-native on macOS and Linux, built on Muse Spark 1.2 with a 1M context, spawning subagents in isolated git worktrees, priced at $1.25 in / $0.15 cached / $4.25 out per MTok and still in beta. Even the open-weight floor moved. DeepSeek V4 Pro (August 13, roughly 671B total / 37B active MoE, MIT, 1M context) shipped with an API price increase, ending DeepSeek's role as the automatic cheap option, while Qwen3.8-Max (August 3, 2.4T total / 95B active, text weights released August 12) and GLM-5.3 (August 14, roughly 753B/40B, claiming about a 50% coding gain over 5.2 - a vendor claim) moved into the space it vacated. The practice implication is blunt: any routing config written in July is now wrong. Re-cost every workload, and put the next re-costing in the calendar before you close the spreadsheet.

The structural change underneath the prices matters more than any single one of them. deepseek-ai/deepseek-harness went public on August 13 under MIT - command name dsh, Node.js, developer preview - the same day V4 Pro went GA, and its organising idea is that everything is a plugin: the model adapter, the tool registry, the session log and the agent loop itself are all replaceable. A satellite ecosystem of web UIs, desktop shells, context dashboards and agent-team layers formed around it within weeks. Read alongside Shopify's July 29 conclusion that after five months of model swaps the harness, not the model, is the durable asset, this turns a vague preference into a concrete L3 maturity test: can you swap the model underneath your CLI agent without rewriting the harness above it?

The adoption baseline moved too. JetBrains' 2026 Developer Ecosystem Survey (15,000+ professional developers, fielded May to July across eight languages) reports 90% using AI coding agents at work at least weekly and 68% daily, with Claude Code at 39% tool share (up from 18% in January 2026), GitHub Copilot at 21% (down from 29%), Codex at 16% (up from 3%) and Cursor at 12% (down from 18%). Claude Code is the primary tool for 31% of respondents. JetBrains competes in this market, so read the shares with that in mind - but it is the largest public sample available, and it says CLI-first is now the majority position rather than the advanced one.

The "primary" designation at L3 reflects a workflow inversion. At L1-L2, developers write code and occasionally use AI to help. At L3, developers describe what they want and the agent writes code, with the developer reviewing and steering. The human role shifts from implementer to orchestrator.

The move to CLI-first agents is the inflection point where AI assistance becomes systematically integrated rather than ad-hoc:

• Scriptability - CLI agents can be invoked from Makefiles, shell scripts, CI/CD pipelines, and GitHub Actions; IDE plugins cannot
• Automation foundation - the same CLI command you run manually can become an automated step in your workflow; this is the path to L4 unattended agents
• Environment independence - CLI agents run anywhere a terminal runs: local machines, CI runners, remote servers, Docker containers
• Composability - CLI agents can be chained with other CLI tools; claude "generate tests" | grep TODO is a legitimate workflow
• Separation of concerns - your IDE focuses on editing; your terminal focuses on agentic tasks; concerns don't compete for the same interface

CLI agents also enable a crucial L3 practice: systematic measurement. When agent invocations are CLI commands, they can be logged, timed, and analyzed. You can measure how long tasks take, how often agents need corrections, and which task types produce the best results. This measurement is what makes L3 systematic rather than just guided.

1. Install Claude Code globally - npm install -g @anthropic-ai/claude-code or follow the official installation instructions. Set your ANTHROPIC_API_KEY environment variable.
2. Run claude in your project root - Claude Code will read your CLAUDE.md and establish project context. Do this at the start of every development session.
3. Start with well-defined tasks - "Write unit tests for src/utils/parser.ts following the patterns in src/utils/formatter.test.ts" is a good first CLI agent task. Bounded, verifiable, and low-risk.
4. Build a personal task library - Keep a text file of agent prompts that worked well. Over time, this becomes a reusable library of task templates. Share it with your team as part of your L3 standardization.
5. Integrate with your Makefile or task runner - Add agent invocations to your development workflow: make test-generate could run Claude Code to generate tests for recently modified files. This is the first step toward automation.
6. Establish team conventions for agent usage - At L3, document which task types are suitable for CLI agents, what context to include in prompts, and how to review agent output. These conventions go in your team's CLAUDE.md or engineering handbook.

Treating CLI agents as a faster chat interface. The CLI isn't just a different UI for asking questions. It's a different paradigm: give a task, review a result. Developers who use Claude Code like a chat panel (asking questions, getting answers, asking follow-ups) get IDE-plugin-level value from a tool built for much more. Shift to task-oriented prompts with acceptance criteria.

Skipping the project context initialization. Always run your CLI agent from the project root, where it can read CLAUDE.md. Running from a subdirectory or a different working directory produces generic output that ignores your project conventions. Make cd project-root && claude a habit before anything else.

Not integrating with version control. CLI agents should always run on a clean branch or with a recent commit as a checkpoint. Agents running in the terminal can make changes as fast as you can approve them, and without version control checkpoints, mistakes are hard to isolate. git add -p after an agent run is good practice at L3.

Neglecting the measurement opportunity. CLI agents are instrumentable in ways IDE plugins are not. At L3, you should be logging agent invocations: task type, duration, number of iterations, human corrections required. This data drives the optimization that characterizes L3 and sets up L4. If you're not measuring, you're still at L2 behavior.