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. 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.

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.