Engineering Agent
By Dumebi
An engineering agent I am building at Rakuten for multiple teams within the travel development department. Think of the most useful intern you have ever worked with: you describe a problem in plain words ("the booking date shows the wrong timezone for users in Australia"), and it reads the code, finds the cause, makes the change, runs the tests, and comes back with a pull request and a note explaining what it did. A human reviews everything before it counts.
It runs in five modes:
Fix (the default): takes a ticket from PRD to pull request through a staged pipeline: ticket intake, a solvability check (a low score stops the run, and the agent can offer an investigation instead), codebase analysis, a dev spec, implementation, quality gates, and the PR. The dev spec is a hard gate: a human has to approve it before any code gets written.
PR review: hand it a pull request link and dedicated subagents review it.
Explore: reads the codebase and answers questions grounded in what is actually there.
Ask: a general helpdesk. "How do I center a div" territory.
Database: talk to the database in plain English.
Under the hood:
A read, decide, act, observe loop armed with developer tools: read files, search the codebase, edit, run tests, open pull requests.
Guardrails by construction on input and output: the model proposes, the harness disposes. It opens pull requests but can never merge, and dangerous actions are simply not in its toolbox.
A sandboxed workspace per task, so the worst case is a bad PR that costs one click to close.
Human-in-the-loop gates for anything irreversible.
Full transcripts of every tool call and result, so you can replay exactly what it did and why.
Subagents with smaller, focused contexts for work like triage and summarisation.
Evaluated against real tasks with known-good outcomes, not vibes.
Built in Python with Chainlit as the chat-style front door, running on Kubernetes. I am also writing an essay series about building it: Building the Engineering Agent.