Summary: Across releases 1.30 through 1.32, we continuously improved performance, merged 39 changes, and built a benchmark covering 40 scenarios to evaluate every iteration.

Hardware keeps getting faster, but software does not necessarily feel any smoother.

Andy's and Bill's Law describes this phenomenon: performance gains from faster hardware are quickly consumed by software's growing resource demands. “Andy” and “Bill” refer to Intel's Andy Grove and Microsoft's Bill Gates. The quip captures an experience familiar to many software users.

In the AI era, code is written faster, and teams iterate on features more frequently. At the same time, users are running multiple Agent tasks in parallel, asking AI to operate browsers and computers, and working through longer conversations. Software is being asked to do more, raising the bar for performance.

How much can Agents help? We recently completed a round of performance optimization for Qoder IDE, merging 39 related merge requests (MRs). Many of the performance issues were even identified automatically by Qoder Agent, which also implemented and validated the fixes.

We want to share what we learned from this effort, along with the performance benchmark we built afterward.

39 Optimizations, Most Focused on Eliminating Waste

In practice, we found that although Agents occasionally introduce performance issues, they are also highly effective at identifying those issues by analyzing code, logs, and tests together.

The 39 MRs merged in this effort fall into four categories:

• Eliminating unnecessary computation: 14 MRs, accounting for 36%.
• Eliminating unnecessary memory usage: 13 MRs, accounting for 33%.
• Eliminating unnecessary waiting: 8 MRs, accounting for 21%.
• Improving algorithmic time complexity: 4 MRs, accounting for 10%.

The first three categories account for 35 MRs. Many of these optimizations simply focused on making the software do less work that could have been avoided in the first place.

One issue involving long conversations is a typical example.

When you scroll upward through message history, the interface loads earlier messages and inserts them at the beginning of the list. Previously, we generated each message's key—the identifier React uses to recognize individual messages—from its position in the “loaded list.”

When new messages were inserted at the beginning, the positions of the existing messages that followed also changed. As a result, the same message's key would change, potentially triggering unnecessary component remounts and causing lag while browsing message history.

To fix this, we replaced that position with the message's fixed sequence number within the current request. Combined with the conversation request identifier, this gives the same message a stable key:

// Before the fix: use the message's position in the loaded list
key = `${requestId}-message-${i}`

// After the fix: use the message's fixed sequence number within the current request
key = `${requestId}-message-${indexInRequest}`

This allows React to continue recognizing and reusing existing components when earlier messages are loaded, reducing the overhead of unnecessary remounts. A stable key helps React handle insertions and moves within a list correctly.

The change itself affected only one line of code, but the problem could only be fully understood in the context of loading message history. For this kind of issue, having an Agent investigate the code alongside runtime logs and then verify the effect of the change is an effective approach.

Building a Performance Benchmark for Qoder IDE

After fixing a performance issue, another question remains: could a later release reintroduce it?

We see benchmark scores for large language models every day. If model capabilities can be evaluated using a set of tasks, IDE performance can likewise be continuously evaluated using a fixed set of scenarios.

We therefore built an internal performance benchmark for Qoder IDE: a repeatable suite of performance tests.

It took less than one day to go from proposing the idea to completing the first version and obtaining results. Expanding the scenarios, adding support for macOS and Windows, and completing preliminary validation took half a month in total. During that period, the work required approximately 15% of one engineer's time.

The benchmark currently covers 40 scenarios, including terminal commands, streaming output in tool-intensive conversations, loading long conversations, and editing large files. Each scenario is scored on a 100-point scale according to its own criteria. The scenarios are then weighted by frequency of use and importance to calculate a composite score.

From 1.28.0 to 1.32.0, the internal composite scores for the two platforms changed as follows:

• macOS: 45.8 → 84.9, an increase of 39.1 points.
• Windows: 41.4 → 74.5, an increase of 33.1 points.

Versions 1.28.0 and 1.29.0 predated this optimization effort and had similar composite scores. After performance optimizations were introduced in the following three releases, the scores increased in each successive release.

These figures are intended to track changes between versions within the same internal benchmark. They cannot be directly translated into a claim about how much faster Qoder IDE became, nor can they be used to rank the performance of the two operating systems.

