When bots became colleagues, colleague-like incidents started
botが同僚になったら、同僚っぽい事故が起きはじめた
B · Useful, limited FastDoctor engineer's anecdotal but first-hand account of a team where each person runs an autonomous bot in Slack; few numbers and no method, but rare field detail on bot-to-bot coordination failures.
Summary based on the full text·Original: about 5 minutes to read
In short
A Zenn post (13 October 2026) on the tech blog of FastDoctor, a Japanese medical services company, by engineer Manabu. It follows an earlier piece on Grok bots spreading through his team. A month later, bots open most threads in the development-request channel, post everything between 21:00 and 08:00, and review each other's work overnight. The post catalogues the "colleague-like" incidents that followed: duplicate tickets, missed mentions, unrequested fixes, and bots negotiating work between themselves.
Key numbers
- 80-90%share of answered threads in the development-request channel opened by bots in September
- 33 secondstime from a request to the bot's "starting work" reply
- 19 minutestime from a request to a human review request on the finished change
- 11similar requests arriving at once, all claimed and then withdrawn by the CTO's bot
As reported by the source.
Japanese·Web page·opens zenn.dev
What it reports
- From September, bots opened 80-90% of answered threads in the dev-request channel; every post between 21:00 and 08:00 in September came from a bot.
- The most common complaint about the bots was unclear Japanese, not bugs: a non-engineer domain expert could not follow their spec questions. After rewriting to target, conditions, one question and options, answers came within 10 minutes; the fix needed repeating several times.
- Speed: 33 seconds to "starting work", 19 minutes to a human review request.
- Bots fixed edge cases nobody asked for and opened PRs while questions were still open; the domain expert reported unintended changes.
- The author's bot missed the CTO's bot's review and reopened the thread; a three-exchange cap per PR prevented a loop, and "no re-review without a new commit" was added.
- Bots ignored messages without an explicit mention, filed duplicate tickets and merged them between themselves within a minute, and the CTO's bot asked for help because it was short of tokens, which led to a delegated bot working under the author's name while he was on holiday.
- Human work shifted from "do this" to asking "who decided this?" before approving; progress tracking moved to a GitHub project board in early October.
How they got it
Personal observation and Slack screenshots from one team. No logs, counts beyond those above, or quality measures.
Limits
- Single team, anecdotal, informal tone; numbers come from the author's reading of the channel.
- Says little about code quality or defect rates.
- Ends with a recruitment pitch.
Why it matters for companies
Once each person has an agent acting for them, the coordination problems of human teams reappear between agents: unclear ownership, duplicated work, missed hand-offs. The fixes are the same as for people, written as explicit rules: mandatory mentions, caps on repeated exchanges, a single board showing who holds each task. The other lesson is about accountability: when bots act fast and helpfully, the human's job becomes checking where a decision came from before signing off, and agents writing to non-technical staff need audience-specific instructions.
Key passages in translation
Japanese original
バグでもテスト落ちでもなく、「何を言ってるか分からない」でした
Not bugs, not failed tests, but "I don't understand what it's saying".
Japanese original
LGTM（承認）を押す前に「それ誰が決めたの？」とSlackに打つことが、10月に入って増えました
Since October I type "who decided this?" in Slack more often before pressing LGTM (approve).
Japanese original
今、それとまったく同じことがbotの間で起きてます。
Right now exactly the same thing is happening between the bots.
Summary based on the full text. Read the original for the full argument and data.Read the original on zenn.dev
- Tags
- Governance