AI coding workflow | First build to repair | Last updated 2026-05-18
My Windsurf to Codex Workflow for Real Project Cleanup
I do not expect Windsurf to finish every project perfectly. I use it for speed. It creates the first version, makes the idea visible, and gives me something to test. Then I use Codex when the project needs focused repair.
This is the workflow I use on real static sites, SEO systems, bilingual pages, and automation ideas. Windsurf gives me momentum. Codex helps me fix the parts that must be correct: routing, validation, schema, language, layout, and deployment cleanup.
This article supports my main guide on ChatGPT prompts for Windsurf. The missing piece is what happens after Windsurf has created the first build and the project starts showing real problems.
When I use Windsurf
I use Windsurf when the project needs a visible first draft. That might be a new blog page, a dashboard section, a static route, a CTA block, or a layout update. At this stage, speed matters because I need something concrete to inspect.
Windsurf is useful when the task is broad but still structured. If I provide a clear prompt, it can create the initial files and connect the obvious pieces. It helps me move from planning into testing.
But I treat the output as a first build, not a final build. The first version may have duplicated logic, weak copy, missing internal links, incomplete SEO metadata, or small CSS problems that only appear on mobile.
When I move the task to Codex
I move to Codex when the problem becomes specific. If a route returns 404, if FAQ schema is duplicated, if the Vietnamese page is still English, or if code blocks overflow the article card, I do not want another broad first draft. I want a careful fix.
Codex works best when I give it the failing URL, the likely source files, the expected behavior, and the commands to run. It can inspect the codebase, patch source files, rebuild, and tell me what changed.
This division of labor keeps the project calmer. Windsurf does not need to be perfect. Codex does not need to invent the whole feature. Each tool has a job.
What I collect before handing off to Codex
Before I send the Codex prompt, I collect evidence. Screenshots show visual layout problems. Error messages show exactly what failed. File paths help narrow the search. A validation command gives Codex a clear finish line.
The best handoff notes usually include the user-facing problem, the expected behavior, the source files to inspect, what not to change, and the test commands. This turns a messy issue into a repair ticket.
For SEO pages, I also include sitemap, canonical, hreflang, FAQ schema, internal links, and `/go/` redirect behavior. Those details are easy to break during a broad cleanup.
Prompt example: Codex repair prompt
This is the kind of prompt I use after Windsurf creates the first version and I find a concrete issue.
It is more focused than the Windsurf prompt because Codex is being asked to repair, not explore.
The first build is working locally, but the generated GitHub Pages output has a problem: /vi/blog/example-page/ still shows English article body. Inspect the article generator, Vietnamese localization module, generated site_output, and docs output. Fix the source pipeline so the Vietnamese page is natural Vietnamese while prompt/code blocks remain English. Do not change the English page. Rebuild, sync docs, run language integrity, validate links, and report exact files changed.Prompt example: validation and deployment cleanup
When the issue is close to deployment, I make the prompt even stricter. The tool should not invent new features. It should verify the current pipeline.
This is useful before committing a fix to a GitHub Pages site.
Run the local build and validation pipeline for this static site. Confirm sitemap includes the intended SEO pages, excludes /go/, has no broken internal links, has no placeholder text, and language integrity passes. Do not deploy. Do not call external APIs. If a generated docs page changed, explain whether it is required for GitHub Pages. Return exact git add commands and avoid git add .Common mistakes in the handoff
One mistake is handing Codex a vague complaint like "the site is broken." That creates unnecessary exploration. A better prompt says which URL is broken, what you expected, and which validation failed.
Another mistake is asking Windsurf to keep fixing the same issue after the first build becomes tangled. If the problem needs source-level reasoning, I move it to Codex instead of generating more layers on top.
A third mistake is skipping the final browser check. Tests can pass while the UI still feels wrong. I still open the page and inspect the article, CTA, language switcher, and prompt blocks.
FAQ
Should I use Windsurf or Codex first?
I use Windsurf first when I need a visible draft, then Codex when the problem becomes specific and needs careful repair.
What is Codex better at in this workflow?
Codex is better for focused debugging, refactoring, validation fixes, SEO cleanup, routing issues, and production-readiness tasks.
Can Windsurf finish a full project alone?
Sometimes it can get close, but I still test the result and use Codex when the project needs reliable cleanup.
What should I include in a Codex repair prompt?
Include the failing URL, expected behavior, likely source files, constraints, validation commands, and what not to change.
How does this help beginners?
It gives beginners a clear sequence: use Windsurf for momentum, test manually, then ask Codex to fix specific problems.
Next step
If you want to use this process on your own static site or app idea, start with the main workflow article, then use the checklist before sending your next prompt to Windsurf.
Read the main prompt workflowDownload the checklistGet new AI tool reviews and comparisons.
Join the research list for new AI/SaaS review updates. This static form is prepared for a future email provider.