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.