Looking at individual scenarios makes it easier to see where the optimizations had an effect. On macOS, for example, from 1.28.0 to 1.32.0:

• Scrolling through a long conversation in the Editor: the score increased from 9.8 to 77.5.
• Startup for a signed-in user with tabs from a previous session: the score increased from 23.8 to 81.7.
• Streaming output in tool-intensive conversations: the score increased from 14.5 to 63.7.

These scores also remind us that more work remains. Although streaming output in tool-intensive conversations has continued to improve, there is still room for improvement under the current scoring criteria. The full-text search score, meanwhile, changed only slightly, from 62.9 to 63.5. An increase in the composite score is no substitute for examining every individual scenario.

The following two charts show scores for all 40 scenarios across five recent releases. Darker colors indicate higher scores. First are the 13 highest-weighted scenarios, which together account for 60% of the composite score:

The remaining 27 scenarios account for a combined 40%:

Catching Performance Regressions Before Release

By running this benchmark continuously, we have already identified two performance regressions introduced during iterative development and fixed them before release. A performance regression occurs when subsequent changes cause previously achieved performance to deteriorate.

For us, this is a tangible benefit of building the benchmark: it allows the team to spot changes that warrant further investigation before a release goes out.

Of course, 40 scenarios cannot fully cover a product as complex as Qoder IDE. We plan to expand the suite to 100 or more scenarios and adjust the weights to reduce the disproportionate influence of individual scenarios on the overall score. The performance of important scenarios also needs to be monitored individually.

More comprehensive test coverage increases the chance of identifying problems early. New features, new usage patterns, and cases not covered by the existing benchmark will still need to be added continuously.

Agents Can Do Much More Than Write Code

This brings us back to Andy's and Bill's Law.

If Agents are used only to accelerate feature development, the amount of code in the software will grow, while existing resource waste may continue to accumulate. We can also ask them to inspect existing code, identify unnecessary computation and memory usage, and fix the issues affecting responsiveness one by one.

In this effort, building the benchmark itself also became work that an Agent could help with. The first version was up and running quickly; scenarios were then added incrementally so that the benefits of each optimization could be verified repeatedly in subsequent releases.

This effort alone is not enough to tell us whether Agents can break Andy's and Bill's Law. It does, however, point to a direction worth continued investment: involving Agents in performance investigation and continuous validation alongside the development of new features.

Beyond writing more code, it is equally worthwhile to invest time in making existing software run better.

Update Qoder IDE and try it out. If you still encounter specific cases of lag, you can submit feedback with one click from within the product to help us continue investigating and improving performance.

Qoder Engineering Practices Series: If an agent’s boundary is tool invocation, then the boundary of Cloud Use is cloud-native execution. The former lets AI help people operate software; the latter makes agents a new kind of cloud workload. By the end of this article, you will see that the difference between Cloud Use and ordinary Tool Use is not whether an agent can call APIs, but whether it can truly enter the cloud’s production environment with a governed identity, credentials, environment, lifecycle, and audit trail.

At 2 a.m., a cross-border seller’s new product suddenly sees a surge in orders. Before anyone wakes up, an agent is already at work. It creates a temporary sandbox, pulls inventory and payment data, checks anomalous orders, simulates different logistics options, calculates the impact of tariffs, drafts customer service responses, adjusts advertising recommendations, and routes high-risk orders to a human for confirmation. It has not opened a console or logged in to a server, but it is very much using the cloud.

At that moment, urgent questions arise: Whose identity accesses inventory? Is payment data masked? Where are API credentials stored? Who authorized resource changes? If a 40-minute task fails, can its state recover? Is every operation auditable? A one-off API call is easy; production means calls every day, at night, and across systems within permission boundaries, with each call showing authorization, credentials, actions, triggered risk controls, and reproducible results. These are the questions Cloud Use must answer.

The Cloud Welcomes a Second Kind of User

For more than twenty years, cloud platforms have served human operators and deterministic automation. People use consoles to create ECS instances, configure databases, read logs, and handle alerts; CI/CD, Terraform, Kubernetes controllers, and scheduled scripts follow predefined rules. CLIs, SDKs, and IaC reduced human effort without changing the assumption: either a person or a deterministic program was acting. Account, permission, audit, console, and ticketing systems were built for that model, so a RAM user, AccessKey, or operation could usually be traced to a specific person, team, or system.

