Two Japanese developer write-ups this week land on the same underlying question: once an AI coding assistant is good enough, how much of your workflow should you still hand-build yourself?
The first piece comes from a developer who had spent real effort crafting a custom review “skill” for Claude Code — essentially a bespoke prompt/config setup to get consistent, structured code review feedback. After revisiting Anthropic’s built-in /code-review command, they found it now groups findings by severity, so the most important issues are visually obvious the moment the review renders. That was enough to make them shelve their custom tooling and run the stock command instead.
What’s more useful than the anecdote itself is the follow-up: documentation on /code-review’s effort argument and the –fix and –comment flags is thin, so the author actually tested them against real pull requests in a personal repo — comparing how review depth changes with effort level, whether auto-fix produces safe patches, and how PR comments get posted. This kind of empirical probing matters more than it might seem. As official agent tooling absorbs functionality that used to require custom prompt engineering, the actionable knowledge shifts from “how do I build this feature myself” to “how do these built-in options actually behave under load,” which official docs rarely cover in enough depth.
The second piece pushes further downstream. Its author describes a familiar frustration: a PR gets review comments overnight, but by the time they notice, fix, and push again, an entire day has passed for a single feedback cycle. Inspired by an Anthropic engineer’s demo of a three-role agent loop — one agent plans, one implements, one judges the result — the author built their own version and kept it running continuously via launchd, macOS’s daemon/service manager, rather than triggering it manually per session.
The framing here is the interesting part: the claim isn’t that a smarter model produces better code, it’s that the design of the loop — how planning, implementation, and evaluation are separated and cycled — determines the quality of the outcome. That’s a meaningful shift in emphasis for anyone building on top of LLM coding agents. Model selection gets a lot of attention; loop architecture gets comparatively little, despite arguably mattering more once you’re trying to run unattended iterations rather than one-shot completions.
Running this as a persistent background daemon rather than an on-demand script is also worth pausing on. It turns code review and even implementation into something closer to a continuously running service than a tool you invoke. That raises the obvious follow-up questions the article doesn’t fully resolve for readers unfamiliar with the setup: what stops the judge agent from rubber-stamping bad implementations, what’s the blast radius if the loop pushes something broken, and what does cost/compute usage look like when the loop runs unsupervised overnight. These are exactly the operational concerns that matter once “agent loop” moves from demo video to real repository.
Taken together, these two pieces sketch a fairly clear trajectory: first, official single-shot commands catch up to and surpass bespoke prompt setups for well-defined tasks like code review. Second, once single-shot quality is good enough, the interesting engineering work moves to orchestration — chaining multiple agent roles into loops that run with less human babysitting. The skill being exercised is shifting from “write a good prompt” to “design a good process,” which is a genuinely different competency, closer to systems design than to prompt engineering.
There’s a third article in this week’s set that, at first glance, seems unrelated: a history of the word “freelance,” tracing it back to medieval knights who fought for whichever lord paid them rather than serving one permanently. It’s a language-and-history piece, not a technical one, but it’s a useful frame for the moment described above. As agent loops take over more of the repetitive judgment work in development — reviewing, fixing, re-checking — the human developer’s role increasingly resembles that of someone directing hired hands rather than doing every task personally. The freelance knight sold judgment and skill on a per-engagement basis rather than permanent loyalty; the developer running an agent loop is doing something structurally similar, contracting out routine execution while retaining oversight and direction.
None of this means custom tooling or manual review is obsolete. But the practical advice from this week’s experiments is straightforward: before building a bespoke Claude Code skill, test the official command’s current capabilities on a real PR first, and if you’re trying to speed up review cycles, spend your design effort on the loop structure — planner, implementer, judge, and the checkpoints between them — rather than assuming a better model alone will close the gap.