AI-Driven GTM Imagery: Part 6, The Code-to-Design-to-Deploy Loop

Here’s something most marketers have never had to think about: the landing page you’re looking at right now was built in a terminal. Not in a drag-and-drop builder. Not in Figma. In a command line, with text commands, referencing folders full of strategic context that told the system exactly what colors, fonts, textures, components, and messages to use.

That probably sounds either exciting or insane, depending on where you sit. One year ago, I would have said insane. But after building landing pages, full websites, and functional apps this way, I can tell you that the code-first workflow isn’t just viable for marketers who aren’t engineers— it’s faster and more precise than anything I’ve used before. And the reason comes down to something most people haven’t considered: the tools that work best for AI-assisted design are not the tools you’ve been using for human-driven design.

In the pillar article for this series, I wrote about the Turkey Dinner Problem. You can’t ask an LLM to make you a four-course dinner if all it has in the kitchen is potatoes. The five-stage process I described (strategic foundations, visual brand guidelines, copy bank, component gathering, assembly) is how you stock the kitchen. This piece is about what happens after the kitchen is stocked. How you actually cook. Specifically: how the code-to-design-to-deploy loop works for landing pages, websites, and apps, and why the workflow looks nothing like what most people expect.

Why Code-First Makes Sense (Even If You’re Not an Engineer)

When I say I write the code in Claude Code, people assume I’m writing code the way a developer does. I’m not. What I’m doing is having a conversation with an LLM that understands my entire brand system because I’ve given it every strategic file I have. Positioning documents. ICP profiles. Design tokens in JSON format with hex codes, typeface names, spacing values, and texture rules. Voice exemplars. Component libraries. All of it sitting in folders that the model can reference directly.

So when I say “build me a landing page for this campaign,” the system isn’t guessing. It knows the color palette. It knows the typography hierarchy. It knows the messaging wedges I’ve already validated. It knows which proof points to pull. The output isn’t a blank canvas that needs to be designed from scratch. It’s a first draft that’s already 70-80% on brand because the strategic underpinnings were in place before I asked for anything.

This is the part that most content about AI design tools gets wrong. They show you how to prompt a tool. They skip the days (pre-AI, quarters) of documentation work that makes the prompt output actually usable.

The Landing Page Loop

For landing pages, the workflow is surprisingly straightforward once you’ve done the prep work. I write the code in Claude Code, referencing all the folders with strategic context. Then I review that code with Codex, merging the best of both models to make sure the output is structurally sound and high quality. Two models catch more problems than one, the same way two editors catch more typos than one.

From there, I push the design into Paper. Paper is an emerging design tool that’s becoming increasingly popular with enterprise AI-centric design teams, and the reason I use it over Figma for this workflow is simple: Paper does better with code-based design than Figma. When you’re working on this type of thing in your IDE or in the CLI, all the design elements are in code format. Your hex codes, your typeface names, your spacing values, your component definitions. They’re all referenced in code. Paper takes those coded elements and displays them visually, similar to how you’d see them in Figma, but without the painful export-import cycle that breaks everything.

This is where I do the visual refinement. Padding adjustments. Corner radius tweaks. Typography sizing. Verbiage changes that only become obvious when you see the layout at full scale. Paper has exceptional MCP functionality with Claude (especially compared to Figma), which means pushing and pulling code between Paper and my CLI is seamless. I tweak something visually, push the updated code back into Claude, and the changes are reflected immediately.

Once the page looks right from both a structural perspective (code review) and a visual perspective (Paper review), I ship it. Typically through Vercel. The whole loop, from first prompt to deployed page, can happen in a single sitting (~30 minutes) if the strategic foundations are solid and I’m editing/adding to an existing site or app. A net-new build takes a bit more time, ~1 hour unless it has complex user login requirements or needs extensive integration set-up (Google Tag Manager, CRM forms, phone or chat agents, etc.).

Websites and Apps: Same Principles, Different Tools

The loop for websites follows the same logic but I reach for different tools depending on the complexity. For websites, I prefer working in a tool like Antigravity. Antigravity handles user interface design and front-end code well, and what I’ve found is that it has more of a multi-agent task management workflow for building websites than something like Cursor or native Claude. That difference matters. It produces more unique, differentiated, functioning websites because the multi-agent approach means different parts of the system are handling different concerns simultaneously rather than one model trying to do everything sequentially.