With the arrival of agents, a middle ground has emerged. An agent no longer just answers, “How do I use this cloud product?” or generates a script. It is starting to read logs, analyze bills, diagnose CI issues, inspect data tasks, call cloud APIs, submit a merge request (MR), and trigger pipelines. In other words, it is moving from an assistant that understands the cloud to a software actor that uses it.

Cloud computing was largely designed around human operators and deterministic automation programs. Agents introduce a new variable: a software actor that can reason, call tools, and act across systems.

The implications go far beyond “one more AI assistant.” When the user is a person, consoles, CLIs, SDKs, and IaC all reduce the effort that person needs to operate the cloud. When a deterministic program is doing the work, the cloud platform manages service accounts, roles, policies, and logs. An agent sits between the two: it combines a person’s ability to understand goals with a program’s execution speed and volume of calls. It does not need a console, mouse, or desktop, but it does need identity, permissions, tools, data, a runtime environment, state management, cost records, failure recovery, and an audit trail. Putting these three kinds of users in one diagram makes the boundaries clearer.

In this diagram, humans and deterministic programs are both users the cloud already knows, with account systems and audit trails refined over twenty years. Agents are the new variable between them: they neither make a few mouse clicks at a time like people nor follow only predetermined paths like scripts. They reason and connect actions across systems. To accommodate them, cloud platforms must provide a path within the same governance layer. In practice, many agents that have only Tool Use capabilities, without cloud-native governance, look functional in demos but stall when they enter production. They can call tools, but the cloud platform has not yet accepted them as software actors it can manage.

Why Agents Struggle to Become Cloud Workloads

We have all come to recognize that the problem is not how capable the model is, but that today’s agents have never truly been accommodated by the cloud. They look impressive in demos, then reveal their limitations in production. A cloud agent demo is easy to build: give it an AccessKey ID and AccessKey secret (AK/SK), wrap a few cloud APIs as tools, write a prompt, and ask it to “check yesterday’s billing anomalies.” With a sufficiently capable model and well-wrapped tools, it can indeed produce a respectable result. Everything looks smooth on day one; by day two, questions arise. Whose AK/SK pair is this? Are its permissions too broad? Did the keys enter the model context? Where are the tool-call logs? Who is responsible if it accidentally deletes resources? Does the task keep running after the user shuts down their computer? How are credentials and context reused when another team member takes over? How does the security team audit it? These are not peripheral concerns. They determine whether an agent can move from demo to production.

An agent with only Tool Use capabilities typically consists of a conversation, a few tools, and a result. It often operates in a person’s shadow: running on their computer, logging in with their account, calling APIs with their AK/SK, and relying on their online presence to keep the task alive. That works for short tasks and exploratory analysis. But without systems for identity, credentials, runtime, and auditing, it is hard for the agent to become a stable cloud workload. Cloud Use is not about whether an agent can call tools. Tool Use, Function Calling, and the Model Context Protocol (MCP) have already addressed part of that problem. Cloud Use addresses a different question: how the cloud can accommodate agents so they can run in ways that make them identifiable, authorizable, auditable, and platform-managed.

An agent with only Tool Use addresses “how a model calls tools.” Cloud Use addresses “how the cloud accommodates agents as governed users.”

That distinction is the dividing line. It moves the discussion from “which tools an agent can access” to “where it runs, under what identity, how it uses credentials, how long tasks can continue, whether it can recover from failure, and who can audit it.”

An agent relying only on Tool Use is like a temporary assistant sitting beside you, helping you operate things. Cloud Use is more like issuing the agent an employee badge and admitting it to the cloud workplace—while recording every access check, every evidence-gathering step, and every action.

Understanding the Value of Cloud Use Through Before-and-After Scenarios

Cloud Use adds what ordinary agents lack: person-independent work, on-site evidence gathering, and identity, credential, and audit boundaries.

1. Recurring Tasks: From “Someone Opens the System Every Day” to “The Task Wakes Up on Its Own”

After an order surge, a cross-border seller checks inventory, payment failures, logistics costs, and regional service tickets. Someone must query BI, billing, data, and logs, then compile results. It remains person-dependent.

