What started as a hobby project—a place to document my journey through Prompt Engineering and Generative AI—recently exploded. Suddenly, I wasn't just a dev playing with APIs; I was running a high-traffic learning platform.

But growth brings a specific kind of technical debt. I hit a wall that every modern developer eventually faces: The Maintenance Trap.

In addition to tackling this, I also use the platform as a hub for research. One area seeing massive investment as we move through 2026 is Hyper-Personalization, which brings its own set of hurdles. While some marketing teams are still playing around with CustomGPTs and basic "Vibe Coding," the early adopters are already looking into true Hyper-Personalization.

While researching, I managed to solve a major maintenance issue while simultaneously clearing a path toward hyper personalization—killing two birds with one stone. The architecture in this article might not be new, but the way of working definitely is. In this article, I’ll share all the learnings and insights from that process.

The Problem: Expert Code vs. Fast Content

To be clear: I didn’t "vibe code" this site (building by feel without understanding the logic). I Amp Coded it. I remained the expert in the lead, architecting every line and database schema with precision.

However, even with expert-led AI assistance, the site was 100% hard-coded for the documentation pages. There -was- no CMS in the background for the content. While Vibe Coders (those using natural language to build apps without knowing the "how") often hit a wall because they lose track of their spaghetti code, I hit a wall because my architecture was too rigid for the speed of content. Every typo or documentation page update required a manual code edit, a build, and a deployment. Not really maintainable and sustainable. Of course I know about Content Management Systems. I just didn't invest in it yet.

While this is something people Amp Coding quickly might face (why would you need a CMS, if you can just prompt an agent to update it? And why would you sacrifice all options you've while coding to a limited CMS?), Vibe Coders (definitely when using tools such as Lovable, Replit, Bolt etc.) will surely face overtime. Every time they want to do an update (even just simple textual updates) on their generated websites, they need to edit this via an assistent (they have no clue how to do this within the code mostly, or don't even have this option). And this will bring a new challenge: tokens and credits! For simple changes like this, this group of people have to pay for tokens to update their websites. This is bad for maintenance, but also sustainability. Every time a small change has to be done, a LOT of energy is wasted, while this could be done way easier. Finally, do one simple Reddit search, and you'll face many posts from people sharing their experience of high expenses using this method.

Why Markdown and WordPress Weren't the Answer

Many developers reach for .md or .mdx files to solve this. But for a data-heavy site, Markdown has major flaws:

• No Structure: My pages feature dynamic user ratings and model comparisons. Forcing that into Markdown is messy.
• LLM Friction: While LLMs love prose, they struggle to maintain complex UI component layouts within Markdown over the long term.
• The WordPress Bloat: I didn't want to sacrifice my custom code for a heavy, plugin-dependent CMS.

The Breakthrough: JSON Configurations

The solution? A JSON-driven component layer.

Instead of hard-coding every page, I built a system where the "content" is a structured JSON schema. This schema tells my frontend: "Render the 'ModelSelector' component here with these specific data parameters."

This approach is a refined version of a pattern I have implemented at several previous companies, or which some CMS use by default; however, historically, it faced significant adoption hurdles. The primary challenge was that developers often found manually authoring and maintaining massive JSON schemas to be tedious and error-prone. As more components were added and documentation inevitably fell out of date, configuring the schema correctly became a bottleneck. And let's be honest? Find a developer having joy configuring JSON schemes...

What makes this iteration different—and far more effective—is the integration of Large Language Models (LLMs). While manual configuration used to be a point of friction, LLMs can now ingest your codebase, understand the component implementations, and automatically generate the necessary JSON structures. This eliminates the "configuration tax" and ensures that the schema remains perfectly synced with the code, transforming a historically difficult architecture into a highly efficient, automated workflow.

Furthermore, because this system is built on a structured schema, we can seamlessly map it to our own custom CMS. This bridges the gap between technical and non-technical teams: anyone can manage website content and reconfigure page layouts through a user-friendly interface without needing to understand the underlying code or JSON. It transforms a complex technical structure into a powerful, accessible tool for the entire organization.

