100% automated. 100% human supervised: a container as a digital teammate

100% automated. 100% human supervised. This is how I describe the execution loop I am building, not a claim that every task succeeds without intervention or that human engineering has disappeared. I decide what should exist. The runner implements a scoped task, checks its work and brings back a reviewable result. I remain accountable for what ships.

A container as a digital teammate

A chat window is not a development environment. My runners have a project checkout, dependencies, a test database, a browser and project-specific instructions. They run in separate LXD containers. That gives each worker a practical workspace without installing its dependencies into another project's environment.

The analogy to an employee is about the work contract: a queue, a clear brief, tools, a place to ask questions and a deliverable. A container is not a person and isolation is not a substitute for access control. The useful part is that the worker can carry a task forward while I review another change.

The board is the interface

In my Salesnivo and AutoSped runner repositories, the entry point is a project board column named Ai. I prioritize the work there. The runner takes a card, moves it into progress and starts a coding session with the task context.

• A pull request moves the work into Testing.
• A question moves it into Questions. My reply can resume the same session.
• Review feedback sends the worker back to the same change.
• A usage limit pauses execution rather than requiring me to reconstruct the task manually.

This makes the supervision visible. I am not approving a vague promise that an agent has finished. I can inspect the diff, checks, questions and proposed result.

Real repositories, project-specific workers

ai-board-runner was built for Salesnivo. Its TypeScript runner handles board intake, coding sessions, questions and review corrections; provisioning prepares the PHP, Node, PostgreSQL and Chromium environment.

autosped-ai-runner is a separate project-specific runner for the AdonisJS application. Its documentation describes a dedicated bot and container, review fixes, approved pull-request handling and task closure. Separate runners let project policies differ without pretending that every product has the same release rules.

I review the diff and test results, then decide whether the change is ready or needs another pass. Feedback goes back to the runner so it can continue working on the same pull request.

What this saves me

I no longer have to sit in a coding session to keep a task moving. The runner picks up the brief from the board, carries the implementation forward and returns with a pull request or a question. If a session stops, I do not have to collect the context and start over.

While it works on one task, I can review another change, clarify requirements or plan the next piece of the product. My time goes into the brief, decisions and review instead of supervising every step of implementation.

AI-generated implementation, human-owned delivery

“AI-generated” describes where an implementation came from. It does not prove that it meets the brief. My engineering experience goes into the architecture, task boundaries, acceptance criteria and review. The automated worker expands execution capacity; it does not inherit accountability.

That is the showcase I want to present: not a magical one-click product, but a repeatable delivery system with inspectable work and explicit human control.

See the anonymized runner showcase · Read the earlier board-runner case study