TL;DR: Explore, then build
A compact visual summary of a two-stage workflow for coding with AI: explore the problem space first, then hand off a clear brief to a coding agent.
A two-staged approach
The more I use AI to write code, the more I think a two-stage workflow is the right mental model.
The first stage is exploratory. In this phase I want a conversational model that helps me reason about the problem, look at the space of possible solutions, compare approaches, and ask questions I might not have thought of myself. This is the phase where I want amplitude, alternatives, and criticism.
The second stage is the building phase. Once I understand the problem well enough, I switch to a coding agent and give it a tighter brief: ideally a summary of what I found, or the full conversation if the context is short enough. At that point the goal is no longer to explore, but to execute.
Why does this work well?
Because it separates two different jobs:
- The thinking phase, where I want breadth and ambiguity.
- The construction phase, where I want focus and implementation detail.
That separation matters because the model that writes code does not also need to carry the burden of deciding the direction of the work. When I mix those two roles together, I often get something that is neither a good exploration nor a clean implementation.
To me, that is the real advantage: I can spend more time understanding the problem, and less time fighting the model over whether the problem itself was framed correctly.
A concrete example
A good example is a problem I had in Google Search Console.
I noticed that I had duplicate articles because I was generating both docs/slug pages and /slug pages. In practice, that meant Google could not reliably decide which version should be treated as canonical. The result was exactly the kind of SEO mess you do not want: duplicate indexed pages, ambiguous signals, and an indexing graph that kept growing instead of settling down.
At that point I did not want a coding agent to start modifying files blindly. First I wanted to understand the shape of the problem. So I asked Perplexity to help me reason about the canonical URL strategy. The key idea that came out of that exploration was simple: pick one canonical URL pattern and stick to it. In other words, if the site already standardises on /posts/YYYY/MM/DD/slug/index.html, that should become the single source of truth, and every duplicate variant should point back to it.
From analysis to implementation
Once I had the answer I extracted the Markdown output (thanks for that feature Perplexity!), and I moved to Codex for the build phase.
The first implementation pass focused on canonical tags and sitemap normalisation. Quarto already had canonical tags enabled, so the missing piece was to keep sitemap.xml aligned with the trailing-slash canonical URLs. That meant normalising /index.html URLs, removing duplicate <loc> entries, and making sure the generated sitemap matched the canonical form I wanted Google to see.
Later, after validating against the Search Console export, I realised the problem was still broader than the first pass suggested. I wanted to make sure the fix also covered the list of affected pages reported by Search Console, not just the rendered Quarto pages. So the solution evolved again: the post-render hook was expanded, the sitemap handling was improved, and missing canonical tags were injected into published static HTML pages under docs/ as well.
That back and forth was important. The conversational model helped me reason about the problem, the coding agent helped me implement the fix, and the validation step showed me where the implementation still needed to be refined.
What I learned
This is why I like the two-stage workflow.
If I ask a coding agent to do everything at once, I often get code before I get clarity. This is something that was also being discussed pre-coding agent, think about the problem before writing a single line of code. Bonus point, splitting the work into phases makes the process more disciplined.
It also makes iteration easier. I can inspect the problem, implement a first version, validate it, and then go back for another round only if the evidence says I need to.
So, this is a suggestion you might want to try: use one model to explore the space, and another model to build once the direction is clear.
If you are working with AI to write code, I think that distinction matters more than most people initially expect.