Skills on Tessl: a developer-grade package manager for agent skillsLearn more
Logo
Back to podcasts

What Developers Need To Know About Agents Before 2026

with Maor Shlomo, Reuven Cohen, and Maksim Shaposhnikov

Transcript

In this episode

In this episode of AI Native Dev, host Simon Maple and guests Maksim Shaposhnikov, Maor Shlomo, and Reuven Cohen explore the evolving landscape of AI agents in software development. They discuss the trade-offs between IDE-based and terminal-first agents, the steps for adopting AI autonomy in development workflows, and the use of subagents to manage complex tasks. Tune in to discover practical insights on maximising AI efficiency while maintaining control and quality in your projects.

From IDE sidekicks to terminal-native power tools, this episode of AI Native Dev dives deep into how developers can work effectively with AI agents today—and how to scale their autonomy responsibly. Host Simon Maple is joined by guests Maksim Shaposhnikov, Maor Shlomo, and Reuven Cohen to unpack real-world workflows, the rise of subagents, and a practical ladder for adopting AI in your day-to-day development.

IDE vs. Terminal: Choosing Where Your Agent Lives

A central theme in the conversation is the trade-off between IDE-based agents (like Cursor and Windsurf) and terminal-first agents. IDE agents keep the developer “in the loop,” using UI elements to guide, visualise, and accelerate onboarding. With buttons, inline diffs, and file-by-file views, tools like Cursor make it easy to review changes, generate unit tests, and delegate small-to-medium tasks without losing situational awareness. This UI support is especially valuable when you’re new to AI tooling or want to minimise the learning curve.

Terminal-first agents, on the other hand, are designed for developers who live in the command line and prioritise speed, composability, and automation. If you’re comfortable with vim/nano, git, and shell workflows, you can bypass UI overhead and operate purely through commands and keybindings. The downside: verbosity and context can become overwhelming. Without a built-in visual diff or navigable change UI, it takes skill and discipline to track what’s happening and avoid losing important context.

Interestingly, the tooling ecosystem is converging. IDEs like Cursor are adding terminal access and even their own agent modes, while terminal agents now offer more interactive experiences. The line between “GUI-driven assistant” and “CLI-first agent” is blurring, giving teams the flexibility to pick the modality that best fits their task—and switch when needed.

A Practical Ladder for Adopting Agent Autonomy

Max outlines a pragmatic adoption path that scales with your experience and risk tolerance. If you’re non-technical or validating ideas quickly, start with no/low-code platforms like Lovable, which let you build frontends and backends via natural language. You stay in control by reviewing and approving the AI’s output, but you don’t need to write code yourself.

For developers, begin with lightweight copilots (e.g., GitHub Copilot) to boost typing speed and fill in boilerplate. Once you’re confident, move to IDE assistants like Cursor or Windsurf where you can delegate larger tasks: refactor an entire file, scaffold integrations, or generate tests across a module. Here, you’re still very much in the loop—reviewing diffs and iterating conversationally—but you’re expanding the scope of delegation.

Finally, when you understand the strengths and limitations of these tools, step into terminal-first agents and CLIs such as Claude Code, Genie CLI, or Gemini CLI. These agents can run background jobs, operate in non-interactive modes, and handle multi-step tasks autonomously. By this stage, you’ve built the trust, habits, and guardrails to safely delegate bigger chunks of work—sometimes across an entire service or subsystem. The overarching principle: grow autonomy as you grow trust, in yourself and in the tooling.

Working Effectively with Terminal-First Agents

The terminal gives you the “batteries” for automation. Many CLIs support non-interactive modes where you pass a goal prompt and let the agent run in the background as a separate process. This makes it natural to wire agents into scripts, tmux panes, or background jobs that can continue while you work elsewhere. For longer tasks, tee logs to files and keep a transcript of agent actions; this becomes invaluable for auditing, debugging, and learning what to prompt next.

