---
id: "lib-2026-10-22-layerx-s-in-house-background-coding-agent-haro"
type: "library"
title: "LayerX's in-house background coding agent \"haro\""
title_original: "内製 Background Coding Agent \"haro\" で拓く未来の開発体験"
lang: "JA"
org: "LayerX"
source_type: "Practitioner post"
date: "2026-10-22"
week: "2026-W43"
url: "https://nosov.ai/library/lib-2026-10-22-layerx-s-in-house-background-coding-agent-haro/"
original_url: "https://tech.layerx.co.jp/entry/why-we-built-our-background-agent"
tier: "B"
tier_name: "Useful, limited"
tier_reason: "LayerX platform engineering lead describes an in-house cloud coding agent with architecture and adoption figures; a clear build case, but the metrics count PRs created, not merged or valuable, and there is no cost data."
summary_basis: "full-text"
original_minutes: "8"
tags: ["background agents", "coding agents", "platform engineering", "pr share"]
---

# LayerX's in-house background coding agent "haro"

Original title: 内製 Background Coding Agent "haro" で拓く未来の開発体験

Tier B (Useful, limited): LayerX platform engineering lead describes an in-house cloud coding agent with architecture and adoption figures; a clear build case, but the metrics count PRs created, not merged or valuable, and there is no cost data.

Summary based on the full text.

## In short

A LayerX engineering blog post (22 October 2026) by izumin5210, Staff Software Engineer in the Bakuraku division's Platform Engineering group. The team built haro, a cloud coding agent invoked from a web UI or Slack, similar to Ramp's Inspect. Each session gets a full Bakuraku development environment in which Claude Code or another agent harness runs. Work on the current version began in mid-July 2026; by October more than half of the repository's daily PRs came from haro. The post argues that off-the-shelf cloud agents could not handle this monorepo and its internal tooling well enough.

## Key numbers

- 55-60%: share of the monorepo's daily PRs created through haro by October 2026
- ~200: PRs a day created on haro (just under 200)
- 58: people using haro in October, over half of the Bakuraku division's engineers
- 87%: share of PRs created via haro in the heaviest-using team
- ~75%: share of mobile app team PRs implemented on haro

## What it reports

- Motivation: local machines run out of memory before people run out of attention when running parallel worktrees on a large monorepo; generic products fit the codebase and internal tools poorly.
- Architecture: TypeScript control app on Temporal workflows drives the agent harness via AI SDK; environments run on EKS with a custom resource definition and controller.
- MCP connections to Slack, Notion, Linear, Datadog, Snowflake and internal services, using each person's own account so nobody manages keys. One internal tool shows agent-generated HTML designs and lets people comment on them for the agent to read.
- By October 2026: 55-60% of daily PRs, just under 200, created on haro; 58 people, over half the division's engineers. One team creates 87% of its PRs there; the mobile team about 75%, helped by Android emulators running in the cloud environment.
- Non-engineers use it too: designers fix mobile UI, QA engineers derive test angles from diffs and run automated checks.
- Custom agents (system prompt, MCP tools, environment) can be triggered from Slack, a scheduler or an API: scheduled bug and security scans, daily metric posts, one-click flaky-test fixes. The haro team uses haro to deploy, monitor and debug haro.
- Sessions are public by default, with access limits for those touching customer data, so people can learn from skilled colleagues' sessions.

## How they got it

Platform team's own usage telemetry (PR counts, active people, sessions), shown in charts. The KPI is the share of repository PRs created via haro, chosen as an indirect adoption measure.

## Limits

- PRs created is an activity measure; merge rate, defects and review load are not reported.
- No compute, token or staffing cost figures.
- Single company, single monorepo, about three months of data; the post doubles as a recruiting piece.

## Why it matters for companies

The case shows where in-house build beats buying for coding agents: large monorepos, internal tools and the need to reuse each person's own credentials across services. It also shows the agent becoming a general automation base (scheduled scans, incident triage) once it runs in the cloud rather than on a laptop. Public sessions are a cheap way to spread good practice. Firms copying this should track merged and reverted work, not only PR counts.

## Key passages in translation

> 人間の認知よりも先にメモリが限界を迎えている状況です。

Memory hits its limit before human cognition does.

> 10月時点で1日の PR のうち55〜60%程度、数にして200件弱の PR が haro 上で作成されています。

As of October, about 55-60% of daily PRs, just under 200, are created on haro.

> haro 上のセッション（Agentとのやり取り）は原則公開であり、ほかの社員からもそのやり取りが見えるようになります

Sessions on haro (exchanges with the agent) are public by default, so other staff can see them.

Original: https://tech.layerx.co.jp/entry/why-we-built-our-background-agent