Stain the Page: How I Prototype with AI
AI is incredible for rapid idea and hypothesis testing by prototyping. Prototyping isn't about writing code. It’s about protecting your most valuable resource: cognitive energy.
This is how I approach it.
The Problem
As engineers, we often face the overwhelming task of determining the look, feel, and architecture of an idea through hundreds of tiny decisions.
When coding by hand from a blank slate, we are making low-level choices: What should I call this variable? What loop structure is best here? When should I split out this file? We bikeshed on whether a ternary operator is readable before we even figure out if the feature is worth building. By the time we get to the novel part of the problem we’re trying to solve, our brains are tired. We can burn out before we even truly begin.
To solve this, we can steal a trick from artists and writers.
Stain the Page
Artists often intentionally make something haphazard just to "stain" a blank page. A blank canvas is intimidating; an unrefined one is an invitation to edit. Once an artist stains a page, they are free to fix it.
Engineers still have to make creative decisions and explore architectural options, but instead of doing this manually and draining our cognitive load on boilerplate, we can use AI to stain the page for us. Doing this will let you:
Narrow your focus: You can concentrate on the decisions that matter.
Experiment: You can experiment without the pressure of a perfect production build.
Build AI skills: You’ll learn what to ask for, how to break up tasks, what refinement loop works for you, and more.
Build soft skills: You’ll work on how to write, how to explain, how to focus, and how to decide.
Give your AI tool of choice your idea and tell it you want a proof of concept. Set the bar incredibly low. Let the AI handle the exhausting micro-decisions — the variable names, the basic CSS, the generic component structure — so you can save your mental energy for the high-level architecture and the user experience. Don't worry about the final picture. Just get something on the screen and stain your page.
Avoid the Void
Because staining the page with AI is now so fast, it changes what we can prototype. In the past, fleeting ideas went straight into the void because the energy required to build them was too high. Now, you can save those sparks.
When you have a spark, jot it down, and immediately feed it to an AI. Tell it your goal, your open questions, and how you think you might solve it.
For example, when I was prototyping an AI Visibility scanner, I initially knew very little about how bots scraped sites. So, I dumped a raw stream of consciousness into a prompt: "I want to see what bots are scraping my site. Give me a dashboard that visualizes user agents and robot.txt hits. Use mock data." The AI generated a messy, half-working UI. It wasn't production code, but interacting with it instantly gave me a mental model of how the pieces fit together. I built my understanding of the domain alongside the tool by telling it, and myself, what my prototype should do.
You will not get the final answer — let that go! You will get discussion and an artifact to return to, play with, build upon, and critique.
Refine, Refine, Refine
Once you have that messy first draft, the momentum changes. You’ve started, which means continuing is infinitely easier. Now, you can refine and rewrite. There are many ways to refine, but there are two techniques I rely on to turn "stains" into real visions.
“The best way to get the right answer on the internet is not to ask a question; it's to post the wrong answer."
This is Cunningham’s Law, and prototyping works the same way. Once you can see what your idea could look like, you realize what you don’t like and can ask others to do the same. Knowing what feels wrong is often a faster path to the right answer than starting from scratch.
Next, and just as effective, tell the AI to poke holes in your idea. Ask for different perspectives. If an API structure using a string feels weird to your engineering instincts, ask it why. "How would a sales team interpret these features?" Let it challenge your assumptions. If you want to go an extra mile, ask another AI to do the same exercise, or critique the other’s output. Then, compare and contrast the results.
Case Study: The AI Visibility Scanner
To see how this works in practice, consider a recent flow I wanted to build. I was researching AI visibility and wanted to weave three ideas together:
Review AI Conversations: Allow users to review how and if they show up in AI conversations relevant to their business.
Determine Prompts: Use AI or user input to determine the relevant prompts to track.
Recurrence: Allow users to repeat and update this loop.
Merging these meant a million tiny decisions. How should the UI for reviewing prompts look? Do we need guidance for using AI to generate relevant prompts? What’s the loading state for the review loop and how often should it run?
I didn’t need to solve those yet. What I really needed to know was: Would this even work? Is it worth building? What does it feel like?
Instead of writing a spec, I opened my AI tool and wrote a prompt that looked a little bit like this:
"Build a single-file React prototype. I want to be able to input my business info. Then, I want to generate prompts that a real customer might use to find me using an AI chat tool. I want those prompts to be fully editable. Then, I want to pass those prompts into a conversational API call and return the results in a formatted way. I then want a UI that displays the results and shows me whether my business appeared."
I had a working prototype in under 30 minutes.
Having something tangible on the screen immediately gave me answers I couldn't have visualized otherwise:
Layout: I saw that showing more than a few prompts was too busy.
Flow: I realized we needed to research the best input fields as well as how to use them to generate prompts.
Ordering: The sequence of the pre-made prompts drastically changed the user experience.
Because I had a stained page to share, I could immediately take it to other engineers and designers to explore further. We skipped the exhausting "Is this possible?" phase and jumped straight to "How do we make this great?"
That shift matters. At Squarespace, AI prototyping is not just helping individual engineers move faster, it is actually changing how product development works. Designers can react to a real prototype instead of an abstract idea, which helps us find the right UXR path earlier. PMs can help engineering iterate and refine ideas into something customers will actually use. On some teams, this flips the traditional rhythm. Now, engineering can explore faster than the larger process can react, so we have to be more deliberate about staying coordinated and unblocked. That changes the shape of product development in a good way. It can make us faster, but more importantly, it really makes us more collaborative.
For me, that difference has changed how I build features. I share my ideas earlier. I prototype earlier. I can use these rough drafts to work with my team to find where technical knowledge, design taste, or product judgment matter the most. More and more, the bottleneck is not writing code. It is deciding what is actually worth building.
I know that the prototype is not the product. It is the stained page, and the best way I know to turn an idea into something tangible to build upon. So, rewrite away. Refine the prototype with your own thoughts and opinions until your best ideas are on the screen.
And then, once your vision is clear, take what you’ve learned and move on to the next clean page.
