專為確定性工程工作流程設計的「初級工程師」AI代理

Sign up

Sign in

Sign up

Sign in

A ‘Junior Engineer’ AI Agent for Deterministic Engineering Workflows

--

Listen

Share

Modern AI developer tools often aim too high: they try to behave like senior engineers — proposing architectures, refactoring whole codebases, and making decisions that really require deep domain context.

That’s impressive, but it misses where most teams actually lose time.

Most engineering hours aren’t spent on architecture. They’re spent on workflow execution: selecting the right work, enforcing rules, moving tickets, triggering automation, and cleaning up the mess when automation runs unpredictably.

This post describes a different approach: a “Junior Engineer” AI Agent designed specifically for deterministic engineering workflows. It doesn’t replace human judgment — it executes the process reliably, drafts small changes, and hands decision-making back to humans.

The problem: workflow is where engineering time leaks

In many teams, engineers burn time on tasks like:

None of this work is “hard”, but it's expensive. It’s repetitive and error-prone, and it steals attention from the parts of engineering that actually require judgement.

Most importantly: these tasks require precision, not creativity — which makes them a great fit for a constrained agent.

Why a “Junior Engineer” agent?

Junior engineers tend to be great at one thing: following instructions literally and carefully.

So instead of building an AI that tries to “think like a principal”, this system constrains the agent on purpose.

The agent is not allowed to:

The agent is allowed to:

Those constraints are what make it reliable.

What this system does not do

This approach does not fix poor requirements, unclear ownership, or weak product decisions. It does not understand domain context automatically, and it does not eliminate the need for careful human review.

The agent executes workflows faithfully — which means it will also faithfully surface ambiguity or inconsistency instead of silently “working around” it. That’s intentional. The goal is not to replace thinking, but to make gaps visible early and remove the mechanical work that distracts engineers from judgment.

Real-world architecture: a multi-repo agent system

The rest of this post walks through how each of these components works in practice, and how they coordinate across repositories without introducing hidden state or coupling.

Repository roles (anonymized)

agent-controller-repo│├── standards-repo│ ├── routing logic│ ├── prompts│ └── shared rules│├── frontend-repo├── backend-repo└── worker-repo (optional)

Responsibility breakdown

This separation is deliberate. It avoids tight coupling and keeps the agent behavior versioned and auditable.

The agent crew (clear boundaries)

1. Junior Engineer Agent (controller)

Runs in the agent-controller repo and:

It does not touch product code.

2. Standards router (coordinator)

Lives in the standards repo and:

3. Execution agents (product repos)

Run inside frontend / backend / service repos and:

4. Automated review agents

Before humans see the PR:

These tools identify issues but do not approve any changes.

5. Humans (final authority)

Humans review:

No AI merges code.

End-to-end Flow

There’s no hidden state: everything is visible in commits, PRs, and logs.

Prerequisites (one-time setup)

A) Secrets

In each repo that runs Codex (frontend, backend, worker):

In controller + standards + product repos:

You can try ${{ secrets.GITHUB_TOKEN }}, but cross-repo workflow dispatch often requires a PAT depending on org settings.

B) Variables (controller repo)

Create Actions Variables in agent-controller:

Routing targets:

Claim label:

C) Variables (standards repo)

Create Actions Variables in standards:

1) agent-controller repo (complete workflow)

Create: agent-controller/.github/workflows/agent-pick.yml

This script:

2) standards repo (complete router workflow)

Create: standards/.github/workflows/agent-router.yml

This router:

3) product repo execution workflow (complete, reusable)

Create this same file in each product repo:

This workflow:

4) pre-human review layer (Codex review + CodeRabbit)

CodeRabbit is typically configured as a GitHub App integration, not a workflow you write yourself. Once installed, it will comment automatically on PRs (free tier available). You can mention it in the blog as an optional pre-human review agent.

Why this setup works (and stays safe)

Determinism

Safety

Cost

How to run it

The outcome

Engineers stop spending time on:

They spend time on:

Final thought

AI doesn’t need to think like a senior engineer to be useful.

Sometimes the highest leverage move is building:

so humans can focus on judgment.

--

--

Written by Ajiferukeolatommy

No responses yet

Help

Status

About

Careers

Press

Blog

Privacy

Rules

Terms

Text to speech