It started with a single prompt I typed into Gemini. I was frustrated, spiraling a bit about the state of the world, so I just dumped this into the chat window:

“Okay, so I am facing a dilemma, I am starting to lose empathy on humans as a race. Especially from a perspective that most of us are not intelligent enough or performant enough compared to AI. And if so then what’s the point of the huge population and how the economy is structured?”

Typing that out felt cold. But the hour-long conversation that followed—with an entity that is technically smarter than I am—pushed me into this weird crisis of relevance.

I look at humans now—our whole species—and the primary word that comes to mind is... inefficiency. I look at how slow we are. How much we doubt ourselves. How we take days to process data that the AI I was just talking to can synthesize in four seconds. I catch myself getting impatient with the fundamental slowness of the human mind.

We’ve spent the last 200 years, basically since the Industrial Revolution, telling each other that our worth is tied to our output. “How fast can you work?” “How smart are you?” “What value do you bring to the market?”

And now we’ve built a machine that is infinitely smarter and infinitely faster. So, by our own definitions... we are obsolete.

And if we’re obsolete, the whole economic structure collapses. The jobs, the wages, the middle class. It’s what economists call “Engels’ Pause”—that period in history where the machines get better, the rich get richer, and the workers just suffer.

If this AI revolution is moving at ten times the speed of the industrial one, what happens to the masses? The doers? It feels like we are walking into a dystopia where humans are just pets to super-intelligent systems. Fed. Entertained. But totally stripped of agency.

Sigh.

But wait. No. As the AI and I kept going back and forth, a realization hit me.

I’m looking at this the wrong way. I’m judging a cheetah by its ability to fly. I’m judging humans by machine metrics.

If AI is the engine... it has no ambition. It doesn’t get bored. It doesn’t want anything. It doesn’t feel the rain outside my window right now.

That’s it. That’s the monopoly we still hold. We have the monopoly on desire. The point of humans isn’t to be the CPU of the planet. We aren’t the processors anymore. We are the steering wheel. AI has all the answers, sure, but who is asking the questions? The inefficiency I’m so annoyed by—the wandering, the mistakes, the irrationality—that is the biological noise required for creativity.

There’s this concept in philosophy: The Observer Effect. Value requires an observer.

An AI can write a perfect symphony in two seconds. It can generate a masterpiece. But if no human is there to hear it? If no one gets goosebumps, if no one cries over the melody... does that symphony actually matter?

No. It’s just math on a server.

Without us—without the massive, inefficient, emotional human population to consume it—the “performant” AI has absolutely zero purpose.

We aren’t the factory workers anymore. We are the users of the universe.

Okay. I feel a bit better. The anxiety is still there, but the frame is different. We just need to stop trying to out-calculate the machine, and start figuring out what we actually want it to build for us.

Time to get some sleep.

View my Blog

When I started this journey to revive my dormant travel blog, WanderingBong, I thought I was just upgrading a tech stack. I thought I was swapping Strapi for a custom Node.js backend and playing with some new APIs.

I was wrong. I wasn’t just upgrading my code; I was upgrading my job description.

Over the last few weeks, I’ve built a custom Model Context Protocol (MCP) server, deployed autonomous agents to my EC2 instance, and integrated AI deeply into my workflow.

But the biggest takeaway isn’t technical. It’s the realization that I am no longer a “Coder.” I am a “Manager.”

Here is what I learned about building software in the Age of Agents.

1. Context Engineering > Prompt Engineering

Everyone talks about “Prompt Engineering” — the art of asking the AI the right question. After building this system, I think that’s a distraction. The real skill is Context Engineering.

An AI is only as smart as the information you give it.

• If I ask an agent to “Write a blog post,” it writes generic fluff.

• If I give it my database schema, my project history, and my raw notes, it writes a strategy.

The “Meta” Moment: To prove this, look at this very article series. The structure, the themes, and the roadmap you’ve been reading weren’t painstakingly outlined by me in a Google Doc.

I simply opened a chat with Anti Gravity and dropped in two things:

1. Generate the Context.md file based on the latest state of the codebase and a high-level review of the git commit history.

2. A stream-of-consciousness paragraph: “I want to document reviving my blog. I started on WordPress, moved to Strapi/Next.js during COVID to relax, and now I want to build anchor articles using AI agents and MCP.”.

That was it. The AI analyzed the technical context, understood the emotional arc (the “COVID relaxation” project), and generated the 4-part outline for this series.

I didn’t engineer a perfect prompt. I engineered the context.

2. The Power of Parallelism (Coding at Scale)

As a solo developer, my workflow used to be linear and painful. If I wanted to build a feature, I had to write the backend API, then switch context to the frontend, then style it, then debug the upload logic. It was sequential.

But with coding agents, I started working in parallel.

