Can Two Local AI Agents Build an App Without Me?
An experiment using Ollama and local qwen models where one AI acts as a software developer and another as a code reviewer automatically.
Stock photo for illustration only, not from the actual event
- The developer built a fully local multi-agent system using Ollama, Python, and a personal PC.
- Roles were split into a Builder and a Reviewer within a project named RelayLab.
- Faced hardware overloading and Ollama setup issues before downsizing model sizes.
- The code reviewer occasionally returned out-of-bounds statuses, crashing the orchestrator and requiring error normalization.
Leveraging artificial intelligence for coding and software development has become commonplace, but allowing two local AI models to collaborate and pass work back and forth without human intervention remains an intriguing frontier. The developer set out to explore this by avoiding paid APIs from major providers like OpenAI or Claude, opting instead for Ollama running Python locally on a personal computer.
The overall experiment was dubbed RelayLab, establishing a minimal development team consisting of two primary roles:
- Builder: Reads product requests, inspects the workspace, and creates or modifies applications.
- Reviewer: Receives original tasks, inspects the Builder's implementation, and approves or requests changes.
Initially, the setup used ambitious model sizes: qwen2.5-coder:7b for the Builder and qwen3:8b for the Reviewer. This immediately drove CPU usage to 100 percent and nearly rendered the machine unusable because Ollama kept both models loaded in memory between turns, spilling workload onto the CPU due to VRAM limitations.
To resolve the performance bottleneck, the models were downsized to qwen2.5-coder:3b for the Builder and qwen3:4b for the Reviewer. Furthermore, the Ollama request configurations were adjusted to use keep_alive: 0, forcing each model to unload from memory immediately after its turn, preventing VRAM contention.
Stock photo for illustration only, not from the actual event
Before the agents could even converse, an installation hurdle surfaced when Ollama threw a llama-server binary not found error. Although models downloaded successfully and the CLI appeared functional, the actual inference component was missing. Reinstalling Ollama resolved the issue and prepared the environment for testing.
Running Small Language Models locally highlights a major step forward in offline software prototyping. While automated multi-agent loops lack the flexibility of massive cloud APIs, managing VRAM constraints and handling non-compliant JSON outputs from local models provides valuable insights into building robust orchestration systems.
For the initial live test, a straightforward prompt was issued to build a polished single-page notes app with creation, completion, and deletion features. The Builder generated an index.html file, kicking off iterative review cycles across multiple rounds without any manual coding from the user.
"[round 3] builder wrote 1 file(s); reviewer: changes_requested"
RelayLab Log
However, the experiment encountered a snag when the Reviewer returned unexpected status terms instead of the strictly mandated JSON enum values. Responses like rejected or needs_changes triggered an AgentProtocolError, crashing the orchestrator. Consequently, the Python script had to be updated to normalize various synonyms into recognized standard statuses.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment