I Built an Office Full of AI Developers. They Started Opening Pull Requests.

In a unique project, a developer created an office filled with AI-powered coding agents. These pixel-art agents, capable of taking tickets, writing code, running tests, and opening pull requests, are represented in a cute dashboard. However, the project quickly evolved beyond just AI agents.

At first glance, the project started as a simple pixel-art office layout, with characters like software engineers, QA testers, tech leads, and product owners. The developers aimed to give these characters an actual connection to coding agents. Each character could represent a different role and AI provider, such as ChatGPT, Gemini, or Grok.

The project truly came to life when the agents were given a real repository to work on. An agent could receive a task like "Fix the checkout crash when the shopping cart is empty." The agent would then clone the repository, understand the task, inspect the codebase, make changes, run project checks, repair failures, commit changes, push a branch, and finally open a pull request. This transformed the cute pixel developer walking toward a desk from just an animation to an actual agent modifying the codebase.

Initially, the developer was just using AI coding tools to generate functions or refactor code. But this new project felt different. Instead of asking the agent, "Write this function," the developer was asking the agent, "Solve this problem." At some point, the developer even started managing the agents, deciding which tasks went to QA, tech leads, or other roles. This change led the developer to think about AI-assisted software development in new ways.

The most interesting aspect became not "Can I write this code?" but rather "Can I describe the problem correctly? Can I define what 'done' actually means? Can I give an agent enough context without giving it too much power? Can I verify the result? Can I design a workflow where bad output gets caught automatically?"

The developer realized that the AI agent is not the challenging part. Connecting an LLM to a repository is relatively easy. The real difficulty lies in handling scenarios where the agent produces garbage, fails tests, runs the wrong commands, modifies the wrong parts of the repository, or even deletes half of the application, which could be a valid refactor in the agent's eyes.

This led to the development of features like isolated workspaces, command restrictions, and verification gates to ensure the agent's actions remain safe.

Tests became much more critical in this setup. With humans writing every change, tests were useful. However, with autonomous agents writing changes, tests became the contract. My Little Office implemented a rule: if the project's verification commands fail, the task doesn't get delivered. The agent gets the failure, attempts to repair it, and if it still can't make the project pass, the task fails without creating a pull request.

This concept of verification becoming a contract for AI-generated code is an essential lesson for the future of software engineering.