During the build phase, I found myself spawning multiple instances of my AI tools to tackle different layers of the stack simultaneously:

• Instance 1: “Refactor the Media Library to support drag-and-drop.”

• Instance 2: “Fix the CSS grid layout on the public Blog View.”

• Instance 3: “Update the CMS UI forms to handle the new ‘Journal’ entity.”

I wasn’t context-switching between these tasks; I was merging them.

I became the Engineering Lead reviewing three open Pull Requests from my “team,” rather than the tired developer writing every line. The “cost of iteration” dropped to near zero because I could run multiple development tracks at once.

3. The Content Vision: Anchor Articles & Curated Memories

So, what am I actually building with this team? The goal was never just to have a “tech demo.” It was to build a better home for my memories.

The old blog was a chronological feed of fragmented posts. The new vision, powered by AI, is about Anchor Articles.

• The Concept: Instead of 10 tiny posts, I want definitive guides (e.g., “The Complete Guide to Patagonia”).

• The AI Role: The Agent scans my thousands of photos and scattered “Journal” notes. It identifies clusters — “Hey, you have 50 photos and 3 notes from Ladakh” — and suggests merging them into a single visual story.

It helps me weave scattered data points into a cohesive narrative, something I never had the patience to do manually.

Conclusion: The Joy of Building Returns

For a long time, my side projects died because the friction was too high. The gap between “Idea” and “Execution” was filled with hours of boring configuration and boilerplate code.

Agents have removed that friction.

• Cursor handles the syntax.

• MCP handles the data connection.

• I handle the vision.

I’m finally tinkering again. And for a Product Manager who loves to build, there is no better feeling.

Thank you for following the journey. The code is deployed, the agents are running, and Wandering Bong is finally alive again.

Check out my blog here - https://wanderingbong.com/

In the last post, I explained why I stuck to a “boring” architecture (Node.js, PostgreSQL, EC2) for my blog revival. I did it to create a stable environment for my new “AI Engineering Team.”

But there is a missing link.

I have Cursor and Anti-gravity (my Junior Devs) helping me write code. And I have the LLMs (Claude/Gemini) ready to manage my content. But the LLMs are usually trapped in a chat window.

They are smart, but they are blind. They can’t see my database. They can’t check my previous posts. They can’t do anything unless I copy-paste data to them.

To fix this, I needed to give them hands. I needed to bridge the gap between the “Brain” (the AI) and the “Memory” (my Database).

That bridge is the Model Context Protocol (MCP).

Subscribe now

The Problem: The Copy-Paste Bottleneck

Writing the code was one thing, but the bigger problem was ongoing blog management. I was drowning in tasks like SEO management, linking related content, and trying to turn scattered notes into stories.

Before implementing MCP, my workflow was painful:

I ask ChatGPT: “Draft a post about Japan.”

1. It writes a generic travel guide (“Visit the Golden Pavilion!”) because it doesn’t know what I actually did.

2. I have to dig through my phone notes, find the specific restaurant name, and copy-paste it into the chat to give it context.

3. It writes a draft.

4. I manually copy that text, log into my CMS, paste it into the editor, and then manually configure the SEO tags.

5. I copy-paste 10 rows from my PostgreSQL database to show what I actually wrote in 2019 so it can link to them.

6. It writes a draft.

7. I manually copy that text, log into my CMS, paste it into the editor, and then manually configure the SEO tags.

I wasn’t an “Architect”; I was a glorified clipboard manager.

The Solution: cms-mcp (The Backend Specialist)

I realized I needed to treat my AI agent or even ChatGPT not as a “super-user,” but as a standard client — just like my frontend UI.

I used the Model Context Protocol (MCP) to build a bridge. My custom tool effectively acts as a “headless browser.” It talks to my backend (cms-be) using the exact same API endpoints that my Admin Dashboard (cms-ui) uses. Think of an MCP Server as an API specifically designed for AI agents. It tells the LLM: “Here are the tools you are allowed to use, and here is how you use them.”

But to solve the “Generic Content” problem, I introduced a new concept to the API: Journals.

The Secret Weapon: The “Journals”

I added a Journal entity to my CMS. These are small, raw memoirs—quick notes, a location, maybe a photo—that I jot down while traveling. They aren’t blog posts; they are just data points of memory.

By exposing these via the API to the Agents, I gave the AI a memory bank.

Now, back to the MCP Server

Initially, I thought about giving my AI agent direct access to my PostgreSQL database. It seemed fast. It seemed easy.

But as a Product Manager, I know that “fast and easy” usually leads to “broken and messy.” Giving an LLM direct database access bypasses all the business logic, validation, and safety checks I built into my backend.

So, I pivoted. I decided to treat my AI agent not as a “super-user” with root access, but as a standard client — just like my frontend UI. My custom tool effectively acts as a “headless browser.” It talks to my backend (cms-be) exactly the way my Admin Dashboard (cms-ui) does.

