Use Real Website Examples Inside Codex
Give Codex concrete website references to compare layouts, typography, colors, and components before it builds or revises your interface.
real website examples inside codex
Contents
- [Choose references for the job](#choose-references-for-the-job)
- [Use a two-pass Codex prompt](#use-a-two-pass-codex-prompt)
- [Review changes at real widths](#review-changes-at-real-widths)
- [Turn comparisons into decisions](#turn-comparisons-into-decisions)
- [Use this in your AI agent](#use-this-in-your-ai-agent)
You can use real website examples inside Codex by giving the coding agent concrete visual references and a comparison task before asking it to edit your interface. The practical method is to collect a small reference set, extract useful design decisions, and turn those decisions into an implementation checklist for the repository.
Choose references for the job
Select pages according to the interface you need to build, not simply according to popularity. The examples below include Notion Developer Platform, Claude Code, and Exa MCP Server. Compare their visible choices, but do not assume that any one of them is the correct template for your product.
Ask Codex to look at five areas:
- Structure: which sections appear, and in what order?
- Hierarchy: how quickly do the heading, explanation, proof, and action become clear?
- Layout: how wide is the content, how are columns balanced, and how do cards stack?
- Visual system: which fonts, sizes, weights, colors, borders, radii, and shadows repeat?
- Behavior: which menus, tabs, code examples, transitions, or changing states help the visitor move forward?
Record only details you can observe. Add recommendations in a separate section so Codex does not mistake an observation for a requirement.
Captured pages
Use a two-pass Codex prompt
The first pass should be analysis. Ask Codex to compare the references and relate them to your page goal:
> Review these saved website references for a developer-facing landing page. Compare section order, content width, typography hierarchy, color roles, button styles, card patterns, code examples, and responsive behavior. Separate observed details from recommendations. Choose the patterns that best fit my audience and explain the tradeoffs. Do not copy wording, branding, illustrations, or distinctive details.
After Codex returns the comparison, use a second prompt:
> Inspect the current project and map that recommendation to the existing components and styles. List the smallest set of files and states that need changes, then implement the coherent version. Preserve accessibility, responsive behavior, loading states, and existing interaction flows.
Separating these passes helps the agent explain what it is borrowing before it changes code.
Review changes at real widths
Before accepting the result, check the page at the widths your visitors use. Confirm that the hero explains the job, the primary action remains visible, and long headings do not break the layout. Check that buttons, cards, labels, and code examples use consistent spacing and states.
Compare the implementation with your reference notes. Did Codex use the intended density, type hierarchy, and component rhythm? If not, give it one focused correction at a time. “Make it better” is difficult to act on. “Reduce the hero copy to two readable lines, keep the action beside it on wide screens, and stack it below on narrow screens” is testable.
A captured page can show appearance and visible behavior, but it does not automatically grant access to the original team's internal design rules. Use observed details as implementation input while keeping your own design tokens, content, and component decisions authoritative.
Turn comparisons into decisions
When references suggest different solutions, rank them by:
- Visitor task: which choice makes the intended action clearer?
- Content needs: which layout gives your real copy enough room?
- Implementation fit: which pattern matches the existing code and avoids unnecessary exceptions?
- Responsive strength: which choice remains usable on small screens?
- Consistency: which option can repeat across the rest of the site?
This framework is more useful than choosing whichever screenshot looks most impressive. It gives Codex constraints it can check while it works.
Captured references can support comparisons of page structure, typography, colors, spacing, components, and visible states. They can also provide observed details for formats such as Tailwind v4, CSS, JSON, or DESIGN.md. Treat those outputs as a starting brief and keep final decisions in your project's own system.
Use this in your AI agent
> Compare the saved website references with my current interface before editing code. Identify observed patterns in structure, typography, colors, spacing, components, responsive behavior, and interactions. Recommend only patterns that fit my visitor's task and existing component system. Separate observations from recommendations, write a short acceptance checklist, then implement the smallest accessible and responsive change. Do not copy brand wording, logos, illustrations, or distinctive visual details.
What is the best Codex prompt for turning website references into code changes?
Use one prompt for design decisions and another for repository changes. Combining both can make the agent jump into code before it has explained what it is borrowing.
Start with:
> Compare these references for my page goal. Describe useful patterns in layout, hierarchy, typography, color, spacing, components, and responsive behavior. Separate visible observations from recommendations, choose one direction, and explain the tradeoffs.
Then use:
> Inspect the current project and map that direction to existing components. Identify the smallest set of files and states to change. Implement it without copying brand-specific content. Preserve keyboard access, readable contrast, responsive layouts, loading states, and existing conversion behavior. Afterward, summarize each change against the acceptance checklist.
The prompt works best when you include your real audience, primary action, preferred content length, and any components Codex must preserve.
How can I tell whether Codex used a reference well instead of copying it?
Check whether the result carries over useful decisions rather than surface decoration. A good use of a reference improves hierarchy, spacing, readability, responsive behavior, or interaction clarity while keeping your own copy, components, and brand choices.
Compare the implementation with your notes. Can you explain why the hero has its current structure? Do repeated cards share a clear rhythm? Does the type scale support the content? Does the primary action stand out for a reason? Do narrow layouts remain usable? If the only visible change is a copied gradient, radius, or illustration style, the reference was probably not used thoughtfully.
Ask Codex to list which choices came from observed references, which came from your existing system, and which it introduced as recommendations. Keep choices that serve the visitor's task and remove details that exist only because they appeared in a screenshot.