Does AI Coding Feel Like Leadership?

Working with AI feels more like leadership than coding is a short note by Allen Bargi about the shift from writing code directly to directing an AI coding agent. It deals with a question developers are now arguing about in earnest: is agentic coding still programming, or is it closer to leading someone through ambiguous work? My answer is boring but useful: the metaphor matters only when it changes how you set boundaries, ask for evidence, and review the diff.

Agentic coding is the practice of giving a coding agent a goal, context, and permission to inspect or change a codebase over multiple steps. In Cursor, Anysphere’s AI code editor, that often means using Agent with repo context, cursor rules, terminal commands, and reviewable file edits. This is why the note landed inside the larger AI coding governance conversation, even though the interesting part is not policy. It is the daily feel of the work.

Start with the real debate

Bargi’s note names a feeling many developers recognize: when an AI agent is good enough to act, the human job moves up a level. You do less keystroke-by-keystroke construction. You spend more time clarifying intent, setting constraints, noticing drift, and deciding whether the result is acceptable.

That is the strongest version of the “leadership” side. Good work with an agent can resemble assigning a task to a capable but uneven colleague. You explain the goal, give the context, break the work into safer chunks, and review the result before it reaches users.

The Hacker News debate around the note pushed back in two useful ways. Some developers said their head is still in exactly the same technical place: the work is still about maintaining a precise mental model of the system. Others said the better analogy is not leadership at all, but whiteboarding with a colleague who asks questions, writes down decisions, and helps explore consequences.

Both objections are fair. “Leadership” can sound grand when the actual work is closer to management: scope the task, route around failure modes, and keep the agent from confidently solving the wrong problem. The practical difference is that a manager-like workflow leaves artifacts. A vague leadership vibe does not.

Keep the coding mental model intact

The trap in the leadership metaphor is delegation without understanding. If the agent changes an auth boundary, rewrites a migration, or touches billing logic, you still need the same mental model you needed before AI entered the room. The agent can move faster than you, but it cannot own the consequences.

A good Cursor workflow keeps the human close to the architecture. For example, before asking Agent to refactor a webhook handler, write the invariant first: “signature verification must happen before JSON parsing, retries must stay idempotent, and the public response shape cannot change.” Then ask for the diff.

That is not micromanagement. It is technical leadership in the small: you are preserving the system’s important truths while letting the tool explore implementation options.

The same pattern shows up in adjacent agent work. In Artifex Gives Agents a Media Graph, the interesting move is not “let the agent do more.” It is making the work legible enough that a person can inspect what the agent thought it was editing.

Treat ambiguity as the handoff, not the prompt

A one-shot prompt is a poor substitute for a handoff. The best version of Bargi’s point is that agentic coding rewards the same behavior as a good handoff: name the goal, expose the constraints, say what counts as done, and require the agent to come back when the task is unclear.

Here is a real repo-shaped example. Suppose you want Cursor Agent to add rate limiting to a public API route. A weak prompt says: “add rate limiting.” A better handoff says: “Add per-user rate limiting to POST /api/export. Use the existing Redis client. Do not add a new service. Keep anonymous users blocked. If the route has no stable user identifier, stop and ask.”

That last sentence matters. It gives the agent permission to pause instead of inventing a requirement. One of the strongest comments in the discussion made this point from the other direction: the best sessions feel like whiteboarding because the agent interviews the developer, writes decisions down, and resolves ambiguity before changing code.

Cursor users can make that behavior less dependent on memory by keeping lightweight repo rules. A rule is not a replacement for judgment. It is a guardrail for the repeated parts of judgment.

---
description: Use before changing API routes that affect auth, billing, exports, or user data
alwaysApply: false
---

Before editing a protected API route:

- Identify the caller identity used by the route.
- Name the authorization check that protects the operation.
- Preserve the existing response contract unless the task explicitly asks for a breaking change.
- If identity, authorization, or idempotency is unclear, stop and ask before editing.
- In the final response, list changed files and the invariant each change preserves.

That .mdc rule does not make the agent “safe.” It makes the next review less mysterious.