1. It Mimics the Human (Me): When I write a post, I use the UI, which calls the API. The API handles the messy stuff — generating slugs, sanitizing HTML, and setting default timestamps. By forcing the Agent to use the API, it follows the exact same rules I do.

2. Scalability & Maintenance: If I change my database schema, I don’t have to rewrite the Agent. As long as the API contract stays the same, the Agent keeps working.

3. Security & Logic: My backend already knows how to validate a user. I don’t need to rebuild authentication logic inside the AI agent.

The “Job Description” (Tools I Built)

I didn’t give the AI root access (I’m a Product Manager, not a maniac). Through the MCP server, I exposed specific API endpoints as “Tools” for the AI:

search_journals (The Context Engine):

• Action: Calls GET /api/journals?location=...

• Use Case: “Find my raw notes from Tokyo so I can write a story that actually sounds like me.”

search_content:

• Action: Calls GET /api/posts?search=...

• Result: The backend runs the search logic and returns JSON. The AI reads this just like a frontend would to understand what I’ve written before.

create_draft:

• Action: Calls POST /api/posts with a JSON body.

• Result: The backend validates the title, creates the slug, checks for duplicates, and then saves to the DB. The AI doesn’t have to worry about SQL syntax.

audit_seo:

• Action: Calls GET /api/posts/:id/seo-check

• Capability: Connected to a Google Search Console MCP, it can analyze traffic and suggest title tweaks.

The Workflow: From Chat to Production

Here is what it looks like when I “collaborate” in ChatGPT or my custom agent now:

Me: “I want to write a new Anchor Article about ‘Hiking in the Himalayas’. Check if I have any existing notes on this, and draft an outline.”

The Agent (using cms-mcp):

1. Context Gathering (search_journals): It queries GET /api/journals?location=Kyoto. It finds: A raw note about a specific coffee shop, a photo I took of a shrine, and a note about the rain.

2. Calls db_search: Scans my database for tags like “Japan,” “Mt Fuji”.

3. Returns Context: “You have 3 existing short posts from 2022 and 5 journal entries.”

4. Synthesizes: Creates an outline that references those specific memories.

Me: “Looks good. Create the draft.”

The Agent:

1. Calls create_draft: It hits my database and creates the actual record.

2. Result: I open my Admin Dashboard (cms-ui), and the post is there, waiting for me to polish. It’s not generic AI slop. It mentions the coffee shop I actually visited, because it had access to my digital memory.

Why This Changes Everything

This setup shifts my role from “Writer/Coder” to “Editor/Manager.”

This architecture turns the AI into a true Virtual Employee. It doesn’t have magical backdoor access. It has to use the tools provided, just like everyone else. This makes the system robust, predictable, and surprisingly easy to debug.

If the Agent fails, I just check the standard API logs.

I don’t have to remember every article I wrote 5 years ago — my “Intern” does that for me. I don’t have to deal with the friction of setting up a new draft — my “Backend Specialist” handles it.

This is the power of Agentic Workflows. It’s not about the AI writing the whole blog for you; it’s about removing the friction so you can focus on the story.

In the next and final post, I’ll share the Content Vision: How I’m using this machinery to move away from chronological blogging toward “Anchor Articles” and visual storytelling.

Most developers have that one side project. The one that’s never finished. The one that technically “works” but is currently undergoing a “complete rewrite” for the third time.

For me, it’s my travel blog, WanderingBong.

It started as a simple place to dump photos. Today, it’s a custom-built monorepo running Node.js, Next.js, and a team of autonomous AI agents.
Is it overkill for a personal blog? Absolutely. Is it the best way to learn modern software architecture? 100%.
Here is the story of how — and why — I over-engineered my personal site, moving from a WordPress install to a futuristic “Agentic Content Engine.”

Phase 1: The “It Just Works” Era (2015)

Like 43% of the web, I started with WordPress. Because why wouldn’t you? It’s five minutes to install.

The Problem: Stick with WordPress long enough, and you stop being a creator and start being a sysadmin.

• I wanted a specific layout -> Use a plugin.

• The site is slow -> Install a caching plugin.

• The caching plugin breaks the gallery -> Scream into the void.

I didn’t feel like a developer. I felt like I was patching leaks on a ship I didn’t build.

Phase 2: The “Headless” Pivot (2020)

When the world locked down in 2020, I nuked the site. I decided to rewrite it using the “Jamstack” architecture.

• Backend: Strapi (Headless CMS)

• Frontend: Next.js

• Infrastructure: A single Ubuntu EC2 instance.

This was a huge step up. I learned how to manage PM2 processes to keep Node.js alive when it inevitably crashed. I wrestled with HAProxy to terminate SSL and route traffic to different ports.

