One Landing Page, Four AIs: Who Writes the Code, Who Makes the Hero, and Who Checks the Copy

Every generic "build a website with AI" post has the same quiet assumption baked into it: one tool, one prompt, one output. Type "make me a landing page" into the box, get a website out the other side, done. It's the AI equivalent of a microwave meal ad.

You already know that's not how it goes. You've sat in front of a model that writes beautiful, responsive HTML and asked it for a hero image, and gotten back either an apology, a stretched SVG blob, or an <img> tag pointing at a URL that doesn't exist. You've pasted your finished copy into the same model that wrote it and gotten back a glowing review and a suggestion to make the headline "more dynamic." Neither of those is a model failure. Both are you handing a task to the wrong worker.

The fix isn't a better prompt. It's a division of labor. Here's the map: who codes, who paints, who proofreads, and what an afternoon looks like when you get it wrong.

The core split: three jobs, three different kinds of machine

A landing page build decomposes into roughly four kinds of work:

1. Structure and code — the HTML, the CSS, the responsive behavior, the form logic, the semantic markup.
2. Visual assets — the hero image, background textures, illustration, iconography, the OG social card.
3. Copy — headline, subhead, body, CTA, the words on the page.
4. Review — someone adversarial checking all of the above before it ships.

One model can technically do all four. Two of them badly. The reason is that these jobs reward opposite failure modes, and models are tuned for specific ones.

Claude writes the code, the structure, and the wiring

This is the job the code models are built for, and the one where delegating elsewhere costs you the most. Claude will take a brief and produce a complete, working page — semantic HTML, media queries, a form that actually posts somewhere. This ground is well covered on this blog, including the pre-build step of turning a campaign brief into a wireframe before any code exists, which I walked through in Before Claude Writes a Line of Code: Wireframing Your Landing Page With LLMs Using Only Your Campaign Brief.

What matters for the division of labor is what Claude should also own even when other AIs are in the loop:

• Integrating the assets everyone else made. Once your image model hands you a hero, Claude is the one that sizes it, sets alt text, writes the srcset for mobile, and handles lazy loading.
• The layout decisions that live in code — grid behavior, breakpoints, spacing systems. There's a fuller breakdown of which design calls belong to the model versus to you in AI Web Design Without the AI Look: Which Design Decisions to Hand Claude and Which to Keep, so I won't re-tread it here.
• Anything with logic. Form validation, mailto handlers, a tiny bit of JS for a sticky CTA. Image models can't do this at all, and general-purpose chat models tend to produce code that looks right and breaks on mobile.

Image models make the assets — and only the assets

Here's where the single-tool assumption falls apart hardest. Code models, by and large, cannot draw. Ask Claude for a hero image and you'll get an inline SVG that reads as "abstract tech blob number 4,000" — or a reference to an image file it invented. That's not a bug; image generation simply isn't what the model does.

So the job goes to an image generator. What the image model is actually good for on a landing page:

• The hero visual — especially abstract backgrounds, gradients with grain, 3D-ish scenes, product-in-context shots. Anything where "vibes" are the deliverable.
• Consistent illustration sets. Generate a style, then generate the icons or spot illustrations against that style, in one session if possible so they stay coherent.
• Social and OG cards. The 1200×630 image that shows up when your link gets shared is a pure image-model job — nobody should be hand-drawing that in Figma.

And what it's bad for, which is the part that burns afternoons:

• Text in images. Image models have historically mangled rendered text, and while some have gotten dramatically better at it, the reliable rule is still: don't put your headline inside the generated image. Render text as HTML on top of the image. If you need text baked into an asset (an OG card, a badge), pick a generator known for text handling and expect a few regenerations.
• Exact dimensions and exact colors. Image models approximate. You'll ask for 16:9 and get something adjacent; you'll ask for your brand hex and get a cousin of it. Budget for regenerating and plan to crop and color-correct, or sidestep it: ask for images with negative space where your HTML text will sit, so precision matters less.
• Anything that must match your real product. A generated image of "a dashboard" will not be your dashboard. If the page sells software, the screenshots should be real screenshots; the AI makes the frame around them, not the product itself.

The second LLM reads the copy like an enemy

