No, it doesn’t.
Suppose in your project’s:
QWEN.md
you clearly write:
“Production cannot be modified directly.”
And the Qwen Code reads it every time it starts a session.
Does this mean you can confidently enable:
Auto mode,
even YOLO mode,
just because the AI knows:
“Don’t touch Production”?
The answer is:
No, you can’t assume that.
Because QWEN.md addresses:
Instruction.
It is not:
Permission.
Nor is it:
Verification.
These three aspects must be clearly separated.
What exactly does QWEN.md do?
The Qwen Code official documentation positions:
QWEN.md
as:
Long-term instructions read by the AI at the start of every session.
For example:
How to build the project,
how to test it,
what coding conventions to follow,
architecture rules,
and fixed operational requirements.
Therefore, writing “Production cannot be modified directly” in the project’s QWEN.md
is reasonable,
because you want every agent task
to first understand this rule.
But “knowing the rule” isn’t the same as “being technically unable to violate it”
Imagine a new employee joining the company.
The manager says:
“You can’t enter the Server Room.”
This is a:
rule.
If the Server Room
is secured with controlled access,
and the employee has no:
key card,
that is:
permission.
Both rules and permission together make the control complete.
If the manager only says:
“Don’t go in,”
but the door is always open,
and the employee holds a:
master key,
you can’t say:
“Since the rule is clear, it’s technically impossible for them to enter.”
The same logic applies to an AI agent.
The first layer is Instruction
QWEN.md:
tells the agent:
what it should do.
Examples include:
Don’t modify Production directly,
run tests first,
submit a plan before modifying the database,
avoid certain directories,
always create backups first.
All of these provide:
valuable context,
but they are still:
instructions the model needs to understand and follow,
not an Operating System that revokes permissions.
Qwen’s official advice: QWEN.md is not more reliable just because it’s longer
The official Memory documentation clearly recommends:
QWEN.md should be:
short and specific.
Because the longer it is,
Qwen’s ability to reliably follow all instructions
may decrease.
If you have multiple QWEN.md files
with conflicting contents,
the official advice warns that:
Qwen may behave inconsistently.
Therefore, merely having a rule
does not guarantee that the AI will correctly interpret that rule in every operation.
Consider a seemingly clear rule:
“Production cannot be modified directly.”
Suppose the agent proceeds to modify a deployment script.
Is this considered directly modifying Production?
At this point,
perhaps not yet.
But if that script is later executed automatically,
it might affect Production.
Or the agent might modify:
infrastructure configurations,
CI workflows,
database migrations,
or secrets references.
While these don’t involve logging directly into Production servers and changing files,
they can still impact Production.
High-risk systems can’t rely on a single natural language phrase
to cover every possible pathway.
The second layer is Permission
Qwen Code offers various approval modes,
which truly control:
what the agent is actually allowed to do directly.
This is a separate mechanism from QWEN.md.
The safest mode: Plan Mode
Qwen officially designed Plan Mode as:
a read-only analysis
In Plan Mode, the agent’s main tasks are to:
read code,
understand the repository,
and plan changes.
It does not directly:
modify files,
or execute shell commands.
If you’re letting Qwen Code analyze an important project for the first time,
Plan Mode provides a stronger boundary than just writing “Please don’t make reckless modifications” in QWEN.md.
Because this mode doesn’t merely remind the AI not to modify,
it simply does not allow modifications to start.
Next comes Ask Permissions
If you are ready to begin making changes,
but the project is:
critical,
unfamiliar,
or shared among many users,
Qwen recommends using Ask Permissions mode.
In this mode,
file edits and shell commands
require manual approval.
That is, the agent must say,
“I want to make this change,”
and you still have the chance to say,
“No.”
This is the true human gate
QWEN.md says:
“Please remember not to do this.”
Ask Permissions says:
“Before you really do this, I need to confirm once more.”
Using both together is far safer than relying on prompt instructions alone.
Auto-Edit is different
Auto-Edit can automatically approve file edits,
but shell commands still need manual confirmation.
This means, if your QWEN.md says:
“Do not modify certain files,”
but the agent judges a particular edit is reasonable,
and you have already authorized file edits to run automatically,
then:
don’t mistake QWEN.md for a substitute permission system in Auto-Edit mode.
Auto Mode uses another AI classifier to assess risk
Qwen explains that Auto Mode:
uses an LLM classifier
to evaluate:
shell commands,
network calls,
edits outside the workspace,
and then decides:
which actions to automatically approve, and which to block.
Generally,
regular file edits inside the workspace
can proceed directly.
So if Production configs are located inside the current workspace,
you can’t assume there’s no risk
just because “the changes haven’t left the workspace.”
Auto Mode does have other guardrails
For example,
Qwen enforces hard rules like permissions.deny
which block certain actions even before the classifier gets involved.
If the classifier is unreachable,
it defaults to fail-closed, meaning:
no action is allowed if it can’t determine safety.
After some consecutive blocks,
it may even fallback to manual approval.
These mechanisms are much closer to technical control than simple text reminders.
But Auto Mode still can’t automatically detect all risks
It still needs to make judgments.
For instance, a shell command may appear to be a normal build,
but in reality the build script triggers deployment steps.
Or a test command might actually rebuild the test database.
The AI classifier does not have knowledge of your company’s entire implicit context.
So high-risk operations
cannot be safely trusted just because “Auto Mode has a safety classifier.”
YOLO mode definitely can’t rely on QWEN.md as a safety belt
The name YOLO is clear.
Qwen officially classifies it as the highest risk mode.
In YOLO Mode,
file edits, shell commands, and other tool calls
are all automatically approved.
The official reminder is clear:
The AI can execute
any command allowed by your terminal permissions.
If your terminal can access Production,
retrieve credentials,
push code,
or deploy,
you cannot rely on a QWEN.md phrase like “don’t do that”
to turn YOLO into a safe mode.
The real issue is: what capabilities does the agent actually have?
This is more important than:
what the prompt says.
For example,
if the agent doesn’t have:
Production SSH keys,
database credentials,
cloud admin permissions,
and deployment requires a separate manual approval system,
even if the AI makes mistakes,
the real damage it can cause is limited.
This is called:
capability boundary.
If the agent has all permissions
Production SSH,
database admin,
cloud root,
force push,
deployment token,
and your security depends only on:
QWEN.md saying:
“Please don’t misuse,”
this is not a true
least privilege model.
Therefore, high-risk workflows require at least three layers
First layer:
Instruction
telling the AI:
what it should and shouldn’t do.
This is where QWEN.md fits.
Second layer:
Permission
actually restricting:
which edits, commands, network actions, credentials, and deployments it can perform.
Third layer:
Verification
where, even if all above were correct,
the results are validated.
What does verification include?
At minimum:
code diff—what files did the AI really change?
Did it inadvertently modify unrelated code?
Then:
tests—does existing functionality still work?
Do the new features meet requirements?
Next:
staging—does the real process run correctly in a test environment?
Finally:
production approval.
Remember this very important phrase:
“Rules are not acceptance.”
You tell the agent:
“Don’t break login.”
It understands the rule,
but after the change,
login may still break,
because the agent’s intent was correct,
but bugs remain in implementation.
So even if the agent fully complies with QWEN.md, the code may not be correct
This is another common misconception.
Assuming QWEN.md:
all rules are followed,
no changes touch Production,
legacy folders remain untouched,
and tests run first,
there may still be:
new business logic errors,
edge cases missing,
concurrency issues,
or UI failures on certain devices.
QWEN.md solves:
work rules,
not formal correctness proofs.
This is the same concept behind our previous discussion of Replit Plan Mode
As SasaDaily explained on August 20:
Replit Plan Mode
lists steps exhaustively,
but that doesn’t guarantee:
building won’t break the app,
because:
a correct plan
and a correct implementation
are still two separate things.
Today we add a layer:
QWEN.md is instruction,
Plan is intended change,
Execution is actual modification,
Verification asks:
was the result correct?
You can think of AI coding as four gates
Gate one:
Does the AI know the rules?
QWEN.md.
Gate two:
Does it have permission to act now?
Approval mode,
permissions,
credentials.
Gate three:
Are its results acceptable?
Tests,
diffs,
previews.
Gate four:
Should the results actually be deployed?
Human approvals,
production safeguards.
No single gate can fully replace the next.
The most dangerous statement is: “I already told the AI not to do it.”
This only fulfills:
the first gate.
Like writing in your company policy:
“All payments over 1 million must be approved by a supervisor.”
Good,
but if the payment system actually allows any employee
to process a 5 million payment on their own,
the system still has loopholes.
A mature workflow
aligns both:
rules
and system permissions.
The most practical approach for Production is: don’t rely solely on agent self-discipline
For example:
Local:
the agent can be relatively free.
Staging:
edits are allowed, but full tests must run.
Production:
agent is not given necessary credentials directly.
Formal deployment:
requires additional
manual approval.
That way, even if one day:
QWEN.md wasn’t loaded,
content conflicts exist,
the agent misunderstands,
or the model is swapped,
you still have:
technical boundaries.
“No credentials” is usually more reliable than “please don’t use credentials”
This is the core principle of:
least privilege.
The agent only receives:
the minimum permissions it truly needs
to complete the current work.
Not:
everything just in case it might be needed later.
If the agent only needs to analyze code,
it may not even need write permission.
In this case:
Plan Mode
is much cleaner than any “please don’t modify” instruction.
What about just fixing a local bug?
Then you don’t need to turn the process into a nuclear plant operation.
You can adjust permissions according to risk.
For example:
A personal test project,
using full Git,
with the ability to reset anytime,
and no sensitive credentials,
you might allow Auto-Edit,
even run more automation
in a truly isolated environment.
This is reasonable.
The point is not:
“Always be as conservative as possible,”
but rather:
permissions should match the risk radius.
The larger the risk radius, the more you cannot rely on instructions alone
For example, editing:
README,
is low risk.
Editing:
CSS,
may be medium-low.
Database migration—high.
Payment logic—high.
Production infrastructure—very high.
Different tasks
should naturally have:
different permission modes,
reviews,
and approvals.
Therefore, “Production cannot be modified” should not be just a single phrase
A more mature design includes:
QWEN.md:
sets the rules,
↓
agent session uses the appropriate approval mode,
↓
production credentials are not directly exposed,
↓
code changes first happen locally or on a branch,
↓
tests pass,
↓
diffs are reviewed by humans,
↓
staging validates,
↓
formal deployment requires separate approval.
At this point,
QWEN.md is:
one layer in the overall safety system,
not the entire system.
So is QWEN.md still important?
Yes, very much so.
Don’t undervalue it just because it’s not:
a hard permission system.
It helps agents from the very start
know the correct way to work.
If the AI doesn’t even know:
“Don’t touch Production,”
it might keep proposing inappropriate plans.
If it knows,
it can proactively:
avoid those areas,
remind you,
use staging,
and only generate deployment instructions.
This significantly reduces unnecessary risks.
The correct understanding should be:
QWEN.md:
reduces the chances the agent makes wrong decisions.
Permission:
restricts what actions a wrong decision can actually trigger.
Verification:
checks if the result is problematic, even if the actions were legitimate.
These three layers serve different functions.
Another common pitfall: conflicting QWEN.md files
For example, a user-wide QWEN.md says:
“Automate all edits, don’t keep asking me.”
While the project QWEN.md says:
“All Production-related changes must be confirmed first.”
If the rules are:
ambiguous or conflicting,
the AI has to interpret them on its own.
Qwen’s official troubleshooting also points out:
multiple QWEN.md files with conflicting instructions
may cause inconsistent behavior.
Thus important rules should not only be:
written,
but also regularly reviewed.
Especially after a recent one-minute tutorial covering Memory Scope
User-wide,
project-shared,
and project-local scopes
can be defined not only for orderliness,
but also to reduce rule conflicts.
Place Production policies
in the proper project scope
to avoid rules from other projects coming in.
If you want to remember just one safety formula today,
remember:
Instruction ≠ Permission ≠ Verification.
Instruction:
QWEN.md.
Permission:
Approval Mode + actual system permissions.
Verification:
Diff + test + preview + human approval.
When you hear an AI agent claim:
“The rules are already in place,”
the next question should be:
“Beyond rules, what are the actual technical boundaries preventing mistakes?”
Finally, to answer today’s question again:
QWEN.md already states:
“Production cannot be modified directly.”
This means:
Qwen Code gets a clear project instruction every session,
which is very worthwhile.
But it does not mean the agent cannot technically
access Production,
or that the agent will always perfectly understand the rule,
nor that merely following this rule guarantees
the code is correct.
Therefore, don’t treat an
instruction file
as a
security boundary.
Real high-risk AI coding workflows
should include:
clear instructions,
permission restrictions,
and
final result verification.
Only then is the AI agent
not just “hoping it won’t make mistakes,”
but rather
even if it does err, the mistake won’t easily go into Production.
Today, let’s improve together with AI.
Learn one AI skill a day.
Save a bit of time every day.
Enhance your capabilities bit by bit.
SasaDaily, growing with you.