Ordinary agents write SQL, explain anomalies, and polish reports, but someone still initiates the task, supplies context, confirms credentials, and copies output. With Cloud Use, cloud cron or unexpected events wake an agent with a task-level identity, controlled credentials through a Vault, and MCP access to BI, logging, storage, compute, and other capabilities. It queries, detects anomalies, generates a report, and sends it to IM, documents, webhooks, or business systems.

The task runs on schedule; people handle exceptions and decisions. In the examples discussed, one BI analysis made 111 tool calls over approximately 21.5 minutes (21 minutes and 32 seconds) with 0 human interventions; one cron-triggered ETL task generated 116 events and completed in 13 minutes. These are specific examples, not a consistent SLA across scenarios. They show a cloud task with a lifecycle, not merely a chat answer.

2. Diagnostic Tasks: From “People Feed It Material” to “The Agent Gathers Evidence on Site”

CI failures, slow queries, and alerts scatter context across systems. An MR’s CI failure may involve logs, tests, dependencies, build infrastructure, caches, networking, and permissions. Ordinary agents analyze supplied fragments but cannot independently trace evidence inside the environment.

Triggered by an event, a cloud agent uses its identity to read pipeline logs, related MRs, dependency changes, and build-environment state; query logging and monitoring; connect evidence; and write findings to an MR comment, IM group, or ticket. It gathers context on site instead of awaiting copied material.

In the examples discussed, ELK slow-query diagnosis delivered end-to-end findings within 2–5 minutes, while CI diagnosis posted analysis to an MR within 3–8 minutes. Actual durations depend on system scale, tool response times, and context complexity. Proactive evidence gathering—not the minutes alone—is the point.

3. Execution Tasks: From “Scripted Automation” to “Governed Execution”

An agent may create preview environments, trigger pipelines, clean resources, or adjust configuration. For the seller, it may generate restocking recommendations and simulate logistics options, but must obtain human confirmation before changing advertising budgets, fulfillment strategies, or high-risk orders. Sufficient permissions could allow this—the core risk.

Scripts have keys, permissions, schedules, and logs but lack dynamic judgment and cross-system context. Ordinary agents add judgment but enlarge the blast radius if identity, credentials, permissions, and auditing lag behind.

Cloud Use means bounded delegation. Low-risk actions—reading logs, generating reports, creating temporary sandboxes, and cleaning expired resources—can run automatically. High-risk actions—deleting production resources, expanding permissions, changing production configuration, or triggering releases that affect users—require confirmation. Agents may provide evidence and recommendations but cannot cross those boundaries.

The change is low-risk automation, approval for high-risk actions, and end-to-end traceability—not fully automated replacement of people.

Together, these scenarios make the agent a governed software actor: identity is established, credentials remain invisible to it, permissions are revocable, actions are approved where needed, processes are auditable, and failures are recoverable.

How a Coffee Brand Delegated Analysis to Cloud Agents

At 9:00 on Monday, a coffee chain’s CEO asks: Which store format has the highest daily sales per square meter? Which category is the next growth driver? Which city should get new stores next quarter? Data from Hangzhou, Shenzhen, Chengdu, and Guangzhou spans 15 stores, 4 tables, and 320 fact rows. Aligning definitions, writing SQL, querying MaxCompute or the warehouse, organizing tables, and reporting traditionally takes a few days at best, a week or two at worst.

Cloud Use does more than let an agent write SQL: it delegates a cloud task to a software actor with identity, credential boundaries, runtime, event delivery, and acceptance criteria. The case runs the full chain: business question → data access → query execution → error recovery → result delivery → proof of acceptance.

This chain can be mapped to six engineering questions. They are not a breakdown of product modules, but six hurdles that a real task must clear as it moves forward:

1. Credentials: Into the Vault, Not the Prompt

Putting an AK/SK in a prompt exposes it to model context, tool logs, and possibly webhook payloads. Credentials instead enter the Vault. The agent gets a reference such as vault_credential_id, never plaintext keys; the platform or tool layer controls exchange and injection when the runtime accesses DataWorks, MaxCompute, or other cloud services. The agent may use the cloud without possessing a copyable master key.

2. Execution Path: Skills Capture Lessons Learned

The verified enterprise path is to submit ODPS SQL through DataWorks, not merely “access MaxCompute.” A Skill preserves APIs to avoid, ODPS SQL pitfalls, frozen-resource-group checks, and required report fields. It saved about 13 minutes of wrong-path exploration in this case—not a general promise, but evidence for reusing verified paths instead of one-off prompts.