Here’s why it’s a game-changer:

• AI-Native Management: LLMs speak JSON. I can "click" pages together by having the application manage the JSON layer via the CMS. Or generate pages using agents based on current schemas. It understands the schema perfectly every time.
• Developer Freedom: I keep my high-performance React/Next.js code. I’m not fighting a CMS; I’m just feeding my components structured data.
• Bye Low-Code / No-Code: You get the speed of no-code with the full flexibility of a custom stack. Everyone can manage the pages as long as you can type in Microsoft Word, but developer can still program new features and components the way they're used to.

Tip: Vercel built this already as a repo to start with. So you don't have to design it from scratch!

But isn't this just how a CMS works?

Partly, yes—but with a crucial distinction: independence. Traditional CMS platforms like WordPress tie your hands to their specific ecosystem (like PHP), forcing you to work within their technical constraints and legacy bloat.

By using an AI-managed JSON layer, you decouple the content from the engine. This shifts the power back to the creators and developers:

• Total Tech Sovereignty: Developers work in their preferred codebase and modern frameworks (like Next.js or Vue) without being forced into a specific language by the CMS.
• Intelligent Configuration Automation: Rather than forcing developers to manually author brittle JSON files, a Large Language Model acts as the bridge between your code and your configuration. By "reading" your component library, the LLM understands how to correctly structure the JSON layer to match your implementation, eliminating manual data entry and ensuring the schema never drifts from the actual codebase.
• Seamless Component Integration: Companies using structured Component Libraries (such as Storybook) can maintain strict brand consistency across all platforms. These components can be instantly added to any new application simply by importing them and registering them in the JSON layer, making them immediately available for use.
• Dynamic Interface Generation: For non-technical users, the LLM can actually generate a simplified CMS interface on the fly. This gives them the ease of a text editor while the underlying site remains a high-performance, custom-coded application.

The "Credit Trap": A Warning for Vibe Coders

This approach is particularly interesting for users of vibe coding tools like Lovable, Replit Agent, or Bolt (and not using Github or other version control systems, and updating their application within the vibe coding platforms).

If you build an entire app via vibe coding, you often become "locked in" to their ecosystem. Every time you want to change a simple text block or update a price, you have to prompt the agent again—consuming credits and tokens. By implementing a JSON layer as an Amp Coder, I've bypassed this:

• No More "Edit" Tokens: I don't need an expensive AI agent to "re-code" my page for a textual change or do it manual via the IDE. I just update the JSON in my backend via the UI I created on the background.
• Full Ownership: Many platforms want you to stay in their "vibe" so they can continue charging for usage. By moving the content to a JSON layer, you keep your app maintainable outside of their credit system.
• Decoupled Design & Consistency: Because the JSON only describes the what and not the how, I am no longer relying on hard-coded styling for every individual page. The layout and styling are rendered on the fly, ensuring a perfectly consistent UI across the entire platform. Change the component once, and every page in your JSON library updates instantly.
• Future-Proof Migrations: This is the ultimate "exit strategy." Since the data is entirely separated from the presentation, I am no longer locked into a specific tech stack. If I want to move from React to Vue, or Next.js to a completely new framework, I can simply ask an LLM to refactor the component library. The core of the website—the JSON layer—remains untouched and active. Migrating becomes a structural task rather than a "start from scratch" nightmare.

Under the Hood

So, how does this actually work? I built a dedicated rendering engine that bridges the database to the frontend.

It starts with the database, where content is stored not as a blob of HTML, but as a structured JSON object. Each page consists of an array of "sections". Every section has a defined type—like text, image, code_block, or even complex identifiers like model_ratings_quadrant.

On the frontend, our ContentSectionRenderer component acts as the traffic controller. It receives this JSON array and iterates through it. For each section, it checks the type and immediately invokes the corresponding React component, passing along any necessary data props (like image URLs, chart data, or text content).

This means when I want to add a complex chart, I don't write React code. I simply add a JSON object with "type": "model_ratings_quadrant" and the necessary data points. The engine handles the rest, ensuring that every page maintains the high-performance, pixel-perfect look of a custom-coded application, with the flexibility of a CMS.

