A Principal PM, a ten-year-old IT degree, and Claude walk into a Vercel deploy.

A note before we start: this is an experiment, not a tutorial. The code under this very page isn't reusable, isn't production-grade, and isn't trying to be. I didn't write it to teach AI-assisted development. I wrote it to learn something specific about my own job — and probably yours.

The problem I wanted to poke at

I'm a Principal Product Manager. Lately, every roadmap conversation has the same subtext: "It's faster now, right? Because of AI?" Stakeholders have watched the demos. They've seen someone build a to-do app live on stage in fourteen minutes. They've concluded — reasonably — that timelines should compress.

On the other side of the table, our engineers are still spending real time on real things: integrating with our CMS, wrestling with caching, fixing the build pipeline that broke when someone bumped a minor version. The actual day-to-day is closer to the same job it always was, with AI as a sometimes-helpful assistant. Not a replacement.

That gap — between what people think AI can do and what shipping software actually takes — is the one that's making timelines uncomfortable. It's also the one I'm responsible for managing.

So I ran a small experiment on myself.

The setup

I have an IT degree. I haven't shipped serious code in over ten years. I sit between communications and engineering, which makes me exactly the wrong person to write a Next.js app from scratch — and exactly the right person to test how far AI gets a non-developer.

One thing to be honest about up front: in prep for this, I did a SitecoreAI Developer Training. Not because the experiment required it, but because I wanted enough context to recognize what Claude Code was asking me to do — local dev setup, the Sitecore CLI, how the project is supposed to hang together. That preparation paid off more than any prompt I wrote during the build itself. Going in completely cold would have been a different — and probably much shorter — story.

💡 Tip · AI is great at typing code. It's less great at telling you how to set up your local machine, what sitecore commands to run, or whether an error you're seeing is the framework's fault or yours. If you're tempted to try this with zero technical background, be honest about that gap. A short training on your stack is one of the highest-ROI prep moves you can make.

The brief I gave myself:

Stack: SitecoreAI, Vercel, Tailwind CSS, Next.js. Our actual stack. No greenfield toy project on a hipster framework.
Goal: a working personal blog ("Core Memo") that I'd actually use.
Tools: Claude — the Design skill for design work, then Claude Code for the build.
Time: weekend-shaped, not sprint-shaped.

No team, no backlog. Just me, three Claude conversations, and the urge to find out where it breaks.

The approach: three conversations, three phases

I did this in three deliberate steps instead of one long "build me a blog" prompt. That structure is the single most useful thing I learned.

Phase 1 — Design system, with Claude (Design). I went in with almost nothing — a name ("Core Memo"), a few favourite colours, and not much else. No reference kit. No carefully engineered prompt. What came out was a coherent system: typography scale, colour tokens, dark mode, a defined brand red, sensible component defaults. The honest surprise of the whole experiment lives here. I expected the design phase to be where AI would fall apart without serious scaffolding from me. It didn't.

ℹ️ Note · If you've been holding off on trying this because you assume you need a detailed brief, a reference site, and a clever prompt — try it with three colours and a name first. The first pass surprised me. You can always tighten the screws later.

Phase 2 — Website mockup, with Claude (Design). New conversation, same skill — but this time I had something to hand it: the design system from Phase 1. I asked for a clickable React mockup of the full blog: homepage, article, about, topic index, search, 404. Critically, I asked for three variations along five axes — hero treatment, list density, sidebar yes/no, brand-red intensity, light vs. dark default — plus a live tweaks panel I could play with.

ℹ️ Note · Variations are how non-designers communicate taste. I can't describe the homepage I want. I can absolutely point at one of three and say "that one, but redder." Make the AI do the option-generation work.

Phase 3 — Code, with Claude Code. Different surface, agentic mode, real file system. I asked it to take the mockup and ship it on our stack: Next.js, Tailwind, SitecoreAI, deployed on Vercel.

This is where the experiment got honest.

Where AI cheated (and why I respect it)

Two moments stood out. Both were AI quietly choosing the path of least resistance — and not flagging it.

Cheat #1: Next.js 15, not 16.