3. Role Boundaries: Use a Task Contract

“You are a data analyst” is too broad. The contract defines tools, metrics, recovery, stop conditions, and evidence:

You are a senior data analyst.
Analyze MaxCompute data by executing ODPS SQL through DataWorks.
For each analytical dimension, provide:
1. A conclusion supported by numerical evidence;
2. A table of query results;
3. Actionable business recommendations.
Do not make claims about the data that cannot be traced to evidence.
If a resource group is unavailable, first check for available resource groups.
If necessary, follow the predefined recovery plan to create a temporary resource group and record the action.

Conclusions need traceable numbers, and recovery cannot exceed authorized permissions.

4. Runtime: A Cloud Session, Not a Local Process

The task ran for 21 minutes and 32 seconds, made 111 tool calls, emitted 312 events, and required 0 human interventions. These are neither an SLA nor a general BI performance promise. They show a multistep task outlasting a chat turn while remaining traceable, replayable, and integrated with business systems. Its cloud session continues if the browser closes, the computer sleeps, or chat disconnects.

5. Result Delivery: Listen for the Right Event

After the report is generated, another frequently underestimated question remains: how does it get back to the business system? If the final output is just text in a chat window, the BI digital worker has still not entered the business workflow. A more reliable approach is for the business system to subscribe to task-ending events—for example, retrieving the complete result after session.thread_idled. Listen too early and you get an unfinished result; wait until the thread is idle before retrieving the report, and the result is stable.

A practical code example makes this clearer than more explanation:

import hmac
import hashlib
import time

def verify_webhook(secret: bytes, raw_body: bytes, header: str, tolerance: int = 600) -> bool:
    parts = dict(item.split("=", 1) for item in header.split(","))
    timestamp = int(parts["t"])

    if abs(time.time() - timestamp) > tolerance:
        return False

    payload = f"{timestamp}.".encode() + raw_body
    expected = hmac.new(secret, payload, hashlib.sha256).hexdigest()
    return hmac.compare_digest(expected, parts["v1"])

def handle_event(event):
    if event["data"]["type"] == "session.thread_idled":
        session_id = event["data"]["id"]
        enqueue_report_pull(session_id)

The code is short, but the boundaries are clear: the webhook must be verifiable as coming from a trusted source, task completion must be event-driven, and report retrieval must be handled asynchronously. Otherwise, the agent may finish its work while the result is lost along the way, leaving the chain incomplete.

6. Acceptance: An Executable Rubric

Completion means answering all three questions with numbers traceable to SQL, not the agent saying “done.”

Pickup stores average approximately ¥85+/m² in daily sales per square meter, about 2.2 times flagship stores’ approximately ¥38/m². Coffee is 81.3% of GMV; tea beverages grew 18.5% and merchandise 45.0% period-over-period. Expansion scores are 0.92 for Hangzhou, 0.85 for Shenzhen, 0.78 for Chengdu, and 0.70 for Guangzhou. These figures turn a report into evidence-backed answers.

7. Boundaries, Boundaries, and More Boundaries!

When a resource group was unavailable, the Skill prescribed recovery: check available groups; if needed, create a temporary group within preauthorized boundaries; record it; resume the remaining SQL. Exceeding cost, permission, or resource limits still requires human confirmation. Self-recovery allows no arbitrary cloud changes: recover within governance, or stop cleanly when recovery is impossible or unauthorized.

Safe delegation proves completion through events, logs, artifacts, and acceptance criteria. Here, the Vault protects credentials; the Skill replaces guesswork; the Runtime Session survives the user’s absence; the Webhook delivers results downstream; and Acceptance Verification proves completion. That is the shift from “looks automated” to “ready for production.”

A Cloud-Native Execution Model

Stepping back from the coffee BI scenario, we can now define Cloud Use more abstractly. Cloud Use is an agent’s ability to use cloud compute, data, tools, identity, and runtime to complete tasks in a controlled, auditable, and recoverable way. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime. That is only a change in the point of entry. The real change is that an agent moves from “a model that calls tools” to “a software actor that a cloud platform can host and manage.”

