https://arran4.github.io/blog/tags/chatgpt/Recent content in chatgpt on Arrans Technical blogHugo -- gohugo.ioentechnicalblog123@arran4.com (Arran Ubels)technicalblog123@arran4.com (Arran Ubels)Arran Ubels. This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.Wed, 26 Aug 2026 13:04:00 +1000https://arran4.github.io/blog/post/2026/038-jules-agy-codex-handoff/Wed, 26 Aug 2026 13:04:00 +1000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/038-jules-agy-codex-handoff/I have increasingly ended up using coding agents as a pipeline rather than a single worker. The important part of that pipeline is not only the Jules-to-Agy-or-Codex handoff. There is another agent sitting outside the implementation session: usually ChatGPT with GitHub integration, or another system that can inspect the issue, pull request, commits, comments, and CI independently. In practice my workflow looks more like this: use ChatGPT or another integrated assistant to understand the task and turn it into a focused Jules prompt; let Jules do the first codebase exploration and implementation; have the outside assistant review the resulting PR and each meaningful follow-up commit, checking Git rather than trusting Jules&rsquo; completion prose; use that review to write the next Jules PR response, answer a question Jules asks in its web session, or decide that no further prompt is needed; keep implementation changes inside Jules while Jules still owns the branch, because direct non-Jules pushes can be unwound by a later Jules update; when the Jules phase is deliberately over, either make very small, obvious fixes directly through the integrated GitHub tooling or hand substantial remaining work to Google Antigravity CLI (agy) or OpenAI Codex; if handing implementation to another agent, always create a new branch: either rebuild from current main or fork the last known-good Jules commit into a new branch; never let the replacement agent continue on the original Jules branch; review the Agy/Codex changes with the outside assistant as well; when switching away from Jules, retire the Jules PR: optionally leave an immediate transition comment saying the work is being moved to a new branch and continued by &lt;agent&gt;; once the replacement PR exists and is ready to become the canonical work, comment on the Jules PR with the replacement link and close the Jules PR without merging it; throughout the job, keep the PR/work unit narrow but record credible out-of-scope discoveries in the project&rsquo;s durable issue register, normally GitHub Issues, updating an existing issue rather than creating a duplicate when one already exists; at the end of the job, reconcile the open issue register against what actually landed: close issues that are now fully resolved, update partially resolved issues with what was fixed and what remains, and make sure pending fixes are linked accurately when the PR has not yet merged; only merge the replacement when I explicitly decide the work is ready.