This is the assignment almost nobody makes, and it's the cheapest quality win on the list.

The problem with asking the model that wrote your copy to review it is that LLMs are agreeable about their own work. You paste in a headline and get back "This is strong! Here are some minor polish suggestions…" from the same model that wrote it. Self-review collapses toward flattery.

The workaround is structural, not prompt-cleverness: review with a different model. Paste the finished copy into a second AI — a different family entirely, not just a fresh chat — and give it an adversarial brief:

You are a skeptical conversion copywriter reviewing a competitor's
landing page. Your job is to find what's wrong, not to be polite.

Page copy below. For each section, answer:
1. What is this section claiming, in plain words?
2. What claim is vague, unsupported, or hype?
3. What would a confused or skeptical visitor ask at this point
   that the page fails to answer?
4. Rewrite the weakest line on the page. Only one.

Do not compliment the copy. Do not summarize it back to me.

What this pass reliably catches that self-review doesn't:

• Claims that sound good and mean nothing. "Supercharge your workflow" survives a friendly review and dies an adversarial one.
• The unanswered objection. A second model reading cold will ask "okay, but what does this cost?" or "what happens after I click?" — the exact question your first visitor will have.
• CTA ambiguity. The reviewer will tell you whether "Get started" left them knowing what they were starting.

Note the boundary: the second model reviews copy, it doesn't rewrite the page. Dump an entire HTML file into a chat model and ask for "feedback on my site" and you'll get a mix of copy notes and half-understood code commentary. Keep its job narrow — words in, words out.

Where handing a task to the wrong AI actually burns the afternoon

Concrete failure modes, so you can recognize them mid-flight:

• Asking the code model for the hero image. You get an SVG or a broken file reference, spend twenty minutes trying to coax something attractive out of a drawing tool that isn't one, and end up with a flat-color <div> anyway. Total loss: about an hour, plus a hero that looks like everyone else's. (If your instinct at that point is "fine, just make the design decisions for me," that's how you end up with the generic gradient-hero look — the failure mode covered in AI Web Design Without the AI Look: Which Design Decisions to Hand Claude and Which to Keep.)
• Asking the image model for layout. Some image generators will happily render a "website mockup" for you, and it will look gorgeous and be completely unusable — a picture of a website, not a website. Fine as mood-board input for your wireframe; fatal if you mistake it for a starting point. The right way to get from idea to structure is the wireframing pass in Before Claude Writes a Line of Code: Wireframing Your Landing Page With LLMs Using Only Your Campaign Brief.
• Skipping the adversarial review because "the copy is fine." This one doesn't cost an afternoon; it costs conversions forever, invisibly. The page ships, reads smoothly to you because you wrote it, and leaks visitors at the headline. You never see the failure, which is exactly what the second model exists to catch.
• Letting two AIs design against each other. Generate a hero in one tool, then ask Claude to "make the page match the image," and you'll get a color palette that's 80% right and a type treatment that fights it. Cheaper path: give Claude the image's dominant hex codes yourself (most image tools show them, or a eyedropper gets them in ten seconds) and let it build around fixed values.

The run-sheet: one page, one evening

Putting it together, the actual sequence looks like this:

1. Brief and wireframe — Claude (or a chat session with Claude): turn the campaign brief into a wireframe and two or three headline directions. ~20 minutes.
2. Assets — image generator, running in parallel: hero background, OG card, any spot illustrations. Generate wide with negative space for your HTML text, expect to regenerate twice. ~15 minutes of attention, some waiting.
3. Code — Claude: build the page, hand it the chosen headline direction and the image files with instructions ("hero background, 2400px wide, dark bottom-left, text overlays top-right"). ~20 minutes.
4. Adversarial copy review — a different model with the skeptical-reviewer prompt above. Apply the one rewrite it flags and any objections worth answering on the page. ~10 minutes.
5. Final pass — back to Claude: hand it the reviewer's notes on anything structural (a missing FAQ line, a weak subhead), let it integrate, ship.

Three tools, four jobs, no task given to a machine that's wrong for it. The single-tool fantasy promises one prompt and a finished site; the reality is closer to running a tiny team where everyone's job description is two sentences long. The upside is that nobody on that team wastes an afternoon doing someone else's job — including you.