A “Junior Engineer” AI Agent for Deterministic Engineering Workflows

Ajiferuke Tomiwa — Thu, 22 Jan 2026 20:48:03 +0000

Originally published on Medium:
https://medium.com/@ajiferukeolatommy/a-junior-engineer-ai-agent-for-deterministic-engineering-workflows-b71fbdcb685d

Most AI developer tools aim too high.

They try to behave like senior or principal engineers: proposing architectures, refactoring large codebases, or making design decisions that normally require deep domain context. That can be impressive — but it often targets the wrong layer of the problem.

In practice, most engineering time isn’t spent on architecture. It’s spent on workflow execution: selecting work, enforcing rules, moving tickets, triggering automation, and dealing with the fallout when automation behaves unpredictably.

This post describes a different approach: a “Junior Engineer” AI agent designed specifically for deterministic engineering workflows.

The goal isn’t to replace human judgment. It’s to execute process reliably, draft small changes, and return decision-making to humans.

The problem: workflow is where engineering time leaks

Across many teams, engineers routinely lose time to tasks like:

Determining which ticket is actually eligible to work on
Verifying status, size, and flags
Manually advancing tickets
Triggering automation
Debugging CI pipelines with unclear failures
Writing glue code that exists only to satisfy process

None of this work is especially creative — but it’s necessary. It’s also repetitive, error-prone, and a poor use of senior attention.

Crucially, these tasks require precision, not creativity. That makes them a poor fit for humans — and a strong fit for a constrained AI agent.

Why a “Junior Engineer” agent?

Junior engineers tend to be good at one thing many systems struggle with: following instructions literally and carefully.

They read requirements closely, apply rules exactly, and debug failures step by step. They don’t rely on intuition or silently skip edge cases.

That mindset is ideal for workflow execution.

Instead of asking AI to reason like a senior engineer, this system intentionally constrains the agent.

The agent is not allowed to:

Make architecture decisions
Make product judgments
Perform large refactors
Invent “best practices” changes

The agent is allowed to:

Execute deterministic rules
Make small, scoped changes
Produce partial implementations
Leave TODOs when requirements are ambiguous
Fail loudly and explain why

Those constraints are what make the system 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 remove mechanical work and make gaps visible earlier.

Real-world architecture: a multi-repo agent system

This is not a single script or a monorepo trick. The system spans multiple repositories, each with a clear responsibility.

Repository roles (anonymized)

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

High-level architecture of the “Junior Engineer” agent system.
The controller executes workflow deterministically, routing work through a standards layer into product repositories, where automated review agents prepare PRs before human judgment.

Responsibility breakdown

Component	Responsibility
agent-controller	Workflow execution, ticket selection, orchestration
standards	Centralized routing logic, prompts, guardrails
product repos	Actual code changes (frontend, backend, services)
review tooling	Automated review before humans

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

The agent crew (clear boundaries)

1. Junior Engineer Agent (controller)

Runs in the agent-controller repo and:

Queries the project system
Applies strict eligibility rules
Selects exactly one unit of work
Claims it deterministically
Dispatches downstream workflows

It does not touch product code.

2. Standards router (coordinator)

Lives in the standards repo and:

Interprets ticket metadata
Decides which repository should handle the work
Selects the correct workflow and prompt
Enforces consistency across teams

This prevents every repo from inventing its own agent behavior.

3. Execution agents (product repos)

Run inside frontend / backend / service repos and:

Receive structured context
Generate minimal diffs
Add scaffolding or TODOs if unclear
Open pull requests

They are intentionally conservative.

4. Automated review agents

Before humans see the PR:

AI review (e.g., Codex-based review)
Tools like CodeRabbit
Tests, linters, and security checks

They surface issues — they do not approve changes.

5. Humans (final authority)

Humans review:

Business logic
Domain correctness
Risk and deployment implications

No AI merges code.

End-to-end flow

Trigger (manual / scheduled)
        ↓
agent-controller repo
  - pick ONE ticket
  - move to In Progress
  - dispatch standards router
        ↓
standards repo
  - determine target repo
  - select prompt + workflow
        ↓
product repo
  - generate draft PR (AI)
        ↓
automated review agents
        ↓
humans review & merge

There’s no hidden state. Everything is visible through commits, pull requests, and logs.

Prerequisites (one-time setup)

Secrets

In each repo that runs the execution agent:

OPENAI_API_KEY

In controller, standards, and product repos:

GH_TOKEN (recommended for cross-repo workflow dispatch)

Variables

Configuration such as project IDs, status field IDs, routing targets, and workflow names are stored as repository or organization-level variables. This keeps workflows generic and reusable across repos.

Why this setup works (and stays safe)

Determinism

The controller selects exactly one ticket
The router selects exactly one target repo
Execution agents produce small, scoped PRs

Safety

No AI merges code
Automated reviews run before humans
Humans retain judgment over business logic and deployment

Cost

No workflow SaaS subscriptions
Only CI minutes, API usage, and optional free review tools

How to run it

Trigger the controller workflow (manual or scheduled)
The controller claims one eligible ticket
The standards router determines the target repo
The execution agent drafts a PR
Review agents comment
Humans review and merge

The outcome

Engineers stop spending time on:

Ticket triage
Status churn
Boilerplate automation
Cross-repo coordination

They spend time on:

Reviewing logic
Understanding behavior
Assessing risk
Shipping confidently

Final thought

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

Sometimes the highest-leverage move is building:

a careful junior engineer
coordinated by clear standards
executing workflows deterministically

so humans can focus on judgment.

Forem: Ajiferuke Tomiwa