Daisuke Masuda

Agreed on the order: sandbox first, then evaluate whether a model swap actually helps. A better model won’t fix an overprivileged executor or a command running in the wrong directory. That’s the distinction I wanted to make in the article: policy checks decide whether an action should run, while execution boundaries constrain what it can touch if something goes wrong. Explicit working directories, restricted filesystem and network access, and scoped credentials belong in that execution layer—not just in the prompt. Debugging should let us reproduce a bad tool call without turning the investigation into another production incident. Thanks for making the priority explicit.

Thanks for calling this out—and for the concrete migration example. I’d fold it into the execution layer’s contract. The article leaves that concurrency requirement underspecified. You’re right that binding approval to an action hash prevents substitution, but doesn’t make two independently approved actions safe to execute concurrently. The executor should acquire a lock scoped to the affected resource before execution, with conflicting approved actions remaining queued. I’d add one requirement after acquiring that lock: revalidate the action’s preconditions against the current resource state. If migration A changes the schema that migration B was evaluated against, B’s approval may still be unexpired and correctly bound to its action, while the assumptions behind that approval no longer hold. In that case, the executor should stop and return it for re-evaluation—and renewed approval if the approved assumptions or operation change. So the contract I’d make explicit is: acquire the resource lock, recheck approval validity and resource preconditions, execute, and record the resulting state before releasing the lock. A queued action gets those checks when it actually reaches execution. That belongs alongside the credential boundary you highlighted. Approval establishes authority for an operation; the executor also has to establish that the operation is valid against the state it is about to change.

Thank you so much, Sanoary! I really appreciate your thoughtful comment. I completely agree—the real measure of AI tooling is not how impressive the technology looks in isolation, but whether it helps teams solve meaningful problems and deliver reliable, accepted engineering outcomes. I’ll keep exploring that intersection between technology, engineering practice, and business value in future articles. Thanks again for reading!

Thank you for the thoughtful comment. I partially agree. You're right that thorough review remains essential — no one should blindly accept changes without understanding them. That said, I've found that in many cases, it's actually more effective to re-engage the agent and ask it to explain or walk through the specific changes it made, rather than reading every single line manually from scratch. This often helps highlight the important or risky parts more efficiently while still keeping human oversight. Of course, for critical or high-risk changes, there's no substitute for carefully reading through the diff yourself. Do you have any particular methods or prompts you use when reviewing agent-generated code?

Thank you! I completely agree. It really does depend on the workflow and the type of task. Claude Code is excellent when you need strong reasoning and careful exploration through complex problems, while Codex integrates more seamlessly with existing GitHub workflows and feels more efficient for implementation-focused work. That’s actually one of the main points I tried to highlight in the article with the decision table. I’ve been using both depending on the situation, and I think trying them on real projects (as you mentioned) is the best way to figure out what fits your own style. Have you found yourself leaning toward one more than the other lately?

Thank you for the question! Right now, I personally feel that Codex is more effective than the latest Claude Code (4.8) for most practical development work. The main reasons are: It tends to handle larger, repository-wide changes more reliably with fewer off-track modifications. The GitHub integration feels more seamless — it produces cleaner, better-structured PRs that are easier to review. It stays better within the scope I define, which reduces the amount of back-and-forth needed compared to the more interactive approach of Claude Code. That said, Claude Code is still excellent for exploratory investigation and smaller, step-by-step tasks where you want tight control and frequent confirmations. It really depends on the type of work, but for end-to-end implementation and shipping features, Codex has been giving me better results lately. What kind of tasks are you mainly using these agents for?