For apps, I work in Cursor for the core code, do code reviews with Claude Codex (and sometimes Composer depending on the complexity), check the user interface design in Paper, make tweaks there, push the code back out of Paper into my CLI, and deploy through Vercel. The pattern is the same: build in code, review in a visual environment, refine, push back to code, deploy. The tools change based on the job. The loop doesn’t.

Phillip Maggs, Director of AI Excellence at Superside, captured why this matters: “You just have to be very comfortable with switching a lot to be able to maintain quality.” He’s right. The AI design landscape changes weekly. The skill isn’t mastering one tool. It’s understanding the loop well enough that you can swap tools in and out as better options emerge without losing your workflow.

Why Paper Changes the Equation

I want to spend a moment on why Paper specifically matters for this workflow, because it solves a problem that most marketers building with AI have felt but can’t articulate.

When you have a design in code that you like, getting it into a visual environment so that you can tweak it is genuinely painful using traditional tools. You have to save elements down into vector graphic format with all these different layers, which burns through tokens. Then you manually import them into Figma. Then you try to figure out how to get them back out of Figma and into the coding tool again. Every handoff introduces friction, breaks things, and eats time.

Paper eliminates that friction because it was built for this exact use case. Its positioning says it all: “the connected canvas for teams shipping with agents.” The canvas is built on HTML and CSS foundations, so agents can read and write designs as code. Design tokens, styles, and components sync between codebase and canvas. One source of truth. No export-import gymnastics.

This points to a broader shift in the SaaS landscape that I think is underappreciated. The market is separating into two categories: tools built for human-only workflows that are bolting on AI features, and tools built from the ground up for agent-native workflows. Take Metricool versus Sprout Social. Metricool doesn’t have as extensive functionality as Sprout Social. But because it works so seamlessly with AI tools, it’s better for my workflow than most others. I don’t need a hundred features in a graphical user interface. I need the tool to be easy for me to push and pull information from with my AI agents. Publer is similar— they presently have much better API and MCP functionality than most. It works best with my agents.

The same dynamic applies to design. Figma has enormous revenue at stake and their AI integrations remain incremental. The infrastructure wasn’t built for the way AI-assisted design production needs to work. Newer tools like Paper, built around code-native design where you can push elements between a visual canvas and a coding environment, are proving far more useful for production.

One more thing worth mentioning on the tool front. For certain types of campaigns, specialized tools outperform the general-purpose loop entirely. Not every asset needs to go through the full code-to-design-to-deploy loop. Sometimes the best workflow is recognizing which tool was purpose-built for the job you’re doing. For example, Mutiny is the best B2B ABM-specific graphic design tool I’ve found so far. If you’re running account-based campaigns and need creative assets that feel tailored to specific target accounts, Mutiny produces really clean campaign creatives quickly, easily, and at a good cost.

What to Do?

If you’re building landing pages, websites, or apps and want to try the code-first approach, here’s how I’d sequence it.

1. Get your strategic files in order. If you followed the earlier pieces in this series, you already have positioning, brand guidelines, and design tokens in formats an LLM can reference. If you don’t, go back to the pillar article and start there. The loop doesn’t work without the kitchen being stocked.
2. Try the simplest version of the loop on something low-stakes. Build a landing page in Claude Code (or Cursor, or whatever coding environment you prefer) with your brand context loaded. Don’t try to make it perfect. Just see what comes out when the model has real strategic context to work with. You’ll be surprised how close the first draft gets.
3. Get into Paper. The ability to push and pull code between a visual canvas and your coding environment is what makes this workflow practical for non-engineers. Without that bridge, you’re stuck either working blind in code or doing painful manual exports into traditional design tools. Paper is free on macOS and Windows. I’m telling you— the first time you code something in Codex or Claude Code and you send the code to Paper for design and watch it build the whole page while you just sit there watching… it’s one of those “a-hah” moments with AI that you won’t forget. Try it.
4. Deploy something. Vercel makes it straightforward to go from code to live URL. The psychological shift from “I made a mockup” to “I shipped a page” is significant. It changes how you think about what’s possible.

The code-to-design-to-deploy loop should give you a faster way to exercise good judgement in creative execution. Build, look, refine, ship. Repeat until the work is good. The loop just makes each repetition take minutes instead of days.

If you use this or any other piece of our six-part “AI-Driven GTM Asset Generation” series, share it with us here (via email) or on LinkedIn! We’d love to see what you’re making. And if you made it all the way to the end of this series, congratulations— you’re already leagues ahead of the 99% of people who have no idea how to do any of this yet.