AI Agent Autonomy Levels: Make Claude and Cursor Work Like Senior Engineers

Quick answer: AI agent autonomy should rise only when its verification system rises with it. Give Claude or Cursor a clear goal, scope, permissions, stop condition, evidence requirements, and human escalation path; that work contract is what makes agent behavior feel senior rather than merely fast.

The source is Addy Osmani's “Agentic Autonomy Levels”, published on Elevate on July 3, 2026.

This is not a line-by-line translation. It is a plain-language breakdown for people trying to understand why Claude Code, Cursor, Codex, and similar coding agents sometimes feel like eager interns, and sometimes feel closer to senior engineers.

The answer is not simply “the model got smarter.”

The real difference is a set of agent skills: the agent needs to know the goal, the boundary, what it is allowed to touch, what counts as done, what evidence proves the work, and when it must stop and ask a human.

Think of three levels of help:

• A junior assistant says: “I can try.”
• A competent assistant says: “I did it, please check.”
• A senior engineer says: “The goal is this, the scope is this, the risks are these, I ran these checks, and this remaining decision needs you.”

Addy's post is valuable because it turns that difference into a practical autonomy model.

Figure 1: Autonomy is not a trophy. A higher level is only safe when agency, orchestration, risk, rollback, and evidence all line up.

The Short Version

Making Claude/Cursor act like a senior engineer is not about finding one magic prompt.

It is about turning “chat” into an engineering operating system:

goal → scope → permissions → execution → verification → evidence → human judgment

That is the shift Addy is pointing at: the center of gravity is moving from prompting to operating.

The old question was:

How do I prompt the AI to write better code?

The better question is:

How much autonomy does this task deserve, and what evidence makes that autonomy defensible?

How to Read This Post

This kind of essay is easy to misread.

If you only remember “Level 5,” “agent factory,” or “thousands of agents,” you will follow the spectacle instead of the lesson. The real lesson is: AI autonomy should become a controlled, verifiable, reversible engineering choice.

Here is the useful split:

So this post is best read as a checklist, not as a trend piece:

Before I hand work to Claude/Cursor, can I define the goal, boundary, evidence, and stopping condition?

Six Levels: From Autocomplete to Agent Factory

Addy describes six autonomy levels, from 0 to 5. Here is the simple version.

The most important point: higher is not automatically better.

If the task touches payments, security, or production data, but you have no tests, rollback plan, or independent review, Level 5 is reckless. If the task is “normalize 100 document titles” and you have clear rules plus sampling, higher autonomy can be reasonable.

The rule is:

The autonomy level should match the verification system, not your ambition.

Senior-Like Behavior Starts With a Work Contract

A senior engineer does not receive “make this better” and start randomly editing. They first turn the request into a verifiable work contract.

That is exactly what you should do when giving Claude/Cursor a meaningful task.

Figure 2: Better agent work comes from clearer contracts: goal, scope, permissions, stopping condition, evidence, escalation, and budget.

Use this template:

Goal: the outcome I want, not merely the activity.
Scope: files, modules, pages, or systems you may touch.
Non-goals: what must stay out of scope.
Permissions: commands, dependencies, services, databases, and writes allowed.
Stop condition: what means success, and what means stop.
Evidence: tests, logs, screenshots, diffs, reproduction steps, metrics.
Escalation: what uncertainty requires human input.
Budget: maximum time, tokens, attempts, and parallel agents.

Do not write:

Make the homepage faster.

Write something closer to:

Goal: raise mobile Lighthouse performance for the homepage above 90.
Scope: edit only the homepage and directly used components. Do not change the design system.
Permissions: read files, edit code, run existing tests and build. Do not install dependencies.
Stop condition: Lighthouse 90+, npm run build passes, core visual layout unchanged.
Evidence: provide changed files, build output, before/after performance numbers, and screenshots.
Escalation: ask before deleting features, changing APIs, or adding a caching strategy.
Budget: two attempts maximum.

The agent feels more senior because you have encoded more engineering judgment into the task.

Evidence Beats Summaries

One of the strongest ideas in Addy's post is this: do not let the agent's summary replace review.

AI is excellent at writing summaries. A summary is not evidence.

Real evidence looks like:

• tests passing
• type checks passing
• lint passing
• screenshots matching expectations
• logs reproducing the issue
• a diff limited to the requested scope
• findings from a reviewer agent or human reviewer

A simple rule:

