In Part IV of this AI-assisted Rapid Prototyping series, I’ll focus on the fourth step: Realize & Crystallize. As a reminder, my prototyping process has five stages, outlined below.
The Realize and Crystallize stages are inseparable; this is where you actually build & iterate on the prototype. Start by creating an initial prototype, a “stage zero” that’s functional and includes all the basic features you envisioned for your MVP. Then iterate by gathering user feedback, keeping what works and discarding what doesn’t. Once you’ve built out your MVP target, you’re ready to either deploy to production or hand over the prototype to the engineering team, depending on whether you’re prototyping or building the final product yourself.
Fire Your Engines!
In the previous articles, I showcased how I set up a.) an Initial Master Prompt (IMP), b.) a full project plan with product requirements, and c.) a memory management & snapshot strategy, to guard Claude Code and Gemini CLI from context rot and ensure that I could rollback to a working version in the event of a catastrophic failure.
With all the initial documentation files in place, I then created a new folder for my personal website project and added all the documents in there.
Next, I launched the WSL (Ubuntu) terminal in VSCode and fired up the CLI coding assistants. I initially started with Gemini CLI to build the project scaffolding. Project Scaffolding refers to the use of pre-built structures or templates to accelerate the initial setup and foundation of a new project, similar to how physical scaffolding supports construction workers.
I then copy pasted the initial master prompt into the console and hit enter. The documentation that I had set up already provided Gemini with the exact scaffolding to set up, which looked something like this:
Once the scaffolding was set up, I switched to Claude to get started with the application development.
After providing the initial master prompt to Claude, Claude asked me for confirmation to begin and once that was done, it generated hundreds of lines of codes within minutes, finally generating a landing page, with placeholder content which it hosted on a local development server for me to view.
This moment justified all the effort I put into the previous steps. Everything I did in the initial setup, Visualize, and Strategize phases paid off. The V1.0 of my prototype matched almost exactly how I envisioned the final product. This isn’t to say everything was perfect, but watching Claude spin up a functional website, complete with all pages and working navigation, from a single initial master prompt validated my decision to create thorough documentation and set up the necessary controls before having the model write a single line of code.
Iterate & Polish
At this stage, my rapid prototyping process was technically complete. I had a responsive, clickable, functional prototype with placeholder content that worked on both web and mobile. For a commercial or enterprise app prototype, this is where I’d solicit user feedback and run user acceptance testing to identify issues with user flows and feature requests. But since this was my personal website, my user base consisted of my wife and me with the grudging, approving nods from my cats serving as senior stakeholder sign-off. Through several rounds of testing, I fixed several issues and implemented a couple of entirely new features. With each session, my prototype became more polished and started resembling a high-fidelity prototype.
The iteration and polish stages weren’t without issues. I went through 19 sessions, each lasting a few hours, before I had a website ready for primetime. My documentation also tracked the hours spent on iteration.
Session Management
As you can see in the image above, the prototyping effort spanned multiple sessions. Let’s first understand what a session means and why it matters. Every time you type “claude” or “gemini” into your terminal, you start a new session. Unlike the popular mobile apps for ChatGPT, Claude, or Gemini, the command line coding agent starts with no memory at all. This means you must provide the initial master prompt every time, which directs the agent to review the instructions. In my case, the IMP directed the agent to review all project specs (long-term memory), the summary from the previous session detailing what was accomplished and next steps (short-term memory), and the specific visual changes made in the last session (episodic memory).
There are advanced memory management techniques that provide coding agents with memory retrieval tools; I’ll explore these in another series. But for building a personal website, I didn’t bother with all that. Instead, I relied on my documentation system to provide context at the start of each session. This was a double-edged sword. Right after the initial prompt, I loaded the agent’s contextual memory, which progressively reduced the remaining context available for new work before context rot set in. I tackled this by keeping each session small and focused on 4–5 immediate tasks. At the end of each session, I asked the agent to update all documentation, take a version snapshot (a backup of all code and resources), and document the immediate priority tasks for the next session.
This ensured that once I started a new session, the agent immediately knew what it had to achieve using the notes it had generated in the previous session.
Think about it like Leonard Shelby leaving himself elaborate notes, photographs and tattoos in Memento to account for his amnesia.
A Word of Caution
After the initial prototype was generated, I ran extensive testing and uncovered numerous functional and cosmetic defects. I had Claude fix issues related to alignment, color schemes, and text and image rendering. Some of the more serious functional issues I found and fixed were:
- Image galleries in published posts did not render
- Embedded content, especially PDFs or slide decks, did not render
- HTML characters were not being stripped or rendered correctly
- Featured images on posts were broken
- The search and filter functionalities on the Blog and Portfolio listing page were broken and did not render correctly
- The skills cloud sat at the bottom of the screen and looked terrible – I completely redid it as a rolling ticker running across the middle of the page
I’m pointing these out to make something very clear:
While coding agents do a good job of generating code, you are still in the driver’s seat. The depth of your validation ultimately determines the quality of the output. Like they say, “It’s not the car, it’s the driver.”
In one instance, Claude was about to make a change and I stopped it. I asked it to first analyze and confirm that the change wouldn’t impact the same feature on mobile. It did, and found that the change would’ve broken a perfectly working mobile feature. It then set up a separate configuration so that changes to one didn’t impact the other.
💡Pro Tip: While using command line coding agents, you’ll be asked to confirm if you want the agent to update code files. One of the options is to always allow the change next time. DO NOT select this option. You may not understand the code, but while the agent is making changes, you can logically infer what is being changed. In many cases, you can stop the agent from making the change and ask it to analyze something more holistically first. I’ve found this to be a very effective method for reducing regressions due to changes.
Unexpected Issues
Like any work project, you’ll encounter unexpected issues no matter how well you plan. Be ready to pivot when they arise.
Once my prototype was ready, I decided to populate it with real content. During the planning phase I had worked out with Claude that I’d be using WordPress as a headless CMS to publish content which would then come up on my website. But when the time came to integrate, I found that Claude had assumed I was using wordpress.org and not a free plan on wordpress.com. These were two completely different things and the entire code base up until that point in time was built assuming that I’d be using wordpress.org. I then had to pivot, with Claude having to rewrite significant portions of the code, including setting up an API based connection and parser to pull content from wordpress.com and then display it on the site.
Learning & Discovery
Every project you undertake will reveal that each Realize & Crystallize phase offers an opportunity to learn something new.
Building a personal website may seem like one of the simplest initiatives you can take on. But while building this prototype, I learned how integrations with headless CMS work, how to set up a site for SEO optimization, and how to configure analytics. This is invaluable knowledge I’ll carry into my next project.
Deployment & Next Steps
Normally, once the prototype is complete, the next stage, i.e. Productionize, begins. This is where you hand over your functional prototype to the engineering team. You can also use the design to generate user stories in JIRA using MCP server-based integrations. I’ve already experimented with integrating Figma with JIRA to automate this process. Setting up a custom MCP shouldn’t be too difficult.
For my personal website, I decided to push the envelope and turn the prototype into a live site. I worked through the site once more from an end-user’s perspective, adding finishing touches and visual polish until I had a deployment-ready website.
Despite what you may read, I wouldn’t recommend relying solely on coding agents for enterprise projects or live sites with paying users. Coding agents excel at prototyping and building a basic codebase.
The end product of realizing the vision & crystallizing it is shown below. In the next and final part in this series, I’ll cover deployment, i.e. actually taking this prototype and turning it into a live site (again, not something I’d recommend for enterprise initiatives).
Hit the comments if you’d like to discuss more.
