This is a hypothetical business case presented by SasaDaily.
A website maintenance team of only 5 people manages 4 different projects simultaneously.
One is their own company website.
Two are client websites.
The other is an internal tool.
The team has started using AI Coding Agents to help find bugs, fix code, and add tests.
But what really causes headaches is not that AI can’t write code.
It’s that each project’s rules are different.
Client A uses one deployment method.
Client B has an old system that can’t be modified arbitrarily.
The company’s own site allows faster testing.
And production environments are not allowed to be deployed by AI alone.
As a result, engineers have to repeat explanations whenever starting a new AI session.
The problem isn’t AI intelligence, but rebuilding context every time
Assuming this company handles 12 small maintenance tasks per week.
This is a hypothetical figure from SasaDaily.
Tasks might include:
- Modifying a form
- Fixing mobile layout issues
- Identifying the cause of a bug
- Adding a test case
- Changing an API integration
- Checking deployment issues
Previously, engineers spent about 12 minutes at the start of each task re-explaining to AI:
Which project it is.
What technologies are used.
Which directories can be changed.
What test commands to run.
Which parts are off-limits.
Whether production deployment is allowed.
12 minutes is SasaDaily’s hypothetical estimate, not Qwen Code’s official measurement.
If you only do this occasionally, 12 minutes isn’t much.
But over several dozen tasks monthly, this repeats frequently.
Step 1: Turn “things explained each time” into project rules
Qwen Code offers QWEN.md.
This is not for saving entire chat histories but for fixed instructions to be known in every session.
For example, the team can document:
Which build and test processes the project uses.
Which coding conventions apply.
Architectural decisions that shouldn’t be changed arbitrarily.
QWEN.md at the project root holds team-wide shared rules.
User-level preferences spanning projects can be stored separately.
Local settings for only the individual within a project can be stored locally.
This way, engineers don’t have to explain everything from scratch when switching projects.
But there is an important boundary here:
QWEN.md provides instructions to AI, not a production safety lock.
The official Qwen Code documentation warns that longer QWEN.md files might decrease adherence reliability; conflicting instructions may cause inconsistent behaviors.
So the team should not simply write:
“Do not modify production.”
and then hand full production permissions over to the agent.
Step 2: Divide maintenance work into different roles
Suppose a client website suddenly has a checkout error.
Previously, one engineer might:
Find the cause.
Fix the code.
Run tests.
Review their own changes.
Now, the workflow can be separated.
This is SasaDaily’s hypothetical workflow.
Agent A:
Focuses only on investigating the root cause.
Agent B:
Checks if existing tests cover this case and suggests tests to add.
Agent C:
Reviews changes from a reviewer’s perspective, assessing scope, exceptions, and risks.
Qwen Code’s Agent tool allows breaking down tasks to multiple subagents, supporting parallel execution.
There is also an Agent Team feature for teammates to share tasks and exchange messages.
Currently, Agent Team remains an experimental feature that needs to be enabled separately.
So small companies don’t need to jump to “ten fully automated Agents” right away.
It’s more practical to let AI handle parallelizable analysis tasks separately first.
Step 3: AI can modify code but can’t decide risk levels
The team next sets a fixed workflow:
Instruction → Plan → Modify → Test → Review → Human Approval
First read the project rules.
Then have AI propose a plan.
Only after scope confirmation, proceed with code modifications.
All changes must pass tests.
Review diffs afterward.
Finally, humans decide whether to commit, push, or deploy.
Qwen Code supports different approval modes.
For example, Plan Mode analyzes without modifying files or running commands.
Auto-Edit can auto-modify certain files, but Shell Commands still require approval.
Auto Mode judges some operations as safe or risky; high-risk actions may be blocked.
More importantly, forbidden operations should not only be written in prompts.
They should be restricted by permissions, sandboxing, workspace boundaries, Git branches, and manual deployment rights.
In other words:
Memory tells AI how to act.
Technical boundaries determine what AI is actually allowed to do.
The two must be kept separate.
Step 4: Leave production approval to humans
Suppose the agent finds a bug and completes modifications.
All tests pass.
The reviewer agent spots no obvious issues.
Is that enough to deploy directly?
No.
The client ultimately bears responsibility for production outcomes.
This company still leaves four things to humans:
- Deciding the scope of the task
- Determining acceptance criteria—what counts as done
- Committing to the client on timing and method of changes
- Finally approving production deployment
AI can reduce engineers’ mechanical work substantially.
But business responsibility does not transfer to AI.
How much time might really be saved?
Let’s make a simple assumption.
Weekly:
12 small maintenance tasks.
Assuming 4 weeks per month:
48 tasks total.
These are all SasaDaily hypothetical numbers.
Originally, each task required 12 minutes to re-explain project context, verify instructions, and environment.
After introducing fixed project rules and standard workflows:
Assuming this drops to 4 minutes per task.
Also a SasaDaily hypothetical figure.
Time saved per task:
8 minutes.
48 tasks × 8 minutes:
384 minutes.
Which is:
6.4 hours.
If internal development time is assumed at NT$900 per hour:
6.4 × NT$900:
Equals about NT$5,760 theoretical monthly time value.
This too is a SasaDaily hypothetical ROI.
Not official data from Qwen Code.
Nor a guarantee any company will save this exact amount.
Actual results depend on project complexity, agent usage costs, review time, error rates, and how complete the team SOP already is.
What small companies should really focus on isn’t the number of agents
The key takeaway from this case isn’t:
“How many AI agents can run simultaneously?”
But rather:
Can AI take over repetitive tasks while keeping project context, testing, permissions, and final responsibility under control?
If AI has to be re-taught every time,
if project rules get mixed up,
and if agents’ work goes unreviewed,
then even the strongest models will cost the team more time cleaning up later.
A more mature approach is to:
Store long-term rules in Memory.
Have agents handle independently manageable tasks.
Leave test results and Git commits for review.
Restrict off-limit areas with permissions.
And keep production decisions in human hands.
Only then does AI Coding Agent become more than just “helping write code.”
It truly becomes part of a reusable workflow.
Today, let’s progress a little with AI.
Learn one AI skill each day.
Save a bit of time every day.
Improve capabilities little by little daily.
SasaDaily grows with you.