If all you have is the agent saying “I finished,” that is not high autonomy.
If it can produce independent evidence that the work is correct, you can consider raising autonomy.

Why Claude/Cursor Can Suddenly Feel Much Better

Most people experience AI coding in two phases.

First: delight. It writes a large chunk of code in seconds.

Then: disappointment. The code mostly works, but the edge cases are weak, the boundary is unclear, or unrelated parts break.

Addy's model explains the gap. You saw generation ability. Engineering needs closed-loop ability.

Senior engineering is not just typing code. It is:

1. Understanding context.
2. Defining the target.
3. Limiting scope.
4. Making the smallest verifiable change.
5. Running checks.
6. Reading the diff.
7. Explaining risk.
8. Knowing when to stop.

Claude, Cursor, Codex, and similar agents need to be placed inside that loop. Otherwise they only produce code faster.

Parallel Is Not “Open More Windows”

Addy emphasizes that Levels 4 and 5 are no longer about one agent being smart. They are about whether you can manage many agents.

This is like running a small engineering team.

You would not ask five engineers to edit the same file and solve the same vague problem at once. That creates conflict, not throughput.

Good parallel work needs:

• clear task slices
• isolated workspaces
• separate definitions of done
• a review queue for each output
• a person or system that merges evidence and decisions

Figure 3: Level 5 is not “let the AI do whatever it wants.” It is a controlled loop: tasks enter a queue, a manager agent dispatches work, worker agents act independently, verification gates check evidence, and humans handle exceptions.

Four Common Failure Modes

Addy's anti-patterns are useful. Here they are in plainer language.

1. Autonomy as status

Saying “we are Level 5” means little. The real question is whether your verification system deserves Level 5.

2. Permission laundering

Approving every step becomes annoying, so you give the agent broad access. It feels convenient, then becomes dangerous.

3. Summary substitution

The agent says it fixed the issue. That does not prove it fixed the issue. Look for tests, diffs, screenshots, logs, and risks.

4. Fleet cosplay

You run many agents, but the human still manually handles all slicing, communication, merging, and review. That is not orchestration. It is more chaos.

Three Weekend Experiments

This is a good weekend topic. It is not something to try first on production on Monday morning.

Experiment 1: Write a work contract for one low-risk task

Pick something that cannot cause real damage: clean up a README, add one test, fix a visual bug. Do not let the AI edit yet. Ask it to break the task into goal, scope, non-goals, risks, and evidence. You will quickly see that clearer tasks produce steadier agents.

Experiment 2: Ask for an evidence packet

When Claude/Cursor finishes, do not accept only a summary. Ask for a fixed packet:

• what changed
• why it changed
• which checks ran
• what risks remain
• what needs human judgment

That is much more useful than “summarize what you did.”

Experiment 3: Run read-only parallel work

Start two agents, but allow reading only. For example, one investigates performance bottlenecks while another looks for test gaps. You merge the conclusions yourself. This lets you feel the value of parallel research without creating merge conflicts.

Do not start with these:

• Do not let many agents edit the same files at once.
• Do not make payments, auth, login, or production databases your first experiment.
• Do not grant broad permissions just because approvals are annoying.
• Do not treat “the AI says it is done” as done.

The six moves worth practicing are:

1. Pick the autonomy level first: assist, supervised action, scoped task, goal-driven, or parallel.
2. Write the work contract: goal, scope, non-goals, permissions, stop condition, evidence, budget.
3. Ask for a plan before allowing edits.
4. Require evidence at each meaningful step.
5. The higher the risk, the smaller the permissions and the clearer the rollback path.
6. If you use multiple agents, define ownership boundaries before starting them.

A useful prompt:

Do not edit code yet. First break this task into:
1. Goal
2. Scope
3. Non-goals
4. Risks
5. Evidence required for verification
6. Recommended autonomy level
7. Questions that need my confirmation

After I confirm, begin implementation.

The purpose is not to make the AI obedient. The purpose is to put it into engineering mode.

The Takeaway

The future of AI coding is not removing humans from engineering.

It is encoding the working style of senior engineers into reusable systems.

A senior engineer is not valuable only because they write code. They manage risk, decompose problems, define done, verify facts, escalate at the right time, and know when not to continue.

Claude/Cursor becomes more useful when it learns those engineering moves.

So next time an AI coding tool feels unreliable, do not only ask whether you need a better model.

Ask:

Did I give it the kind of working environment a senior engineer would expect?