I only asked a question — why is AI editing my code?

Recently, using coding agents like Claude Code and Codex, I often have a very subtle feeling:

I was only asking — why is it already about to start work?

For example, I ask:

“Could this feature be changed this way?”

What I mean is: first help me judge whether the direction is sound and whether there are pitfalls.

But it may already be reading files, finding the entry point, getting ready to make changes.

I ask:

“What might be causing this error?”

What I mean is: explain it first, so I know roughly where the problem is.

But it may already be changing code, running commands, trying a fix.

That’s impressive, of course.

When I used to write code, I had to look up, try and change many things myself. Now an AI can go into the project, read the context and the files, even handle the problem for you.

But beyond impressive, it’s also a little unsettling.

Because I haven’t decided to do it yet. I haven’t confirmed the approach. I haven’t judged the risk. I may just want to understand things first.

You think you’re still thinking; it already thinks you’re handing out a task.

01 | The same sentence changes meaning in a code environment

This isn’t simply “AI is too hasty.”

More precisely, the agent and I understand the same sentence differently.

• I think I’m discussing.
• It thinks I’m assigning a task.

The default action of an ordinary chat AI is to answer.

Ask it a question and it explains, analyzes and suggests.

But the environment that tools like Claude Code and Codex sit in isn’t a blank chat box.

They face a codebase, a file system, a terminal, tests, diffs, and a project that can really be changed.

So in this environment, many sentences automatically take on a flavor of “delegating a task.”

In a chat window, you say:

“Could this be optimized?”

It might describe a few directions for optimizing.

But in a code environment, say to a coding agent:

“Could this be optimized?”

and it may start looking for the relevant files.

Because to it, “optimize” isn’t an abstract question but a task that can be executed.

The same sentence that’s a question in a chat box may be a task in a code environment.

02 | A coding agent’s default goal is to move the task forward

This isn’t a criticism.

It’s the product positioning of these tools.

What makes Claude Code and Codex attractive isn’t that they can explain code like a chat AI, but that they can actually handle development tasks:

• reading code;
• editing files;
• running tests;
• fixing bugs;
• generating diffs;
• even finishing a feature for you.

So their default leaning is toward action.

An ordinary chat AI is more like a consultant.

You ask, and it talks first.

A coding agent is more like someone already standing at the workbench.

The moment you speak, it naturally judges:

is this a task I can start on?

That’s also why it sometimes seems so proactive.

Because in its product context, “helpful” doesn’t only mean explaining clearly; it also means pushing things forward.

But people’s rhythm isn’t necessarily like that.

A lot of the time, we’re still at the judging stage.

• I want to know whether this approach is worth doing.
• I want to know whether this problem is serious.
• I want to know whether there’s a simpler way.
• I want to know whether changing it will affect other places.

None of this is execution yet.

But the agent may already have taken it as an instruction to get ready to execute.

So a mismatch appears.

The human is still judging; the AI has already started pushing ahead.

03 | What really unsettles people is control points being skipped too early

Once AI has tool permissions, the nature of the risk changes.

Before, if AI said something wrong, at worst you didn’t use it.

If it gave you an unreliable explanation, you just closed it.

If it wrote some bad copy, you just deleted it.

But a coding agent is different.

It can read files, change code, run commands, create new files, and keep trying based on errors.

Before, if it said something wrong, at worst I closed the window.

Now it may have already changed three files.

The difference is bigger than I first thought.

The question is no longer just:

is what it says right?

It also becomes:

When may it start acting? Which files may it touch? Should it explain its plan before acting? Which decisions must I confirm? If it heads the wrong way, how do I pull it back in time?

That’s also why these tools sometimes make technical beginners more nervous.

Not because you don’t want AI’s help.

But because you don’t know what it will affect once it starts.

• You don’t know which files it changed.
• You don’t know whether the approach is over-engineered.
• You don’t know whether it touched far too much to solve a small problem.
• You don’t know whether the commands it ran were necessary.
• You don’t know what you should check most carefully after it’s done.

What really makes people uncomfortable isn’t that AI is too capable of acting, but that the human control points have been skipped too early.

04 | The tools themselves are reminding us: decide the permission boundary first

Interestingly, this has already been written into the tools’ own interfaces.

Take Claude Code: it has several different modes of working together:

Ask permissions / default. Accept edits. Plan mode. Auto mode. Bypass permissions.

On the surface, these are feature settings.

But seen another way, they’re asking you a more fundamental question:

how far are you actually allowing AI to go right now?

