One engineer shipped a macOS agent without knowing Swift

Qoder's new Computer Use capability lets an AI operate a real desktop: look at the screen, click, type, drag, and keep working in the background. The engineer who built it could not read the code it produced, because he did not know Swift. That detail, tucked into the team's build log on the Alibaba Cloud community, is more interesting than the feature itself.

A post describing the project puts it plainly: "I did not know whether the code was right, but I could tell whether the tool correctly operated the computer." One person, no Swift, had to deliver production-grade native macOS software. The only workable definition of done was behavior.

One engineer, no Swift, and a desktop tool that clicks for you

Computer Use sounds simple until you write down what "click a button" requires. The click has to land. The state after it has to be readable. And the agent must not steal the foreground; nobody runs a tool twice if it yanks focus away on every action. The build log lists these as the project's three concrete challenges.

That produced a hard constraint. Unable to judge the code by reading it, the engineer judged it by watching what it did. The strategy was to define a correct result and make the AI prove it reached that result, rather than hope the code looked right. We have argued before that the real bottleneck for desktop agents is skill coverage, not the model. This post is a case study in the next bottleneck: once the agent can act, how do you know it actually did?

The first workflow is the familiar one. Write the requirement, let the Agent write code, run the tests by hand, inspect the result, give feedback. Every conversation starts from zero. The context has to be restated, and the Agent forgets which directions already failed. The bottleneck is the human. Attention runs out, and it does not persist across sessions. When the person stops, the system stops.

From request-and-response to a loop that runs overnight

The first step was building a pipeline the Agent could complete alone. Computer Use depends on system permissions, and every build has to be signed with the same certificate. Otherwise macOS treats it as a brand-new application and invalidates the Screen Recording and Accessibility permissions already granted. The team wrapped the whole path, source to stable signing to launch to tests, into one command. The Agent never has to understand signing. It just needs a reliable route to a valid package.

Running once is not enough. A normal Agent conversation is request-and-response: the task ends, the Agent stops. Building a tool takes many turns, because compilation fails, tests fail, behavior is wrong in one app, or a fix breaks something elsewhere. Qoder's answer is Goal Mode. Give the Agent a goal, such as "implement the click tool and pass the end-to-end test," and it keeps working: implementing, testing, fixing, retrying, until it converges or clearly needs a human decision. Qoder already offers remote delegation for long-running coding tasks, the same autonomy pushed a step further.

The green test that proved nothing

The ability to run alone surfaced a new failure. Asked to implement the click tool, the Agent ran the test and reported success. A manual check showed the button had never been clicked. The test only verified that the call did not throw an exception. It never checked that the button state changed. Green test, wrong behavior. The same blind spot shows up at enterprise scale, where nobody can say what their AI coding agents actually did today.

Missing tests were not the problem. Weak tests were. If a test only covers the happy path, the Agent can write an implementation that does nothing and still pass. The new rule: no change is complete unless it passes real, sufficient verification. The team describes a three-layer verification scheme, and the layer it dwells on is that the Agent generates its own tests. Implementing the click tool means building a small app that can actually be clicked and proving the visible state changes. The post shows one such Agent-generated test app, covering text fields, buttons, sliders, scrolling, nested views, lists, and other UI elements, with many similar apps built for different scenarios.

A Monday fix that comes back on Wednesday

Verification proves the current change works. It does not protect against regressions. Suppose Monday's fix stops a click from stealing foreground focus. Wednesday's optimization touches related logic, the old bug resurfaces, and nobody notices, because it sits outside the current task's test scope. It is the same failure mode that the regression tax study documents: changes meant to add capability can let old failures resurface.

The team's answer is blunt: every fixed issue becomes a persistent test case, checked automatically in future rounds. Bugs found during development enter the regression suite, and so does real user feedback. A report like "clicking did not work in this app" becomes a repeatable scenario and permanently joins the regression set. Problems that have already happened should not live only in human memory. They should become automatic checks.

The write-up cites two real failures with a single root cause: the Agent had no memory across rounds. Putting all knowledge in the prompt does not work. The context window is not large enough, and manual explanation always misses something. The team's solution is to keep memory in the file system, split into two layers. Project memory holds stable knowledge: architecture, constraints, research conclusions. Retrospective notes hold what changed in each round, what remains, and where the next round should begin. The same idea shows up in StructAgent, which lifted agent success rates from 27% to 79% without a bigger model.

The docs/ directory is the memory layout:

docs/
├── specs/              requirements and acceptance criteria
├── architecture/       architecture and core constraints
├── implementation/     notes on key implementation modules
├── research/           technical research and decision rationale
├── plans/              next-stage iteration plans
├── retrospectives/     per-round reviews, open issues, and risks
├── evidence/           test results and behavior validation records
└── test-cases/         source, coverage, and history of test scenarios

At the start of each round, the Agent reads the project memory and the previous retrospective. At the end, it writes back. The loop reads: Goal, Implementation, Verification, Retrospective, next goal. No round starts from zero anymore.

Loop Engineering, and the barrier that moved

The team reports hundreds of hours of continuous iteration, including long stretches of unattended overnight work, with evaluation charts published alongside the post. The original impossible setup, an engineer who could not read Swift shipping production-grade native macOS software, turned out to work. Not because the AI was powerful on its own, the team argues, but because a system stood around it: acceptance criteria, testing, memory, regression. Inside that system the AI could run, verify, and accumulate knowledge by itself. BAAI's research agents run on the same principle, checking their own work as they go.

The human role shifted from writing code and watching execution to defining standards, designing verification, and choosing direction. "Loop Engineering" has become a popular label lately, and the team says it recognized its own practice in it. If the loop works, an engineer does not have to be an expert in a specific technology stack to ship production-grade software. The stack stops being the main barrier. What matters is the ability to define the target and verify the result.

Qoder Desktop already includes Goal Mode and Spec capabilities, and the latest release upgrades UltraPlan and UltraReview. General-purpose validation tools such as Computer Use and Browser Use are meant to help teams build their own autonomous iteration systems. Qoder has tested the systems approach from another angle too, a multi-agent experiment that claims 60% fewer mistakes. The quietest claim in the post is the one worth sitting with: an engineer no longer needs deep expertise in a stack to ship production software with it. The stack was never the real barrier. Verification was.