The Agentic Connection: Mapping to the Future

This architecture does more than just simplify maintenance—it creates a perfect landing zone for Agentic Workflows. Recently, we've seen the release of tools like the GitHub Copilot SDK, which provides a programmable "agent runtime" that can plan, call tools, and edit files.

The JSON-driven system maps perfectly to this new paradigm. Because everything—from the text on the page to the complex quadrants and charts—is already stored as machine-readable data, your application is "Agent-Ready" by design.

Yes, an LLM Built This (And You Can Too)

Here is the best part: I didn't write the migration code manually. An LLM built this entire JSON infrastructure.

The process was incredibly straightforward and reproducible. I simply provided the LLM with my existing hard-coded files (like the PromptArchitecture.tsx page) containing all my custom coded components, and gave it a high-level architectural instruction to create a plan:

"Analyze these React components {added Context}. I want to move this content into a database. Design a JSON schema that can represent this exact structure, and write a React component that takes that JSON and renders these existing components dynamically. Write a plan in {fileName}, so I can review it before we start building."

The LLM did the rest. It created a plan for me to review, and then it designed the JSON structure you see above, wrote the backend to serve it, and created the frontend renderer to display it. As the Expert in the Lead, my job wasn't to write the boilerplate—it was to define the architecture and validate the strategy. The LLM handled the implementation, turning a complex refactor into a manageable task.

The best part? Now that the backend has a functional CMS, anyone who can use Microsoft Word can create new pages, add fresh content, or update existing pages. It’s no longer a coding task; it’s just a simple form with all the required elements to build the page. An example of the initial building blocks it created for the CMS I am using can be found in Figure 2.

And then I can simply add HTML content to create the page, or even just text and transform it to HTML. In Figure 3 you can see how it looks like when I add a HTML block.

This is just a starting point, but it gets the job done for me.

When dealing with less technical users, you might want to consider more tools within your custom generated CMS, that will help the user design the content and configure the components correctly in a way they're used to (for example Microsoft Word features for editing).

If you are working with "Vibe Coding" tools—or as the industry often calls them, "AI Engineering Tools"—you can simply ask the agent to implement this JSON-based architecture for you. By doing this early, you ensure you don't need manual code edits for every small change, effectively "insulating" yourself from high token costs later on.

But what if I want to add new components you might think? Well, that's kinda straight forward. You design the component, and once again, ask the agent to make it available in your CMS. This way you can simply select the newly created component within your CMS, configure it, and it will be available on the page.

JSON import and Version Control

Finally, since I want to use tools like Gemini, ChatGPT, or my own coding agent to build pages, I no longer want to manually click through a CMS. Because LLMs excel at JSON, I taught Gemini to generate pages using my specific JSON structure (incorporating all available components). Now, I can simply input standard text containing my requirements, have Gemini convert it to JSON, and upload it directly to the CMS.

To support this, I created a "JSON import" feature for each page. I can easily copy the JSON from Gemini, paste it into the modal, and save it; the system automatically generates all the necessary components in the CMS. While I can still make final edits if required, the foundation is laid instantly. This feature also allows me to add new JSON or completely overwrite content if I want to redo a page. Implementing this was as simple as asking my coding agent to add the option.

However, please be aware that when working this way, adding version control to your CMS is highly recommended. If you overwrite content or move too quickly (yes, it has happened to me) while updating a page via JSON, you risk losing data. By implementing simple version control—which you can also request from your coding agent—you can easily restore a previous version whenever necessary.

Which tool should you use?

One common question people ask me over and over again is, "Which tool should we use for this use case?" Especially when talking about Vibe/Amp Coding, there are different approaches to take, which also influence which tool you might want to use. Let me break it down for you.

Your Coding Experience

The first question you should ask yourself is how much coding experience you have. To effectively use a professional AI-enhanced setup, there are four pillars you absolutely must understand. If these terms feel like a different language to you, you are at high risk of breaking your project beyond repair.

