DEV Community: Angga Bachtiar

Building a Repository-Aware AI Coding Loop in Rust

Angga Bachtiar — Thu, 10 Sep 2026 16:13:27 +0000

Most AI coding examples stop after generating code.

The model receives a prompt, returns a proposed implementation, and the application prints the result. That is useful for experimentation, but it is not a complete engineering workflow. Code is only useful after it has been written to the repository, compiled, tested, and reviewed.

I built Loop Engine to explore a more practical approach:

plan → edit → verify → review → reflect

Loop Engine is an open-source Rust CLI that runs this workflow against a local repository. It uses OpenRouter for model access and allows a different model to handle each phase.

What the engine does

A normal run performs the following steps:

Inspects the target repository.
Creates an implementation plan.
Lets the implementation agent read and modify files.
Runs the repository's verification commands.
Sends the actual changes and test output to a reviewer.
Reflects on the result.
Repeats when verification or review fails.

The loop only reports completion when:

The repository contains real file changes.
The implementation agent explicitly finishes.
No tool error remains unresolved.
Every configured verification command passes.
The reviewer approves the implementation.
The reflector agrees that the objective is complete.

A model cannot complete the workflow merely by returning the word COMPLETE.

Why Rust?

The engine executes file operations and local verification commands, so predictable behavior matters.

Rust gives the project:

Strong types for loop state and tool actions.
Explicit error handling.
Safe path validation.
Good support for asynchronous HTTP and subprocess execution.
A single installable CLI binary.

The engine also uses optimistic concurrency for file updates. An existing file must be read before it can be written. Immediately before writing, the engine confirms that the file still matches the version the agent read.

This prevents the agent from silently overwriting a change made by the developer during the run.

Installing Loop Engine

Clone the repository:

git clone https://github.com/anggadb/loop-engine.git
cd loop-engine

Install the CLI:

cargo install --path . --locked

Create your local settings:

Copy-Item .env.example .env
Copy-Item loop-engine.json.example loop-engine.json

Add an OpenRouter API key to .env:

OPENROUTER_API_KEY=your-openrouter-key
OPENROUTER_HTTP_REFERER=your-localhost-url
OPENROUTER_X_TITLE=Loop Engine

The environment file and local model configuration are excluded from Git.

Configuring models by phase

Each phase can use a different OpenRouter model:

{
  "models": {
    "plan": "openai/gpt-4.1-mini",
    "implement": "openai/gpt-5.1-codex",
    "review": "openai/gpt-4.1-mini",
    "reflect": "openai/gpt-4.1-mini"
  },
  "requests": {
    "timeout_seconds": 600
  },
  "execution": {
    "max_tool_calls": 30,
    "timeout_seconds": 120,
    "checks": []
  }
}

For free experimentation, the phase models can be replaced with an available free model:

{
  "models": {
    "plan": "qwen/qwen3-coder:free",
    "implement": "qwen/qwen3-coder:free",
    "review": "qwen/qwen3-coder:free",
    "reflect": "qwen/qwen3-coder:free"
  },
  "execution": {
    "max_tool_calls": 30,
    "timeout_seconds": 120,
    "checks": []
  }
}

Free models have stricter rate limits and may be less reliable. The exact list of available models can also change.

Inspecting a repository safely

Before sending repository content to a model, inspect the generated snapshot:

loop-engine --repo "C:\projects\my-app" --inspect

This command does not load the API key or make an OpenRouter request.

The snapshot is bounded and excludes hidden entries, common dependency directories, generated output, symlinks, binary files, and credential-like filenames. It still cannot guarantee that source files contain no sensitive values, so reviewing the snapshot remains important.

Dynamic verification detection

Loop Engine detects common build systems from files in the target directory:

Repository marker	Verification
`Cargo.toml`	`cargo test`
`go.mod`	`go test ./...`
`package.json`	Available `test`, `typecheck`, and `build` scripts
Pytest configuration	`python -m pytest`

You can preview the selected checks without running them:

loop-engine --repo "C:\projects\my-app" --inspect-checks

Example output for a Go repository:

{
  "source": "detected",
  "checks": [
    {
      "program": "go",
      "args": ["test", "./..."]
    }
  ]
}

