Each week, the newsletter features a workflow from an engineer using AI coding tools in their actual work. This page collects all of them in one place and serves as a living archive for the "Workflow of the Week" section from the newsletter.
I publish Agentic Coding Weekly every Monday. If you want new workflows like these in your inbox, subscribe below.
Table of Contents
Paul Willot: Claude Code Setup and Planning-Execution-Expansion Workflow Loop
Published in ACW #9 on Jan 19, 2026.
This week's workflow is from Paul Willot, Senior Machine Learning Engineer at Liquid AI. Over to Paul:
I'm very much a terminal guy, so I focus on using CLI tools in a way that maintains control over the output.
My Tool Stack
I primarily use Claude Code in the terminal for actual coding, complemented by ChatGPT in the browser for research and planning. Occasionally I'll use Gemini for drafting UI parts since I've found it much better at spatial understanding.
For quick read-only exploration of a new codebase, I like using Gemini 3 Flash which has an impressive price/speed/quality balance. Used to call it through aider but switched to charmbracelet/crush in the last few months.
Claude Code Setup
I keep Claude Code largely vanilla, using a few MCP servers sporadically. I'm not currently using Agent Skills. Tried it when it was first introduced but found it hard to robustly control model behavior. Instead, I prepare a Makefile with self-documented targets, which are runnable by both agents and humans. It allows me to precisely control how the model runs and tests the codebase. I also pre-approve most tools to Claude and restrict access to specific files using standard file system permissions.
I mostly draft the CLAUDE.md for projects manually, but when I let it be auto-generated I review and trim it down cause LLMs like to be too exhaustive and include irrelevant details, which hurts focus down the line.
New Project Workflow
Planning: I start a ChatGPT deep research session to gather information and tools around the problem I'm tackling. Simultaneously, I also set up a skeleton repo with basic structure and environment setup. This GitHub repo shows my typical project structure for a Python project.
Execution: I use the deep research results to manually fill an initial TODO.md, then ask Claude to tackle the steps in order. I aim for the smallest possible MVP and review code and results frequently. I constrain the model fairly heavily in how to go about implementation at this stage.
Expansion: Once happy with the initial shape, I add tests and setup tooling for the agent, like playwright-mcp for projects with web UI parts. Then I add more ambitious tasks to the TODO.md, reset context, and let the agent run longer with less hand-holding.
When Things Go Wrong
When the model is stuck or things don't go as I like, instead of adding more instructions I often reset context and have the model work on a sub-problem first, then integrate that solution into the broader project. If that's still not working... I just do it myself!
— Paul
Christoph Nakazawa: Fire-and-Forget Approach to Agentic Coding
Published in ACW #8 on Jan 12, 2026.
This week's workflow is from Christoph Nakazawa, CEO at Nakazawa Tech.
The Fire-and-Forget Approach to Agentic Coding
Christoph primarily uses ChatGPT or Codex web. He's tried Claude Code and some open models, but never vibed with any of them. He prefers to stay in control, not a fan of terminal agents touching files on his computer. He wants agents to work in their own environment and send him the results for review.
The killer feature of Codex on web is the ability to specify how many versions of a solution you want. When I was building fate, I asked for 4 versions for anything slightly complex. As a result, I barely trust single-response LLMs anymore.
The approach is fire and forget. He doesn't always know what a solution should look like, and he's not a fan of specs. Code wins arguments. He fires off a prompt, looks at the results, and if it's not right or doesn't work, starts a fresh chat with a refined prompt. Planning happens in a regular ChatGPT chat with a non-Codex Thinking or Pro model.
He typically fires off 3-5 Codex sessions before stepping away from the computer or going to sleep, then works through each solution one by one. When done with a task, he archives all the chats and moves on.
A few things that he finds useful: turning memory off and starting a fresh chat for every question. Keeping a strict project structure so the model has rails to follow, then heavily editing and rewriting anything it generates before it touches the repo. Getting good at prompting a specific model, as the same prompt doesn't work as well with other LLMs. Building intuition for what it's good at and adjusting when a task takes more (or less) time than expected. Finally, treating the prompt input bar as a replacement for the todo list. Instead of filing a task, he drops the thought into a prompt. The change ships in an hour instead of sitting in a backlog forever.
Eunsu Jang: Parallel Codex Agents with Git Worktrees
Published in ACW #7 on Jan 5, 2026.
This week's workflow is from Eunsu Jang, Lead AI Application Engineer at Explaza. Over to Eunsu:
Parallel Codex Agents with Git Worktrees
I use an OSS coding agent orchestrator called vibe-kanban and give it the task prompt. It creates separate git worktrees and runs independent Codex agents for each task.
If the task is genuinely hard or ambiguous, I’ll kick off multiple runs with slightly different instructions, or just switch the Codex model (for example GPT-5.2 vs GPT-5.1 Codex Max). This tends to surface different tradeoffs: one version might be safer and boring, another might be over-engineered, another might match the existing architecture better. Since each implementation is isolated in worktrees, it’s easy to compare approaches without branches getting tangled.
I noticed that these models often over-engineer the implementation. So I add following instructions in the project AGENTS.md file:
## GENERAL RULES:
- Avoid over-engineering
- Follow DRY/YAGNI
- Respect the project architecture
- Fail fast. No invisible fallbacks.Once the agents finish, I deploy each worktree and test in the browser. Anything that fails basic self-QA gets dropped early. For the ones that look promising, I open a separate Codex session and have it score and compare them. The score is subjective, but it’s useful for forcing a clear decision.
Here’s the exact comparison prompt I use:
Worktree A and Worktree B are results of the task below. Please evaluate each on a 10-point scale based on:
1. No over-engineering
2. Proper use of DRY/YAGNI
3. Strict respect for the project architecture
4. Fail fast, no invisible fallbacks
Choose the better worktree and explain why.
Original task instruction:
...Finally, I select the winning worktree, issue small follow-up instructions for final polish, and create the PR.
— Eunsu