• IDE (Integrated Development Environment): You need to be comfortable in a professional editor. If you’ve never seen a terminal or a file tree, the learning curve will stop you before you even start.
• Git & Version Control: This is your only safety net. If you don't know how to "commit" or "roll back," a single AI confabulation (hallucination) can overwrite your entire project with no way to recover your work.
• Environment Separation: You must know how to separate a Development database from a Production database. Some AI agents might run "reset" or "drop" commands to test a feature; if this happens on real data, you could lose your entire database in seconds.
• Extra (but important)*: Database Migrations: Understand how to manage schema changes. Without them, you cannot provide LLM agents with the precise context they need to interact with your data. In modern frameworks, migrations are stored as files in your repository, making it easy for agents to understand your database structure.

If you do not have experience with these three/four items, you should navigate to the Coding with AI - Code Assistant Landscape section on our website (see button below) and pick one of the "AI Engineering" tools (like Replit Agent, Lovable, or Bolt.new). They mostly all work with credits, so there is not much more to choose from in that perspective (I'll discuss that later).

Why pick from these tools? Because most of them contain guardrails, such as version control etc. If you're running into issues you can simply convert it back to a working previous version. This should be one of the key elements you're looking into when selecting a tool. When you're known with coding, you will start setting up your project in a version control system such as Git. This way, if something goes wrong, you can easily revert the changes back to a working version.

If you do have coding experience, you will want to pick one of the items in the "IDE Integration" section of the Code Assistant Landscape. Here, there are actually differences that might influence which tool to use, especially when you are not fixed to a specific toolset required by your organization.

Credits VS Rate Limits

Some tools, like Claude Code and AntiGravity, work based on "Rate Limits," while other tools, such as Windsurf, work via a credit system. The difference is simple: when a tool is based on credits (or requests), you'll receive a certain amount of credits/requests per month for you to use (mostly depending on the subscription you have). Every prompt you send to the tool (model/agent) will consume one or more credits/requests (mostly depending on which model/tool you're using). Most tools give a clear overview when selecting a model of how many credits you're consuming, as shown in Figure 5.

In the image above (Figure 5), you can see that when I took this screenshot in Windsurf, Claude Sonnet 4.5 consumes 2 credits per prompt*, GPT-5.2 Medium Reasoning consumes 2, but Claude Opus 4.5 consumes 4 credits per prompt*.

Rate limits, on the other hand, are less visible. Rate limits mean that a user can have a certain amount of traffic to the model before it is disabled for them. This means you have to wait a certain number of hours before you can continue using the model again like shown in Figure 6. In this example, I was blocked for 2 days due to the rate limits (screenshot was taken on January 14th, 11PM).

If you're a heavy user and know what you're doing (spending your credits wisely), credits are the way to go. If you're a less frequent user and it doesn't matter if you get blocked for a certain amount of time while coding (think about hobby projects, for example), rate limits are your best friend.

