Over roughly two years, machine help with programming moved through three shapes. First a chat window that answered questions about code you pasted into it. Then completion inside the editor, a line or two at a time. The third shape is the one this article is about: an agent that lives in the terminal, opens no new window, takes no room in the editor, and runs the whole loop — read the code, change it, run the command, look at the result, correct itself — inside the command line you were going to use anyway.

Qwen Code is an open answer to that shape, published by the team behind one of the larger open model families. Its promise is deliberately unglamorous: describe the job in plain language, and it reads the repository, edits the files, runs the tests and hands back something that works.

It has to understand the project before it can touch it

A completion tool watches one file. This one loads the whole repository into context: it scans the structure on startup, maps how the pieces depend on each other, and inside a session a file can be pulled in by name when you want it considered. Conventions a team keeps in its head can be written down once — build commands, test commands, house style — in a description file at the project root, and every session reads that file before starting work. It is a small mechanism with a large effect: the rules reach every AI edit instead of decaying after the first afternoon.

One sentence in, one finished change out

The common use is to hand over a request and let it close the loop: refactor the timeout handling on the login endpoint and run the tests to prove nothing broke. It splits that into steps by itself — find the relevant files, understand the current implementation, make the edit, run the suite, read the failures and correct them until it passes. When the change is done it can record a commit with a message that describes it. If something fails, pasting the error log back in is enough; it locates the cause in the repository instead of guessing at the surface.

Bigger jobs can be split across helper agents working in parallel, each with its own context and no interference: one hunting a performance bottleneck while another writes unit tests, the results gathered at the end. On a large project that division of labour is the difference between waiting and wondering.

Plan before acting, and a brake that works

The more autonomy a tool has, the more it needs a way to stop. Two running modes cover the extremes. In the first, writing a file or running a command each require your agreement, which suits a first week or a branch that matters. In the second, everything runs unattended, which suits repetitive work you already trust. Between them sits a planning mode: read-only analysis first, an implementation plan as the output, and no actual change until you say yes.

Extension follows the open route. A skill is a reusable package of instructions and scripts that can be dropped in and invoked again later, and an open protocol lets outside data sources and tools join the conversation — a database, a set of online documents, a design file — so that context stops being only what happens to sit in the repository.

Swap the model, keep the codebase

The tool is tuned around its own team's open coding model, but the layer that talks to models stays open: compatible endpoints from commercial providers can be attached, as can an inference service running on your own hardware, and the choice can change mid-session. The framework is released under a permissive licence and the model weights are open as well. Both open means there is no vendor lock-in to argue about, and a team with sensitive data can run the entire loop on local models.

Concretely: the licence is permissive, the implementation runs on an interpreter available on Windows, macOS and Linux, and the whole thing is one installation in a terminal. As of late 2026 the public repository had passed twenty-seven thousand stars and was moving quickly. The software itself is open; day-to-day use normally reaches a model service through the vendor's cloud on a metered or monthly plan, or through any compatible service or local model of your own.

Who it suits

People who already work in a terminal and want the model to take hold of the work rather than talk about it. Teams that cannot send source code to an arbitrary endpoint and need the model to be replaceable. Anyone who has watched an AI edit a file confidently and wrongly, and wants a planning step and an approval gate before anything is written. It is open, the model is swappable, and the codebase is not locked to anybody.