The Mindset Shift

For most of our careers, developers have been the quarterbacks of software development. We were on the field reading the defense, calling plays, and moving the offense in the right direction. We wrote the code, debugged problems, and made adjustments manually. Our value was often connected to how well we could execute each play. With the current landscape of AI tools, we've elevated from the field to the sidelines.

We are moving from quarterback to coach. The coach is not responsible for throwing every pass or running every route. The coach creates the game plan, puts the right players in the right positions, and ensures everyone understands the objective.

In agentic development, we define the outcome, create the specifications, and establish the architecture, standards, and constraints the agent must follow. We decide what to delegate, review what comes back, and call timeout when execution starts moving in the wrong direction.

Part of this responsibility is evaluating the roster. New models and tools will continue to appear. Some will be faster or more capable. Others will cost more and should enter the game only when the situation justifies them. Choosing the right capability for the task becomes an important engineering skill.

This shift can be uncomfortable. Many developers have spent years building an identity around writing code. We invested time learning languages, frameworks, design patterns, and best practices, which are all still very valuable, but moving from implementing every detail to writing specifications and directing agents can initially feel like a step backward. It is actually a move up the abstraction ladder.

The keystrokes may be delegated, but the judgment, accountability, and responsibility remain ours.

Soft Skills Are Becoming Technical Skills

This shift also makes soft skills more important than ever. In the past, developers could sometimes compensate for weak communication by writing the code themselves. We might receive a vague requirement, fill in the gaps through experience, and make dozens of small decisions while implementing the solution.

An agent cannot reliably do that unless we clearly communicate those decisions. The agent needs to understand the goal, the constraints it must operate within, and what a successful outcome looks like.

If our direction is vague, the result will be suboptimal. If our requirements conflict, the implementation will reflect those conflicts. If we cannot explain what we want, we cannot expect the agent to produce it consistently. The agent may be capable of doing the work, but capability without proper direction produces unpredictable results.

We will expand on this topic in later sections.

Claude Code

Claude Code is a terminal-native coding agent that can inspect a repository, modify files, run commands, execute tests, and verify its own changes.

You provide the technical objective, constraints, and definition of done. Claude determines which parts of the codebase are relevant, proposes an approach, makes the changes, and validates the result using the project’s existing tooling.

Instead of directing every file edit or terminal command, you work at the task level: “add authentication to this API,” “refactor this module to use dependency injection,” or “find and fix the race condition in the checkout flow.”

That does not remove engineering judgment from the process. You are still responsible for the architecture, tradeoffs, security boundaries, code quality, and final approval. Claude accelerates codebase exploration and execution, while you provide direction, review its decisions, and intervene when the implementation moves away from the intended outcome.

Think of it as delegating implementation to a fast engineer who can operate across the repository, but still requires clear requirements, project context, technical constraints, and review.

Every AI agent needs a control loop — the mechanism that decides what to do next. Most agent frameworks build elaborate orchestration: decision trees, routing classifiers, retrieval pipelines, state machines. Claude Code does none of that. Its architecture is radically simple: one loop, three phases, driven entirely by the model's own reasoning.

This simplicity is not a limitation. It is a deliberate design choice by Anthropic, and understanding it will change how you think about what Claude Code can and cannot do.

Source: How Claude Code works  — Anthropic

Every task Claude Code performs follows this same cycle. When you give it an instruction, it first gathers context — reading files, searching your codebase with grep and glob, checking documentation. It builds a mental model of what exists before touching anything. Then it takes action — editing files, writing new code, running shell commands. Finally, it verifies its own work — running tests, checking for errors, validating that the output matches your intent.

This cycle repeats. If verification reveals a problem, Claude gathers more context about the failure, takes corrective action, and verifies again. The loop continues until the task is complete or Claude needs your input to proceed.

The loop in pseudocode

while (task_not_complete) {
  context = gather(read, glob, grep, webfetch)
  result  = act(edit, write, bash)
  status  = verify(run_tests, check_output)
  if (status === 'needs_human') break
}