Agent Compute Units (ACU's)

Model selection

Consider the models that the tools support. For example, some tools support only a (very) limited number of models—such as Claude Code and Antigravity—or require BYOK (Bring Your Own Key) features, where you must connect models via your own API keys. Others, on the other hand, support most or all of the popular models available; examples of these tools include Windsurf and Cursor.

Redundancy and Reliability

Beyond compliance, maintaining access to multiple models is a critical business continuity strategy. Relying on a single provider creates a single point of failure; if that provider experiences an outage, your entire workflow grinds to a halt. A recent example occurred on January 14th, when a major downtime at Anthropic rendered all their models unavailable simultaneously. By ensuring your tools support a diverse range of models, you remain resilient against such service disruptions and can simply pivot to an alternative provider to keep working.

Standout Features

Once you've decided whether you need a tool based on credits or rate limits and if you decided on the amount of models available within the tool, the next step is to look at the features provided by default. Most tools offer standard capabilities like MCP integrations, version control, planning mode, workflows, and agent setups. However, some come with unique features that can fundamentally change how you code.

For example, "browser-use" is not available in all tools but can be incredibly powerful. This feature provides a built-in browser that the agent can operate in the background. It allows the agent to debug code, test your project, or even run through various use cases to ensure that new changes haven't negatively affected existing features. For projects running locally or for personal use, this might be less critical; however, when building for the web and serving real users, it is a massive time-saver.

Beyond the use cases mentioned above, it can also provide detailed reports on changes. While navigating through your application, the agent can take screenshots and log activity to report back to you. This allows you to simply validate the final output without having to manually click through every part of the site yourself.

The ability to add skills—to reduce token consumption for MCP servers or explore other use cases—and workflows (shortcuts to common tasks) can significantly enhance your coding experience.

The community surrounding these tools also plays a vital role. Anthropic, for instance, shares numerous resources that you can use directly within Claude Code or migrate to your preferred tool. A prime example is the Claude Plugins and Get Shit Done GitHub repository, among many others.

You may also want to consider whether you prefer a chat-based or terminal-based assistant. Personally, I favor chat-based tools (Windsurf, Antigravity, Cursor). Not only do they tend to provide clearer feedback, but they also offer superior interfaces for reviewing changes. These tools typically allow you to accept or reject edits at the line level, giving you much more granular control compared to tools that force you to accept all changes at once.

Still not sure? Head over to our Tools page to see the different options and read community feedback.

The Future: Hyper-Personalization at Scale

The next frontier in web design is moving away from the "one-size-fits-all" model. Modern companies are investing heavily in Personalized Websites—pages that automatically adapt their content, layout, and messaging based on specific user needs.

But what is Hyper-Personalization exactly? Unlike standard personalization, which might simply use a customer’s name or segment them by location, Hyper-Personalization leverages real-time data and AI to deliver unique experiences to every individual user. It’s the difference between a storefront that knows your city and a storefront that evolves its entire interface, product recommendations, and tone of voice based on your specific browsing behavior and intent in that exact moment.

However, this level of personalization introduces three major hurdles:

• Maintenance: How do you manage 100 different versions of one page?
• Testing: How do you verify that every variation looks good?
• Delivery: How do you ensure the right user gets the right content without lag?

Solving Personalization with the JSON Layer

By decoupling your components from your content, you can tackle these problems in two ways:

Key Benefits of "JSON Personalization"

• ~Zero-Risk Layouts: Since the AI is only touching the data (JSON) and not the logic (React/Next.js), it is impossible for the AI to "break" the complete site's functionality. Some pages - might - be affected, but not the complete website.
• Infinite Scalability: You can generate 1,000 unique landing pages for 1,000 different keywords or user personas without writing a single new line of CSS or HTML.
• Auditability: You can easily read and edit the JSON to ensure the AI-generated content is accurate before it goes live—something that is much harder to do when the content is buried inside complex code.
• From Word documents to JSON objects: The next step? In tools such as Claude Code, Windsurf, Cursor, and Antigravity, you can configure custom agents. By setting up an agent specifically designed to parse and convert documents into your JSON structure, you can automate the entire workflow. Simply run the agent to fetch documents from a specific folder or domain and transform them into the exact structure required for your website.

Ultimately, shifting the complexity of personalization from the code to the data layer transforms your website from a static document into a living, breathing interface. By using JSON as the bridge between your component library and generative AI, you move past the "Maintenance Trap" and into a space where your site can finally scale as fast as your ideas. You aren't just building a faster website; you're building an intelligent system that meets every visitor exactly where they are—without the overhead of a thousand manual updates.

In fact, this very page was configured and written entirely by a Large Language Model. After building the solution together, the GenAI agent analyzed our entire chat history and the logic we used to reach our goal. It synthesized those technical breakthroughs and my specific project priorities to generate a production-ready JSON file including the content that defines this entire layout. As I have a local copy of the production content, it even selected the right tools showcased on this page, and added the screenshots I added in a folder (with data tags). By simply uploading that file to my CMS, I moved from a brainstorming session to a live deployment without writing a single line of layout code or the content. While I stepped in at the end to review and refine the content in production, the structure was born entirely from that collaborative analysis—proving just how fluid the transition from development to documentation can be.

This documentation page was released on January 13th, 2026.