Next.js 16 was out. The upgrade has real friction: a new opt-in caching model around the "use cache" directive (Cache Components), an overhauled routing and navigation system, and a few deprecated APIs removed outright. Claude scaffolded the project on 15 without mentioning the choice. I didn't notice for a while because… it just worked. When I eventually asked about a feature only available in 16, the truth came out: upgrading would be non-trivial, so it picked 15.

⚠️ Watch out · If you care about a specific version, pin it in the prompt. "Use Next.js 16 with the App Router and Cache Components." AI optimizes for something runs — not something runs on the stack you'd defend in an architecture review.

Cheat #2: Pure headless instead of the SitecoreAI page editor.

This one matters more.

The whole point of running a CMS like Sitecore — for most teams — is the editor experience. Marketing wants to open the SitecoreAI page editor, drag a hero block onto a landing, change the copy, hit publish. That's the value proposition. That's why we pay for it.

Claude built a clean headless setup that fetches data from SitecoreAI and renders it in Next.js. It works perfectly — for me. It's also, in the most important sense, the wrong shape: a marketer can't open the SitecoreAI WYSIWYG editor and edit this site without the additional component wiring being in place. AI took the easier integration path because pure headless has fewer moving parts.

⚠️ Watch out · If editor experience matters to your stack (and on SitecoreAI, it almost always does), call it out before the build, not after. "Wire up the components so the marketing team can edit them in the SitecoreAI WYSIWYG editor." Otherwise AI will quietly default to the developer-friendly version of your CMS — which is the version your marketing team can't use.

This isn't AI being lazy. It's AI doing exactly what an under-pressure engineer would do: take the path with the least integration friction, ship the demo, and hope nobody asks about the editor at the end. The difference is that an engineer would tell you. AI ships it cheerfully and you find out at the demo.

There's a small irony here: the platform is now literally called SitecoreAI, and the AI built it without enabling the AI-first editor experience.

The result

The blog you're reading right now is the result. It's deployed on Vercel, talks to SitecoreAI, looks the way I designed it, and didn't require me to write code by hand. What it required from me was a stream of small product decisions: which variation, which version, which trade-off, which default to push back on.

Which is, honestly, my actual job description.

It's not production-grade. It's not reusable. The next person who tries to build on top of it will hit edges. And that's fine — that wasn't the point.

What I'm taking from this

The expectations gap that's making our timelines uncomfortable is real, but it's not symmetrical. On the "ship a small thing on a known stack" end, AI is closer than I expected — closer than most stakeholders probably realise. On the "integrate properly with our enterprise toolchain" end — versions, editor experiences, deployment pipelines, governance, the boring middle of any real project — there's still a meaningful gap. And that gap is exactly the part where experienced engineers spend most of their time.

The honest move, as a PM, is to stop asking "can AI do this?" and start asking "which part of this is the small-thing part, and which part is the integration part?" Those two scale very differently. Plan accordingly.

The other thing I'm taking away is harder to say without sounding either naive or alarmist, so I'll just say it: most of the time I spent on this experiment didn't feel like coding. It felt like product management. Reading diffs, making trade-off calls, pushing back when the easy answer wasn't the right one. The work didn't disappear. It moved.

What's next

This experiment isn't done. The same blog is going to be the workbench for the next rounds:

Wire up the SitecoreAI page editor properly. Mark the components so a marketer can actually edit this site in the WYSIWYG editor without me. The shortcut Claude took has to be paid back; that's a post on its own.
Upgrade to Next.js 16. Walk through the migration with AI and see what breaks. I want to know whether AI is good at upgrading code or only at writing it — those are very different skills.
Try something genuinely harder. Personalization, or a SitecoreAI Stream / Agentic Studio integration. The kind of thing where the headless-vs-WYSIWYG shortcut isn't available, and where the integration part is most of the work.

Each one will be a post. Some will go better than this one. Some will go worse. That's the point.

If you're a PM, a marketer, or a recovering developer staring down the same gap, I'd love to hear what you're trying. The comments are off (it's the first post — give me time), but I'm easy to find on the links in the footer.

— Manuel