Explicit checks override detection:

{
  "execution": {
    "max_tool_calls": 30,
    "timeout_seconds": 180,
    "checks": [
      {
        "program": "go",
        "args": ["test", "./..."]
      }
    ]
  }
}

The model cannot invent arbitrary shell commands. It can request verification, but the engine only executes commands resolved from trusted configuration or fixed detection rules.

Running an objective

To run the engine against a repository:

loop-engine `
  --repo "C:\projects\my-app" `
  --env-file "C:\tools\loop-engine\.env" `
  --config "C:\tools\loop-engine\loop-engine.json" `
  "Remove the deprecated endpoint and update its tests" `
  --iterations 3

During implementation, the coding agent can request these operations:

List repository files.
Read a text file.
Create a text file.
Replace an existing text file.
Run the configured checks.
Finish the implementation.

The engine always runs authoritative verification again after the final edit.

Exit code 0 means the work passed the completion rules. Exit code 2 means the iteration or tool budget ended before verified completion. Other nonzero codes indicate execution errors.

Prompt logs and recovery journals

Every run creates a .loop-engine directory inside the target repository:

.loop-engine/
  run-<id>.jsonl
  run-<id>/
    iteration-001/
      0001-plan.jsonl
      0002-implement.jsonl
      0003-implement.jsonl
      0004-review.jsonl
      0005-reflect.jsonl

Each prompt log records:

The iteration and phase.
The selected model.
The system and user prompts.
The response or error.
Request timing.
Tool results associated with the prompt.

The request is written before the API call starts. If the process is interrupted or the provider times out, the input remains available for diagnosis.

The main journal records original and replacement file content before every write. This provides a manual recovery path if a run fails after modifying files.

Logs may contain source code and model output, so .loop-engine/ should remain excluded from version control.

Handling incomplete runs

An incomplete result includes a stop_reason, such as:

verification_failed
tool_budget_exhausted
unresolved_tool_error
no_changes
invalid_review_response
review_requires_changes

It also contains:

The changed file list.
Verification commands and their output.
The latest repository snapshot.
Every model response.
Prompt-log paths.
The recovery-journal path.

Edits remain in the target repository after an incomplete run. This makes the result inspectable, but it also means the tool should preferably be used in a clean branch or disposable checkout.

Current limitations

Loop Engine is still experimental.

It currently:

Replaces complete file contents instead of applying structured patches.
Does not delete or rename files.
Does not automatically roll back failed runs.
Does not resume interrupted prompts.
Detects build systems only from the selected repository root.
Depends on model compliance with its JSON action protocol.
Runs verification commands with the current user's operating-system permissions.

The verification process is not an operating-system sandbox. Project build scripts may access the network, environment variables, and files available to the user.

What I learned

The interesting part of an AI coding agent is not the initial code response. It is the control loop around that response.

The model needs constrained tools, real observations, explicit verification, durable logs, and a completion rule that cannot be satisfied by confidence alone.

Loop Engine is my attempt to make that loop small enough to understand while still useful against real repositories.

The source is available on GitHub:

👉 github.com/anggadb/loop-engine

Feedback, issues, and contributions are welcome.

Building a Human-in-the-Loop Autonomous Coding Agent with n8n and Telegram

Angga Bachtiar — Wed, 19 Aug 2026 07:37:50 +0000

What if I could send a coding task from my phone, put the phone back in my pocket, and let an AI agent work on my development machine?

And what if, whenever the agent wanted to do something that required my permission, it could simply message me on Telegram?

That was the idea behind a small automation project I recently built.

The final architecture combines Telegram, Cloudflare Tunnel, n8n, a lightweight Express.js runner, and Codex to create a remote, human-in-the-loop autonomous coding workflow.

The interesting part is that almost everything still runs on my own development machine.

I didn't deploy n8n or my Codex runner to a public server just to make Telegram communication possible. Instead, I use Cloudflare Tunnel as the bridge between the public internet and my local n8n instance.

The result looks roughly like this:

                    INTERNET
                        │
                        ▼
┌─────────────┐   ┌───────────────┐
│  Telegram   │──▶│  Cloudflare   │
│    Bot      │   │    Tunnel     │
└─────────────┘   └───────┬───────┘
                          │
                          │ secure tunnel
                          ▼
                 ┌────────────────┐
                 │   Local n8n    │
                 └───────┬────────┘
                         │
                         ▼
                 ┌────────────────┐
                 │ Express Runner │
                 └───────┬────────┘
                         │
                         ▼
                 ┌────────────────┐
                 │     Codex      │
                 └───────┬────────┘
                         │
                         ▼
                    Local Repo

And when Codex requires approval:

Codex
  │
  │ approval required
  ▼
Express Runner
  │
  ▼
n8n
  │
  ▼
Telegram
  │
  │ Approve / Reject
  ▼
n8n
  │
  ▼
Express
  │
  ▼
Codex continues

This article explains how I built it and, more importantly, some of the architectural problems that appeared once I tried turning a coding agent into something I could actually operate remotely.

The Goal

AI coding agents are already capable of doing much more than generating code snippets.

They can inspect a repository, modify multiple files, execute shell commands, run tests, inspect failures, fix their implementation, and repeat the process.

But there was still one inconvenience in my workflow:

I had to be sitting at my development machine to initiate and supervise the work.

I wanted something closer to this:

Me, from Telegram:

"resume-web:
Add rate limiting to the API
and add tests."

        ↓

Codex works on my PC

        ↓

Telegram:

"Task completed.
12 tests passed."

All from my phone.

But I had another requirement.

I didn't want to achieve remote coding by simply giving an AI agent unrestricted control over my machine.

If the agent wants to perform something outside the permissions I've granted, I still want to make that decision.

So the real goal became:

Build an autonomous coding workflow where normal development work can proceed independently, while sensitive actions are escalated back to my phone for approval.

I think human-in-the-loop autonomous coding is the best description for it.

Why Telegram?

The first question was how I wanted to interact with the system.

I could have built a web dashboard.

But then I'd have to build authentication, a frontend, notifications, mobile responsiveness, task history, and several other things unrelated to the actual experiment.

Telegram already gives me most of that.

It provides:

a mobile interface
push notifications
bots
commands
messages
inline buttons
callback events

More importantly:

it's already on my phone.

So Telegram became my remote control.

Telegram = Remote UI

The Localhost Problem

There was an immediate problem.

My n8n instance runs locally.

Something like:

http://localhost:5678

That's perfectly fine when I'm sitting at my computer.

But Telegram obviously cannot send webhook requests to:

localhost:5678

localhost only exists from the perspective of my machine.

I needed:

Public Internet
      ↓
Public HTTPS endpoint
      ↓
My local n8n

One solution would have been deploying n8n somewhere publicly accessible.

But I specifically wanted to keep this automation running on my own machine.

That's where Cloudflare Tunnel entered the architecture.

Exposing Local n8n with Cloudflare Tunnel

Cloudflare Tunnel lets a locally running service become reachable through a public hostname without exposing the machine itself directly.

Instead of opening a router port like:

Internet
   ↓
Public IP
   ↓
Port forwarding
   ↓
My PC

I run cloudflared locally.

The connection is initiated outbound from my machine toward Cloudflare.

Conceptually:

My PC
 │
 │ outbound connection
 ▼
Cloudflare
 │
 │ public HTTPS
 ▼
Internet

Then Cloudflare can map a public hostname to my local n8n service.

For example:

automation.example.com
          │
          ▼
  Cloudflare Tunnel
          │
          ▼
http://localhost:5678

This means Telegram can reach a public HTTPS webhook while n8n itself continues running locally.

So my webhook path can conceptually become:

https://automation.example.com/webhook/telegram

while the actual service receiving it is still:

http://localhost:5678

I don't have to expose n8n's port directly to the internet.

Why Cloudflare Tunnel Instead of Port Forwarding?

I didn't want my architecture to become:

Telegram
   ↓
MY_PUBLIC_IP:5678
   ↓
n8n

That would require exposing an inbound service from my development network.

Cloudflare Tunnel gives me a cleaner model:

                    Public Internet
                           │
                           ▼
                    ┌─────────────┐
                    │ Cloudflare  │
                    └──────┬──────┘
                           │
                     secure tunnel
                           │
                    ┌──────▼──────┐
                    │ cloudflared │
                    │   My PC     │
                    └──────┬──────┘
                           │
                           ▼
                    localhost:5678
                           │
                           ▼
                          n8n

The tunnel is initiated from the local machine rather than requiring inbound port forwarding.

For a personal automation project like this, that was exactly what I wanted.

Cloudflare Is Only the Ingress Layer

One thing that's important to clarify is that Cloudflare isn't running my coding workflow.

It doesn't execute Codex.

It doesn't orchestrate the tasks.

And it doesn't run n8n.

Its job in this architecture is much smaller:

Cloudflare Tunnel
       =
Public ingress to local n8n

The actual execution still happens locally:

LOCAL DEVELOPMENT MACHINE

cloudflared
     │
     ▼
    n8n
     │
     ▼
Express.js
     │
     ▼
Codex
     │
     ▼
Repository

I like this separation because each component has a very specific responsibility.

Why n8n?

Once Telegram can reach my local environment, I still need something to orchestrate the workflow.

For example:

Receive Telegram message
        ↓
Parse project + instruction
        ↓
Validate input
        ↓
Call Codex runner
        ↓
Wait for completion
        ↓
Format result
        ↓
Send Telegram response

That's where n8n fits.

My simplified workflow looks something like:

Telegram Trigger
       │
       ▼
Parse Command
       │
       ▼
HTTP Request
       │
       ▼
Local Codex Runner
       │
       ▼
Format Result
       │
       ▼
Telegram Message

n8n isn't the coding agent.

It's the orchestrator.

The Local Codex Runner

I still needed something that could actually launch and communicate with Codex.

I built a lightweight Express.js service for that.

Conceptually, n8n calls:

POST /codex

with something like:

{
  "project": "resume-web",
  "task": "Add rate limiting to the API and add tests."
}

The runner maps a project alias to an actual local directory:

const projects = {
  "resume-web": "D:\\Projects\\resume-web"
};

This was an important design decision.

I don't allow Telegram to specify an arbitrary filesystem path.

Instead of:

{
  "path": "C:\\whatever\\someone\\wants"
}

the remote interface only knows:

resume-web
backend-api
personal-rag

The runner decides where those repositories actually exist.

So:

Telegram
   │
   │ "resume-web"
   ▼
Express
   │
   │ lookup
   ▼
D:\Projects\resume-web

That gives me a simple allowlist around what the remote system can operate on.

The First Codex Implementation

My original runner was surprisingly simple.

It essentially spawned Codex:

const child = spawn(
  "codex.cmd exec --sandbox workspace-write -",
  {
    cwd: projectPath,
    shell: true
  }
);

Then I collected stdout and stderr:

let stdout = "";
let stderr = "";

child.stdout.on("data", (data) => {
  stdout += data.toString();
});

child.stderr.on("data", (data) => {
  stderr += data.toString();
});

Finally:

child.on("close", (code) => {
  res.json({
    success: code === 0,
    output: stdout,
    error: stderr
  });
});

That produced:

Telegram
    ↓
Cloudflare
    ↓
n8n
    ↓
Express
    ↓
codex exec
    ↓
Repository
    ↓
Codex exits
    ↓
Express response
    ↓
n8n
    ↓
Telegram

And it worked.

I could literally send a coding instruction from my phone and receive the Codex result back on Telegram.

But there was still one major problem.

What Happens When Codex Needs Approval?

Giving an agent permission to edit code is one thing.

Giving it unrestricted access to everything on the machine is another.

I wanted Codex to work autonomously inside a controlled environment, but still ask me when it crossed a permission boundary.

Normally this is easy when you're sitting in front of the CLI:

Codex wants to perform an action.

Approve?

[Y] Yes
[N] No

But my Codex process is being triggered remotely.

That created the most interesting problem in the entire project:

How can Codex pause a task, tell Express that it needs approval, send that request all the way to my phone, and then continue the exact same task after I approve it?

Process Completion Is Not Task Completion

My first runner treated:

child.on("close", ...)

as:

TASK FINISHED

That makes sense for a one-shot command.

But it becomes limiting once the agent needs an interactive lifecycle.

What I actually needed was:

Persistent Codex process

      │
      ├── Turn
      │    │
      │    ├── working
      │    ├── working
      │    ├── approval required
      │    │       ↓
      │    │      WAIT
      │    │       ↓
      │    │    approved
      │    │
      │    ├── continue
      │    │
      │    └── completed
      │
      └── ready for next turn

That led me to using Codex App Server.

Turning Approval Into an Event

With an event-driven Codex integration, Express can receive lifecycle messages while the task is still running.

An approval request is no longer equivalent to task completion.

Instead:

approval request
      ≠
task completed

Codex can effectively tell the runner:

"I'm still working on this turn,
but I need a human decision before
I can continue."

The runner stores that pending approval and triggers a dedicated n8n webhook.

The Approval Journey

This is probably my favorite part of the system.

Suppose Codex needs permission.

The request travels:

Codex
   ↓
Express Runner
   ↓
n8n
   ↓
Cloudflare Tunnel
   ↓
Telegram

On my phone I receive something like:

⚠️ Codex Approval Required

Project:
resume-web

Action:
<requested operation>

[ Approve ]   [ Reject ]

I press:

Approve

and the response travels back through the automation:

Telegram
   ↓
Cloudflare
   ↓
n8n
   ↓
Express Runner
   ↓
Codex

The important part is that this isn't a new coding task.

It's a response to the existing paused Codex turn.

Codex receives the decision and continues exactly where it stopped.

Keeping n8n Synchronous

There was one design decision from my original implementation that I intentionally kept.

The n8n request waits until Codex finishes.

Why?

Because it gives me an extremely simple final-result pipeline:

Codex finishes
      ↓
Express responds
      ↓
n8n immediately continues
      ↓
Telegram receives result

I don't need:

GET /task/status
GET /task/status
GET /task/status
GET /task/status

or another polling mechanism.

Express simply awaits the Codex turn.

Conceptually:

const result = await codexRunner.runTurn({
  project,
  task
});

res.json(result);

If approval never happens:

Task
 ↓
Codex
 ↓
Complete
 ↓
HTTP response

If approval happens:

Task
 ↓
Codex
 ↓
Approval required
 ↓
Telegram
 ↓
Approve
 ↓
Codex continues
 ↓
Complete
 ↓
HTTP response

From the original n8n workflow's perspective, both eventually produce the same result.

Profiling the Agent

I also wanted to know how long Codex actually takes to perform tasks.

So my runner logs execution duration.

Originally:

{
  "project": "resume-web",
  "durationMs": 128421,
  "success": true
}

But remote approval introduced an interesting problem.

Suppose:

Codex works         2 minutes
I ignore Telegram   6 minutes
Codex continues     1 minute

Total wall-clock time:

9 minutes

But saying:

"Codex took 9 minutes"

wouldn't really be accurate.

So I separated:

{
  "durationMs": 540000,
  "codexActiveMs": 180000,
  "approvalWaitMs": 360000,
  "approvalCount": 1
}

This opens up some interesting profiling possibilities later:

Average task duration
Average Codex active time
Approval frequency
Human response time
Failure rate
Commands per task
Performance by project

The Full Architecture

After putting everything together, my system now looks like this:

                         INTERNET

                  ┌───────────────────┐
                  │     Telegram      │
                  │       Bot         │
                  └─────────┬─────────┘
                            │
                            │ HTTPS
                            ▼
                  ┌───────────────────┐
                  │    Cloudflare     │
                  │      Tunnel       │
                  └─────────┬─────────┘
                            │
                    outbound tunnel
                            │
════════════════════════════╪══════════════════
                    LOCAL MACHINE
                            │
                            ▼
                  ┌───────────────────┐
                  │        n8n        │
                  │   Orchestration   │
                  └─────────┬─────────┘
                            │
                            │ localhost
                            ▼
                  ┌───────────────────┐
                  │  Express Runner   │
                  │                   │
                  │ • project map     │
                  │ • task lifecycle  │
                  │ • approval state  │
                  │ • profiling       │
                  │ • logging         │
                  └─────────┬─────────┘
                            │
                            │ JSON-RPC
                            ▼
                  ┌───────────────────┐
                  │ Codex App Server  │
                  │                   │
                  │ • thread          │
                  │ • turn            │
                  │ • tools           │
                  │ • approvals       │
                  └─────────┬─────────┘
                            │
                            ▼
                  ┌───────────────────┐
                  │ Local Repository  │
                  │                   │
                  │ Code / Git / Test │
                  └───────────────────┘

Each component has a very specific job:

Telegram
    → Remote interface

Cloudflare Tunnel
    → Public ingress to my local environment

n8n
    → Workflow orchestration

Express.js
    → Codex process + task management

Codex
    → Autonomous coding agent

Git repository
    → Actual development workspace

I think that separation is one of the reasons the project stayed relatively understandable.

Is This Really Autonomous Coding?

I wouldn't describe this as fully autonomous software development.

I'm still responsible for deciding what gets built, reviewing important changes, controlling permissions, and deciding what eventually reaches production.

But once I provide a task, the implementation loop can happen independently:

Inspect
   ↓
Plan
   ↓
Modify
   ↓
Build
   ↓
Test
   ↓
Fail
   ↓
Debug
   ↓
Fix
   ↓
Retest
   ↓
Complete

And if the agent reaches something requiring my judgment:

Agent
  ↓
Human decision required
  ↓
Telegram
  ↓
Me

That's why I prefer the term:

Human-in-the-loop autonomous coding.

Why I Didn't Just Give Codex Full Access

There is obviously a much easier solution to the approval problem:

Give the coding agent unrestricted access.

Then there are no approval interruptions.

But that's exactly what I didn't want.

Instead, the philosophy behind my setup is:

Normal development work
        ↓
     AUTOMATIC

Sensitive operation
        ↓
    ASK HUMAN

For example:

Read repository
        → automatic

Edit workspace
        → automatic

Run tests
        → automatic

Inspect Git
        → automatic

Sensitive command
        → approval

Outside workspace
        → approval

Network operation
        → approval

Destructive operation
        → approval

The goal isn't to remove myself from development.

It's to move myself:

FROM

execution loop

TO

decision loop

And I think that's a much more useful form of automation.

What I Want to Add Next

The current system already works, but there are several things I'd like to improve.

I want commands such as:

/status

to return something like:

Project: resume-web
Task: Add API rate limiting
Status: Running
Duration: 02:41
Approvals: 0

I'd also like:

/cancel

to interrupt an active Codex turn.

Another obvious improvement is task queues.

I don't necessarily want:

Task A ─┐
Task B ─┼─→ same repository
Task C ─┘

all editing files simultaneously.

Instead:

resume-web

Task A → RUNNING
Task B → QUEUED
Task C → QUEUED

Git branch isolation would also make the system much safer:

Telegram task
      ↓
Create branch
      ↓
Codex works
      ↓
Tests
      ↓
Return diff
      ↓
Human review
      ↓
Merge

And eventually, persistent state would help recover from crashes or restarts while approvals are pending.

What I Learned

At first, I thought this project would mostly be about AI.

It wasn't.

The most interesting problems ended up being orchestration problems:

How does Telegram reach localhost?

Who owns task state?

What does "completed" mean?

How does an agent pause?

How do approvals travel between systems?

How does execution resume?

What happens if something crashes?

Which operations should be automatic?

Which operations require humans?

The model is only one part of an autonomous system.

The infrastructure around the model determines whether it can actually operate reliably.

The Bigger Idea

Before building this, my workflow looked roughly like:

Open laptop
   ↓
Open terminal
   ↓
Navigate to repository
   ↓
Launch coding agent
   ↓
Give instruction
   ↓
Watch execution
   ↓
Approve action
   ↓
Wait
   ↓
Review

Now:

Take phone
   ↓
Open Telegram
   ↓
Send task
   ↓
Put phone away

Then, if necessary:

Telegram:

⚠️ Codex needs approval

[Approve] [Reject]

And eventually:

Telegram:

✅ Task completed

My development machine is still doing the actual work.

I'm still responsible for the important decisions.

But I no longer need to sit in front of it while the agent performs every step.

And that's probably the biggest thing I learned from this project:

The next step for coding agents isn't necessarily removing developers. It's reducing how much of the execution loop requires a developer's continuous attention.

Sometimes the biggest improvement isn't another model.

It's building better infrastructure around the one you already have.