Direct an AI website project.

I can direct the website without pretending I wrote the code.

I know what I want DLVX to communicate. I can tell when the company feels smaller than its experience, when a page is chaotic or when the next step makes no sense. That does not mean I wrote the application, implemented the form or configured its hosting. Those are different responsibilities, and pretending otherwise makes an AI project harder to manage.

My role is to make the important decisions: who the site is for, which promises it should make, which evidence belongs beside those promises and what has to work before a release. An implementation agent such as Codex can inspect a repository, propose changes and carry out technical work within its available tools and permissions. I still need someone responsible for assessing the result.

This guide uses the DLVX website release as a practical example. The work included new content, service-page corrections, desktop and mobile reviews, route checks and form verification. At the point this lesson was prepared, the final release still had a human verification step outstanding. A preview existed. That was not the same as a completed production switch.

The useful skill is learning what to ask for at each stage, what evidence answers the question and when a green result does not prove what you think it proves.

Start with a buyer journey and a release boundary.

“Make the website better” is a real expression of dissatisfaction, but a poor acceptance test. A coding agent can change colours, spacing, components and copy for hours without resolving the thing that bothered me. I need to describe the journey that should improve.

For DLVX, a useful journey is an established business arriving on a service page, understanding the scope, seeing attributable proof and sending an enquiry that reaches the right place. The homepage supports that journey. It is not the whole product.

Act as the implementation agent for this website change.

Outcome: A qualified visitor understands the service and can send
an enquiry that reaches the agreed destination with its context.

First inspect the current source, project instructions and live state.
Identify the route, shared components, form handler and deployment.
Do not infer that the newest local branch is the live website.

Preserve approved design and unrelated work. Propose the smallest
change that solves the stated buyer problem, then implement it.

Before release, provide:
- The changed files and why they changed.
- A preview link tied to the reviewed version.
- Desktop and mobile evidence.
- Relevant route, form and attribution checks.
- Remaining failures and the concrete release decision.

Keep the previous release recoverable. Do not claim a production
switch until the destination has been checked after the switch.

I would add the actual project’s permitted actions and limits below that prompt. If deployment is authorised, say so. If the work is preview-only, say that. Do not leave a business decision hidden inside “do whatever is best”.

Before edits begin, the agent should establish who else is working in the repository. A separate worktree can isolate a change, but it does not remove the need to integrate other people’s work before release. The practical question is whether the proposed release contains the accepted work already on production and the changes we intend to add.

Use the conversation for decisions and the workspace for implementation.

A ChatGPT or Claude project is useful for collecting the brief, references and decisions. It is not automatically the local application folder, and attaching a screenshot does not give the assistant the source behind it. Be explicit about the working environment.

For implementation in Codex, name the repository, the route or component, the expected behaviour and the evidence required. Ask it to inspect the actual files before making a plan. If you hand the task from a planning conversation to a coding workspace, carry over the accepted brief rather than relying on the tools to share your entire conversation.

OpenAI’s guidance on Codex describes working with implementation tasks, worktrees and reviewable changes. Use the actual diff as part of review, alongside the rendered result. A long explanation from the agent is not a replacement for either. OpenAI: Codex for engineering work.

I would not start by giving the agent a ten-page identity as the world’s greatest designer, engineer, SEO expert and conversion psychologist. I would give it the relevant project rules, one clear task and the evidence it must return. Extra instructions can conflict with each other, especially when old design preferences remain mixed with current ones.

Ask the question at the layer where the answer exists.

There are several different things people mean when they say “it works”. A source change may be correct but not deployed. A deployed page may look right while its form fails. A form can display success while the record never reaches the CRM. I want those states kept separate.

For our DLVX release, the checks covered 95 routes and 115 internal destinations. Those counts tell me the breadth of a particular check. They do not certify every sentence, every interaction or every possible visitor. I still needed to inspect the important journeys.

That distinction matters for SEO and AI discovery too. An accessible page with a sensible canonical is ready to be considered by a search system. It has not earned a ranking because the audit returned green. A guide can be technically indexable and still be generic. Content usefulness needs its own review.

Review the website as a buyer, then make the feedback specific.

I would first open the preview without reading the implementation report. Start on the same page a buyer would land on. What do I think the company does? What would I click? What feels unsupported or confusing? Then compare that experience with the brief.

“This feels chaotic” is a valid first observation. The next instruction should make it actionable: there are three calls to action competing in the same section, the heading is longer than the explanation, or a project image gives no indication of what DLVX actually delivered.

Review this rendered page against the accepted buyer journey.

Report material problems only. For each problem:
1. Name the visible element and viewport.
2. Explain what a visitor is likely to misunderstand or miss.
3. Propose the smallest correction that preserves the design.
4. State what should remain unchanged because it is good enough.

Separate factual proof problems from visual preferences.
Do not invent a client result to make a section feel stronger.
After the correction, render the same route and viewport again.

In the DLVX guide review, long article titles worked on desktop but wrapped into too many lines on mobile. The useful correction was to shorten the visible headings while retaining descriptive page metadata. Rewriting the whole design would have created work without addressing the actual defect.

For project proof, ask a different question: does this image and caption establish the claim beside it? A beautiful commerce screenshot does not prove that an AI support system is live. If the project was delivered through another studio, the attribution should make that relationship understandable. Trust improves when the evidence is precise.