Try the argument on one PR

The fastest way to settle this locally is to run the same small change two ways: once as normal coding, once as agent-directed work. Do not pick a toy task. Pick a real but bounded change, like adding validation to a form, improving an error state, or replacing a deprecated helper in one package.

Use Cursor Agent for the agent-directed pass. Keep the branch disposable. The point is not to prove that agents are better or worse. The point is to see which parts of the work became leadership-like, which stayed pure coding, and which became review overhead.

A small experiment plan:

• Pick one issue that should touch 1–4 files.
• Write a six-line handoff receipt before starting: goal, non-goals, invariants, files likely involved, tests to run, and when to stop.
• Ask Cursor Agent to restate the plan before editing.
• Let it make the change, but review every file diff in the IDE.
• Record one sentence afterward: “This felt most like coding, management, leadership, or pairing because…”

This is also a useful code review guardrail. If the agent cannot state the invariant it preserved, the reviewer has to reconstruct too much from chat history.

Put the metaphor where it belongs

The metaphor is useful when it changes your artifacts. It is not useful when it lets people stop being precise.

For small edits, “AI as autocomplete” is still the right frame. You keep flow, accept or reject suggestions, and move on. Calling that leadership adds nothing.

For multi-step agent work, the leadership frame earns its keep. You need a clear handoff, scoped permissions, an interruption rule, and a review receipt. If your agent also has access to external tools through Model Context Protocol, Anthropic’s open protocol for connecting AI systems to tools and data, the need for boundaries goes up again. An MCP server that can read issues is different from one that can mutate production data.

The limitation is obvious: an agent is not a person. It has no durable accountability, no shared career context, and no real ownership of the system. So keep the human responsibilities named: decide, constrain, verify, and merge.

Common questions

• Is this leadership or just management?

  It is often closer to management than leadership, and that objection is healthy. The useful part is not the title; it is the behavior: scope the work, state constraints, ask for status, and review output. If the word “leadership” makes the workflow fuzzy, use “agent management” and require a handoff receipt.

• Does agentic coding still require deep coding skill?

  Yes, especially when the change crosses boundaries like auth, persistence, concurrency, or billing. The agent may write the first draft, but the reviewer still needs to understand data flow, invariants, tests, and failure modes. A good local test is whether you can explain every changed file without replaying the chat.

• What should go in Cursor rules instead of the prompt?

  Put repeated repo constraints in Cursor rules, and keep task-specific intent in the prompt. A rule is a good home for “protected routes must preserve auth checks” or “database migrations need rollback notes.” The prompt should still name the issue, desired behavior, files in scope, and what the agent should ask before editing.

• Where does MCP fit into this debate?

  MCP raises the stakes because it can connect agents to external systems, not just source files. A read-only issue tracker tool is low risk; a tool that writes to a database or comments on customer tickets needs stricter permissions. The leadership metaphor becomes concrete when you decide what the agent may see, call, or change.

• How do we know whether the agent helped developer productivity?

  Measure the PR, not the feeling. Compare elapsed time, number of review comments, test failures, reverted lines, and how long it takes a reviewer to understand the diff. One bounded PR is enough to learn whether the agent saved thinking time or merely moved that time into review.

Best ways to use this research

• Best for: Cursor users deciding how much autonomy to give Agent on real repo work, especially when changes touch auth, data access, or public APIs.
• Best first artifact: A short handoff receipt plus one .mdc rule for a risky boundary, such as protected API routes or migrations.
• Best comparison angle: Run one normal PR and one agent-directed PR on similar scoped tasks, then compare review effort instead of prompt quality.
• Best guardrail: Require the agent’s final response to list changed files, tests run, and the invariant each meaningful change preserves.

Further reading

• Cursor — Agent
• Cursor — Rules
• Model Context Protocol — specification
• Working with AI feels more like leadership than coding — source

Try one branch, then decide

Pick one real PR this week and write the handoff before you open Cursor Agent. If the diff is easier to review because of that handoff, the leadership metaphor has earned its keep.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.