And honestly? It worked fine. It was stable. It was cheap. It served the content perfectly.

Phase 3: The “ContentPlanner” Monorepo (2025)

So, if Phase 2 was working fine, why rewrite it?

Because the goal wasn’t just to have a blog. The goal was to learn.

We are entering the age of Coding Agents and AI Engineers. I didn’t want to just read about it; I wanted to build with it. I wanted to understand what happens when you treat AI not as a chatbot, but as a developer.

So, I kept the infrastructure that worked (EC2) and nuked the codebase to build a playground for my new AI team.

The Architecture: A Monorepo for Agents

I organized the codebase as a Monorepo using npm workspaces.

• The Brain (cms-be): A custom Node.js/Express backend.

• The Cockpit (cms-ui): A Next.js admin dashboard.

• The Face (blog-web): A public Next.js site.

The Infrastructure: Why I Stuck with EC2

In 2025, moving to Vercel is the default. But I deliberately stayed on my Ubuntu EC2 instance.

Why? Because the infra wasn’t the problem. It was already set up, paid for, and humming along nicely with PM2 and HAProxy.

Migrating to Serverless would have just been busywork. By keeping the “Boring” infrastructure stable, I could focus all my “Innovation Tokens” on the app layer — specifically, figuring out how to build with Cursor and Anti-gravity.

I didn’t want to debug serverless cold starts; I wanted to debug AI hallucinations.

The Secret Sauce: Journals & Memory

This rewrite allowed me to fix the biggest issue with AI content: Context.

If you ask ChatGPT to write a blog post, it’s generic. It doesn’t know you. To solve this, I added a new entity to my custom backend: Journals.

Journals are raw data points — quick notes, location tags, and unedited photos I capture while traveling. They aren’t blog posts. They are memories.

The AI Workflow:

1. cms-mcp: I built a custom Model Context Protocol server that exposes these Journals to the AI.

2. The Result: When I ask the agent to “Draft a post about Ladakh,” it doesn’t scrape Wikipedia. It queries my Journals via the API, sees my note about the “altitude sickness at 10,000ft,” and writes a story that actually happened to me.

Why You Should Over-Engineer

Sure, I could have stuck with the old Strapi setup. It worked.

But I wouldn’t have learned the nuances of Agentic Workflows. I wouldn’t have learned how to structure data (Journals) so an AI can use it effectively.

In a world where AI writes the code, the value of a developer isn’t in maintaining the status quo. It’s in tearing it down to see if you can build something smarter.

My blog is over-engineered. But for the first time in years, it’s teaching me something new.

Share

I am a Product Manager by trade, but I have always been a tinkerer at heart.

There is a specific joy in building new things, breaking things, and occasionally fixing them. But let’s be honest: for those of us who don’t code eight hours a day, the “friction” of building is real. You have a great product idea, but then you get stuck configuring Webpack, fighting with CSS, or debugging a broken deployment.

Eventually, the project hibernates.

For me, that project is my travel blog, WanderingBong. It started years ago on WordPress, evolved into a custom Headless CMS during the pandemic lockdown, and then… sat there. It gathered digital dust because the cost of “tinkering” became too high compared to the free time I had available.

The Paradigm Shift

But recently, I felt a shift. We are entering a new age of software building.
It isn’t just about ChatGPT writing a function for you. It is about Coding Agents and Agentic Workflows.

Code is becoming cheap. The cost of iteration — that painful cycle of “write, review, fix, repeat” — is plummeting. For a Product Manager, this is a superpower. It means the barrier between “Writing a Spec” and “Shipping a Feature” is dissolving.

I realized I couldn’t just read about this shift. I had to feel it. I needed to understand how we will build software in the future — how we will tackle hackathons and side projects when we have an infinite supply of junior engineers at our fingertips.

From Coding to Orchestrating So, I am waking the project up. I’m not just “migrating” the blog; I’m rebuilding it as a playground for this new reality.
I am moving from a system where I manually type every line to an architecture where AI Agents work alongside me as my engineering team.
The Roadmap: Building in Public Over the next few weeks, I’m documenting this journey. It’s a log of a PM trying to build a modern, AI-infused content platform without losing their mind.

Here is the plan:

1. The Evolution: Looking back at the “WordPress to Headless” journey and why the old stack became a cage.

2. The Tech Stack: A deep dive into the “boring” but reliable infrastructure (Node.js, EC2) that acts as the foundation.

3. Agentic Workflows: The real breakthrough — how I’m using Model Context Protocol (MCP) to let AI agents talk directly to my backend to audit content and draft posts.

4. The Vision: How this changes the product itself, moving from static posts to “Anchor Articles” and dynamic storytelling.

The stack is still my reliable “boring” monorepo, but the way I interact with it is completely new.
Code is cheap. Ideas are expensive. Let’s see what we can build when the friction disappears.

Share