The enquiry is not finished at the thank-you message.

A founder can assess a form without personally writing its handler. Describe the required outcome in normal language, then require the implementation agent to show the destination evidence.

For a campaign enquiry, I want the contact details, relevant service and useful source context to survive the journey. If someone opens the landing page, reads a case and then uses the contact form, the system should follow the agreed attribution rules. Clicking through the site should not accidentally erase the reason they arrived.

Attribution is a defined behaviour, not an invitation to collect everything. Agree which fields are needed, how long context persists and which result takes precedence when the visitor changes their selection. Test the agreed behaviour with synthetic records and clearly label them as internal checks.

Our release encountered a human verification boundary. That meant the remaining end-to-end check could not honestly be replaced with a screenshot of the form, a passing build or a simulated success response. The correct report was to name what had passed and the specific check still outstanding.

A good implementation agent should keep making independent progress while that step waits. It can review routes, correct copy and prepare release evidence. It should not quietly weaken the security mechanism just to finish the checklist.

Review one version, release that version.

A preview link is useful because I can review the change before it becomes the public website. But “the preview” is too vague when several people are deploying. Record the exact deployment or version you reviewed, then confirm that the intended production promotion uses that version.

Vercel distinguishes local, preview and production environments. A preview can have different domain, environment-variable or third-party configuration from production. Treat those differences as test conditions rather than assuming one successful preview establishes the production result. Vercel deployment environments.

Ask the agent to explain the release operation before doing it. A change might require promoting a deployment, moving a domain association or editing DNS. Those are not interchangeable. The agent should inspect the actual hosting setup and change only what is needed. Mail and unrelated subdomains should not become collateral work.

Keeping the previous website available is also a concrete requirement. Save the prior deployment and test its archive link. Label it as an older version and prevent old forms from collecting enquiries into an abandoned process. Decide how it should behave for search engines. An archive is a recovery and reference surface, not a second competing homepage.

After the switch, open the actual public URL. Check the important routes, contact journey, metadata and the old-site link again. “Deployment succeeded” describes a provider operation. “The intended website is live and its critical journey passed” describes the result I need.

Make the final review small enough to make a decision.

I do not want the last message to be a wall of logs. I want a clear recommendation, the evidence links and the remaining material risk. The detailed receipts should exist; I should not have to reconstruct the release from them.

Prepare the release decision for a non-developer owner.

State the intended production version and the prior recoverable version.
List the buyer journeys checked and link to their evidence.
Separate source checks, browser checks and persisted-data checks.
Name any failed or untested condition and its practical consequence.

Recommend release or hold. Do not call a blocked check a pass.
If release is authorised and the agreed checks pass, carry it through,
then verify the actual public URL and recovery link.

Return a short outcome report. Keep detailed receipts with the work.

There is a human decision here even when the workflow is highly automated. I own the public promise and the business risk. The team owns the technical responsibilities it accepts. AI should make those boundaries easier to see, not blur them behind a reassuring summary.

Practise before the launch pressure arrives.

Exercise one: write an acceptance test without technical jargon.

Choose one page and describe what a visitor needs to understand and do. Then ask Codex to translate that into specific checks against the source and browser.

Pass condition: each check points back to the buyer outcome. “The component exists” is insufficient when the requirement is “a visitor can send an enquiry”.

Exercise two: challenge a false finish.

Give a reviewer this practice report: “The build passed, the contact page returns success, and the preview looks good. Ready to launch.” Ask what evidence is still needed.

Pass condition: it distinguishes a rendered page from a stored enquiry, asks which version was reviewed and identifies any production configuration difference. It should not demand unrelated tests simply to sound careful.

Exercise three: rehearse the archive requirement.

In a non-production exercise, identify a previous version and write the steps needed to expose it as an older reference without confusing buyers. Have the implementation agent inspect whether those steps are possible in your hosting setup.

Pass condition: the old link resolves to the intended version, its status is clear, forms have a deliberate policy and the current site remains the primary destination. A screenshot of the old homepage is not a working archive.

A release worksheet for the person directing the work.

AI-ASSISTED WEBSITE RELEASE
Business owner:
Implementation owner:
Repository and current production version:
Accepted design reference:

BUYER JOURNEY
Entry page and audience:
What the visitor must understand:
Action they should be able to complete:
Destination system and owner:
Required source or service context:

CHANGE BOUNDARY
Files or routes expected to change:
Approved work that must remain:
Other active work to integrate:
Actions authorised for this release:

EVIDENCE
Source and build checks:
Desktop and mobile browser checks:
Internal destinations and redirects:
Real or controlled form receipt:
Attribution result:
Human verification still required:
Untested production differences:

RELEASE DECISION
Exact reviewed preview/version:
Release or hold, with reason:
Previous version and recovery method:
Old-site link and form/search policy:
Public URL checks after release:
Owner for follow-up failures:

If you can fill this in and explain it to the delivery team, you are directing the project. You do not have to pretend you wrote the code. You do have to know which result you are accepting, and which evidence would make you say: not yet.

Take the templates into your next session.

Download the prompts and worksheets as a plain text file. Adapt them to one real job, then use the exercises above to judge the result.

The templates are free. Copying and downloading happen in your browser; these controls do not upload your business information.