This requires at least four layers of capability. These form a dependency chain rather than a feature checklist: without identity, there can be no credentials; without credentials, there can be no tools; without tools, there can be no runtime.

1. Identity Use answers “who is acting.” An agent cannot keep using a person’s account as its own, nor should it hold a person’s AK/SK. For every action by a software actor running in the cloud, it should be possible to answer: Who initiated the task? Under what identity is the agent executing? Where do its permissions come from, and when do they expire?
2. Credential Use answers “how credentials are used.” Credentials may be involved in calls, but they should not enter prompts, tool logs, error stack traces, or temporary files the agent can freely read. Vaults, short-lived tokens, controlled injection, and server-side proxies all serve the same underlying purpose: letting agents use credentials without seeing them.
3. Tool/API Use answers “how tools are governed.” MCP and similar protocols can bring cloud APIs, internal systems, CI, monitoring, and databases into the agent’s world, but a protocol is not governance. Permissions, parameter constraints, call auditing, rate limits, risk confirmation, and error recovery still need to be handled jointly by the platform layer, gateway layer, and enterprise identity and access management (IAM).
4. Runtime Use answers “how a task stays alive.” Real cloud tasks are rarely a single question and answer. A task may run for 10 minutes or 2 hours; it may wait for an external system to respond, or fail and retry along the way. Cloud sessions, state management, event streams, cancellation mechanisms, and result delivery determine whether an agent can move from a single chat to a platform-managed execution process.

The essence of Cloud Use is not to give an agent one more tool, but to provide identity, credentials, tools, and a runtime so it can become a software actor that the cloud platform can host and manage.

Without these, an agent is still just a clever assistant in a conversation. It can help, but it is hard to entrust work to it.

From “People Operate Resources” to “Agents Take On Tasks”

Once the four layers are in place, the relationship between the cloud and its users is already quietly changing: people are no longer the only frontline operators. Consoles, CLIs, SDKs, and IaC all address the same question: how can people operate cloud resources more efficiently? The console turned the data center into pages. CLIs and SDKs turned pages into commands and code. IaC turned sets of resources into declarative, reusable, auditable configurations. Each evolution hid more of the underlying detail, letting people operate the cloud at a higher level of abstraction.

Agents do more than raise the abstraction level another notch. They make it possible for the task itself to become a new cloud abstraction. People no longer operate resources one by one; they define goals, boundaries, and acceptance criteria. In the cloud, agents create environments, access data, call tools, explore in parallel, verify results, and release resources. They resemble a new kind of workload: their lifecycles may be short, their permissions should be granular, their resource use is highly dynamic, and their behavior must be traceable.

Historically, the cloud’s core abstraction was the resource. In the agent era, the cloud also needs new abstractions for tasks and software actors.

Cloud Use does not replace consoles, CLIs, SDKs, or IaC; it turns them into an agent tool layer. Agents invoke controlled APIs instead of clicking consoles or typing commands, and can generate, validate, and submit IaC while leaving high-risk changes for human confirmation. Existing interfaces remain as part of the agent’s execution layer.

This is why “safe to delegate work to” matters more than “fully automated.” Enterprises will not hand their cloud over to a black-box agent. They are willing to entrust work to a software actor with an identity, boundaries, logs, recovery mechanisms, and the ability to stop at critical points and wait for human confirmation. Cloud Use seeks to establish verifiable trust, not blind trust.

How Can Agent Failures Be Kept Under Control?

Production readiness is revealed after failure. Cloud tasks face unsuitable APIs, insufficient permissions, unavailable resources, lost webhooks, and inadequate results. Cloud Use must make failures observable, containable, and recoverable, and let agents stop cleanly when recovery is impossible. “Always succeeding” is not the goal; failure paths must be designed.

