People who have never shipped software tend to think the hard part is typing the code. Anyone who has done it knows the typing is one step of many. Before a line is written there are requirements to clarify and technical choices to make. Afterwards the code has to be debugged, tests added, instructions written, and only then is there something another person can use. Done alone, that sequence takes days or weeks, and most of the time is spent on the steps that are not code.

ChatDev replaces the workers on that line with models, and not with one model doing everything but with a small company in which each member holds a role. It was built by a university research group together with a model company, and released as an open project. You describe what you want, the members of the virtual company take their assignments, and what comes back is a program that runs.

Offices and duties for every member

The organising metaphor is a real software company, and it is followed closely: a chief executive, a product officer, an architect, programmers, reviewers, testers, a documentation writer. None of them work alone. Collaboration happens through rounds of conversation that resemble meetings. The product officer proposes a requirement, the architect judges whether it is technically feasible, the programmers implement, the reviewers read the code and propose changes, and the testers actually execute the program and carry the error back for another round.

Two details keep the meetings from becoming theatre. In review, the roles are reversed on purpose: the critic must name the exact fragment of code it wants changed, which cuts down a great deal of confident nonsense. And a version mechanism means later stages are only ever shown the current source, so the team does not waste rounds repairing code that has already been replaced.

One sentence in, code and documentation out

Usage is deliberately plain: describe the software in ordinary language, give the project a name, and the team starts. Requirements analysis, interface design, implementation, testing and documentation are all covered, and what arrives at the end is not a pile of loose files but a project with running instructions and a manual.

Early figures published by the team give a sense of scale: a small application of moderate complexity took under ten minutes on average, and the model calls cost the equivalent of a few units of local currency. Those numbers come from an ideal setting, and real results move with the clarity of the description and the strength of the model used. The more precisely the request is written, the closer the result lands.

From building software to building anything

The project did not stay inside the software company scenario. Its second generation, released early in 2026 under the codename DevAll, widened the boundary considerably: it became a no-code environment for composing agents, in which a visual canvas and dragged connections are enough to build a collaborative flow. Data visualisation, three dimensional modelling, deep research, content production — any of them can be arranged into a sequence that executes on its own. Templates can be assembled like blocks, and the layer underneath is available for anyone who wants to customise it with configuration or code.

The platform separates front end from back end, draws the flow as a graph, and allows a human review step to be inserted at any important node, so automation stops and asks when a judgement is required. The source is open under a permissive licence, and by the middle of 2026 the project had gathered more than thirty-four thousand watchers. The model interface stays compatible with mainstream services, so your own key is enough to start.

Who should try it now

At its present maturity the strongest ground is small tools and prototype validation, projects with a clear target, where turning a passing idea into something runnable is dramatically faster than doing it by hand. It is equally good for students and developers who want to study how agents collaborate, with the virtual company as a laboratory for watching group behaviour. For a large and complicated system the output will still need an experienced developer to take it further, and treating it as a fast starting point rather than a replacement for the finish is the more practical posture.

What it changes is smaller than the marketing suggests and larger than it sounds: the first draft of a program no longer has to be written by one person alone. A queue of roles, each with a narrow duty, will produce something imperfect but real, and the details can be argued about afterwards.