Because visibility is limited compared to an IDE, adopt practices that preserve clarity. Always run agents in dedicated branches. Require agents to summarise planned changes before execution, and enforce commit granularity (e.g., one logical change per commit) so you can bisect or roll back safely. Use git diff and patch staging (git add -p) to keep fine-grained control over what lands. When the agent suggests running commands, prefer review-and-confirm flows or “dry run” flags to catch destructive actions early.

Finally, make the terminal your glue. Chain agents with shell utilities, pass artifacts between steps, and use CI to validate outputs. For example: generate code with a CLI agent, run tests/lint in CI, then only allow merging if gates pass. This “agent + automation” pairing turns the terminal into a powerful hub for orchestrating autonomous work without sacrificing quality.

Subagents: Orchestrator/Worker Patterns for Complex Tasks

When a task is too large or ambiguous for a single agent, subagents shine. Think of them as worker instances that the main agent (the orchestrator) spawns to tackle parts of the job or explore multiple options in parallel. Two scenarios stand out: divide-and-conquer (e.g., split a feature into backend and frontend subagents that iterate independently, then reconcile) and parallel exploration (e.g., multiple search strategies—Google queries, Wikipedia, internal docs—converging toward an answer).

This pattern boosts throughput and reduces latency, as the workers canvass the problem space simultaneously. The orchestrator evaluates their outputs, chooses winners, and routes feedback for further refinement. You can let the main agent autonomously spawn workers via prompt instructions (some tools, like Claude Code, can interpret “use parallel agents” natively), or you can predefine specialised subagents with tailored system prompts and tool access for higher quality.

There are trade-offs. Costs scale roughly linearly with the number of workers, and quality isn’t guaranteed—subagents might fail to converge or duplicate effort. Moreover, designing effective subagent instructions is its own craft. General-purpose workers are fast to spin up but may miss crucial constraints; specialised workers demand more upfront prompt engineering but tend to produce higher-quality results. As foundation models improve, the need for multiple workers may decrease, but the orchestration pattern remains valuable for speed and robustness today.

Cost, Convergence, and Guardrails for Multi-Agent Workflows

Running many agents in parallel can burn tokens quickly, especially if each worker performs long tool-augmented traces. Control blast radius with explicit scope: define the goal, constraints, allowed files, and stop conditions. Impose timeouts and step limits. Require subagents to propose a plan before execution and to summarise deltas at each checkpoint to reduce meandering.

Convergence is a real concern. Encourage structured decision-making: have subagents produce rationale alongside outputs, let the orchestrator score proposals against acceptance criteria, and iterate only on the most promising branches. Where appropriate, introduce a human-in-the-loop review before expensive steps (migrations, destructive ops) or before merging code. This keeps costs predictable and maintains quality.

Finally, choose your spawning strategy wisely. If you need breadth fast, allow the main agent to spin up generic workers (“parallel agents”) and pick the best outcome. If quality matters most—say, a security-sensitive backend—preconfigure specialised subagents with domain-specific instructions, tools, and test harnesses. The right balance depends on your tolerance for cost, latency, and risk.

Key Takeaways

  • Pick your modality intentionally: IDE agents maximise visibility and onboarding; terminal agents maximise speed, composability, and automation.
  • Climb the autonomy ladder: no/low-code (Lovable) → copilots (GitHub Copilot) → IDE assistants (Cursor, Windsurf) → terminal CLIs (Claude Code, Genie CLI, Gemini CLI).
  • In the terminal, protect clarity: run in feature branches, require plans and summaries, commit in small units, and capture logs for auditability.
  • Use subagents for parallelism and decomposition: split backend/frontend work or fan out multiple search strategies; reconcile via an orchestrator.
  • Balance speed against cost: parallel workers increase throughput but burn tokens—set scope, step limits, and review gates to stay efficient.
  • Specialise when quality matters: predefine worker roles and system prompts for domain-specific tasks; otherwise, let the main agent spawn generic workers for rapid exploration.
  • Build trust incrementally: expand the scope you delegate as you gain experience with the tools, and always keep guardrails in place for critical changes.