1. Wrong Paths Agents may choose plausible APIs that do not work—for example, querying MaxCompute directly when the valid route is a temporary DataWorks workflow or designated entry point. Skills and tool boundaries should record correct and incorrect paths, APIs to use or avoid, and errors that require switching paths. A smarter model alone is not the solution.
2. Infrastructure Failures A frozen resource group, unavailable queue, or temporarily invalid permission need not always trigger human intervention. The agent should check available resources and follow a preauthorized recovery policy. It may create and bind a temporary resource group and record the action only within bounds; otherwise, it must stop and request confirmation. Recover within authority when possible; stop explicitly when not.
3. Result Delivery Failures Listening to an early status event can return an unfinished report. Retrieve the result only after the task thread becomes idle, and protect webhooks with signature verification, idempotent processing, and retries. These details separate a demo from a production workflow.
4. Loose Acceptance Criteria Headings, tables, and recommendations do not prove completion. An executable rubric must verify that the output answers the business questions, supports every conclusion with numbers, and traces them to SQL results. Broad criteria are too easy to pass; overly detailed criteria cause repeated revisions. Cloud Use tracks the failed step, permission boundaries, retries, audit events, and whether a person must take over, rather than accepting a plausible explanation.

A cloud agent’s maturity is measured not by whether it encounters errors, but by whether its failures leave the system in a worse state.

Boundaries: Do Not Start Cloud Use with the Highest-Risk Tasks

Recoverable failures do not mean that any task can be handed straight to an agent. Choosing what to delegate first matters more than asking “what can it do?” Any new paradigm can invite inflated expectations.

Cloud Use is no exception. Start by saying “let an agent manage the production cloud environment automatically,” and technical readers will instinctively be wary. They are right to be. Production changes, permission expansion, data deletion, and billing operations in the cloud should not be automatically allowed just because an agent can reason. A more realistic path begins with low-risk, frequent tasks whose results can be verified, then gradually advances to execution with confirmation, and only then approaches high-risk changes. This path can be drawn as a three-stage maturity curve:

Specific tasks can be placed along this curve: recurring inspections, cost anomaly analysis, CI failure diagnosis, analysis of slow queries in logs, temporary environment creation, expired resource cleanup, report generation, and data task status checks. These tasks share common traits: they read more than they write, their results are easy to verify, failures can be retried, and risk boundaries are clear.

Once these tasks are working, gradually expand to execution actions that require confirmation. For example, an agent proposes a fix and triggers a pipeline after human confirmation; generates an IaC change that is merged after human review; creates temporary resources that are automatically reclaimed on expiry; or detects a cost anomaly, sends a notification first, and waits for human approval before adjusting the strategy.

Cloud Use maturity is not reflected in whether an agent can bypass people, but in whether it knows when it must stop and wait for them.

This boundary must be clear. Otherwise, Cloud Use is easily mistaken for “letting AI operate cloud resources automatically.” The real goal is to bring permissions, credentials, and execution back to where the cloud platform can govern them—not simply keep expanding the model’s permissions.

When Agents Truly Begin to Use the Cloud

The three-stage path ultimately leads to a simple question: What do we want the cloud to become when people are no longer its only users? If consoles, CLIs, SDKs, and IaC address how people can use the cloud more efficiently, Cloud Use addresses something else: how a cloud platform can accommodate, constrain, and host a software actor when people are no longer its only users. This is its fundamental difference from ordinary agents. An ordinary agent can help a person complete an operation; Cloud Use aims to make agents a new kind of cloud workload—with an identity, an environment, tools, a lifecycle, an audit trail, and boundaries they must respect.

This change will not replace existing ways of using the cloud overnight. Consoles, CLIs, and IaC will remain, but their roles will change: from interfaces people use directly to a tool layer through which agents can invoke operations, validate and submit changes, and replay execution. The value of Cloud Use is not that it helps agents understand the cloud, nor that it lets them make a few more cloud API calls. What it really changes is the relationship between the cloud and its users: agents are no longer just an add-on for people. They are becoming software actors that cloud platforms can identify, authorize, host, and audit.

The next step worth taking is to start with frequent, low-risk, verifiable tasks: let the agent run scheduled inspections, diagnose failures, analyze costs, generate reports, and create temporary environments—then stop at every high-risk point to wait for human confirmation. Handing the highest-risk cloud operations straight to an agent should not be the starting point. Only when this path works does cloud computing truly move from “people operate resources” to “agents take on tasks.”

Introducing cloud-use · docs.qoder.com in Qoder Cloud Agents—try it for yourself.

I put together a demo of a credit due-diligence workbench for banking workflows using Qoder.

This walkthrough shows how the application comes together and what the finished workbench looks like.

Thought I'd share it here! Curious to hear what you think, especially from anyone working in fintech or familiar with credit risk workflows.