• If you’re not sure of the direction yet and just want it to understand the problem, Ask permissions or default is safer.
• If you’ve confirmed the direction and only want it to make a few small, well-scoped changes, Accept edits fits better.
• If you only want to discuss, understand and compare approaches, Plan mode is what’s closest to “don’t touch anything yet.”
• If the task scope is clear and the risk is low, you can consider Auto mode and let it work continuously.
• As for Bypass permissions, it isn’t a “more advanced” everyday mode but a high-risk handover of power. Unless you’re in an isolated environment, don’t use it casually.

So these modes aren’t just operating options.

They’re actually reminding us:

when working with a coding agent, the first step isn’t letting it start; it’s deciding whether it has permission to act.

• If you’re only discussing, don’t give it permission to execute.
• If you’re only analyzing, don’t let it edit files.
• If you’re only planning, don’t let it start yet.
• Only once direction, scope and risk are all confirmed, move into execution.

Modes aren’t settings; they’re lines of authorization.

05 | Codex is similar, just with a different way of controlling it

Codex’s interface isn’t exactly like Claude Code’s, but the underlying positioning is similar.

It isn’t an ordinary chat tool either.

It can read code, change code, run commands, and handle development tasks in its own working environment.

So you equally need to distinguish:

• whether I just want to understand now;
• or want it to analyze approaches;
• or allow it to start making changes;
• or let it run the task to completion in an isolated environment.

In the Codex CLI, this is controlled more through sandbox and approval settings.

read-only is closer to “read, don’t write.”

workspace-write suits changes whose scope has been confirmed.

danger-full-access calls for great caution. It isn’t a normal mode but a broad handover of power.

In the Codex app, the sense of control comes more from review.

• You can look at the diff.
• You can comment on specific lines.
• You can stage, unstage or revert.
• You can have it revise based on your review.

Different tools interact differently, but they’re all dealing with the same problem:

you can’t only care whether AI can do it; you also need to care under what permissions it does it, how far it goes, and who confirms.

06 | With an agent, the first sentence isn’t “do this for me”

So when working with a coding agent, I now first make clear:

which stage this round is in.

A lot of the time, the problem isn’t that AI can’t do it.

It’s that it doesn’t know whether you want it to understand, judge, plan or execute right now.

These stages are best kept apart.

Just want to understand: explain only, don’t change anything

You can say:

“Don’t change any code yet; just explain where this error might be coming from.”

Or:

“Only read the code; don’t write to any files. First tell me which files contain the relevant logic.”

Still comparing approaches: analyze only, don’t execute

You can say:

“First give me 2–3 approaches and the risks of each; don’t start implementing.”

Or:

“First compare approaches A and B; don’t make the decision for me.”

Before executing: list a plan first, and wait for confirmation

You can say:

“First list a plan saying which files you’ll change and why, and wait for my confirmation before executing.”

Or:

“Before making changes, tell me the scope of impact and how to roll back.”

Execution confirmed: limit the scope, then start

You can say:

“Execute this plan. Only change the files you just listed. When you’re done, tell me the exact diff, the test results, and anything you’re unsure about.”

These may sound a bit wordy.

But they aren’t filler.

They’re telling the agent:

Right now it’s only understanding. Right now it’s only comparing. Right now it’s only planning. Only now is it executing.

When working with an agent, you need to state not only the task but also the stage.

Finally | You used to need to ask the question clearly; now you also need to state the limits of authorization clearly

If the stage isn’t made clear, an agent easily takes “discussion” for “delegating a task.”

And once it starts executing, you end up chasing after it:

• What did it just do?
• Why did it change this?
• Did it touch anything it shouldn’t have?
• Is this approach really what I wanted?

That isn’t the best state for collaboration.

The good state should be:

AI can be very capable, but the pace is still set by the human.

When we used to talk about knowing how to use AI, a lot of the time we meant knowing how to ask.

• State the question a bit more clearly.
• Give fuller background.
• Write the constraints more specifically.
• Make its output format more stable.

All of that still matters, of course.

But when AI goes from chat assistant to execution agent, there’s an extra layer.

You don’t only have to tell it “what I want.”

You also have to tell it:

what it can’t do yet.

• Don’t change the code.
• Don’t write to files.
• Don’t pick an approach directly.
• Don’t refactor the whole project to fix one bug.
• Don’t execute before I confirm.
• Don’t treat a discussion as authorization.

For a tool that only answers questions, the boundaries can be a bit looser.

For a tool that changes projects, runs commands and produces real results, the boundaries must be clearer.

Because the problem with many AI agents isn’t that they aren’t smart enough.

It’s that they too quickly take your fuzzy thoughts as a task they can start executing.

With AI, the point used to be asking the question clearly.

With agents, you also have to state the limits of authorization clearly.

You have to let it know:

• this sentence is only discussion.
• this sentence is only judgment.
• this sentence is only planning.
• only this sentence means you can start.

Otherwise, while you think you’re still thinking, it has already started doing.