I Built a Flowchart Engine with an AI. Here's What Actually Happened.

In the last post, I talked about why AlpineJS deserved a flowchart engine and how that idea got lodged in my brain. This one is about what happened next — the part where I actually had to build it.

Fair warning: this isn't one of those "I typed a prompt and an entire framework appeared" stories. If you're looking for that, I've got bad news about how software development works.

A Little Context About Me

I've been writing code in some form or another since middle school. I'm turning forty this year, so if you do the math, that's roughly twenty-five years of staring at screens and wondering why something that should work doesn't. My earliest paid work was editing friends' Myspace pages — yes, that Myspace, and yes, I charged for it. Entrepreneurship starts early when you figure out that teenagers will pay actual money for custom CSS.

Over the years, I bounced through HTML, CSS, lightweight JavaScript, PHP, dabbled in C, C#, Python — the usual journey of a developer who keeps trying other languages and keeps coming back to PHP like it's comfort food. I got serious about building full web applications about ten years ago, starting with WordPress and custom-rolled frameworks before discovering Laravel, which is where everything clicked. These days, I reach for the TALL stack about ninety percent of the time, though I'm a fan of Vue as well. The point is, I've been around long enough to know what I don't know, and building a flowchart engine from scratch was firmly in that category.

It Started with a Question, Not a Plan

The first conversations I had about AlpineFlow weren't even with Claude. I use multiple AI tools for research — I read docs constantly and bounce ideas around to stress-test my thinking. So I pitched the concept to a few different AIs to get a sense of whether this was worth pursuing.

Gemini flat out told me not to bother. It said I was building something that already existed and that I should just use ReactFlow or VueFlow. Which, respectfully, missed the entire point. I didn't want to use React or Vue. I wanted to make node-based UIs available to Alpine developers — people who could immediately use it with PHP and Livewire without being locked into a framework they don't work with every day. Telling an Alpine developer to "just use ReactFlow" is like telling someone who asked for directions to the grocery store that they should just move closer to a restaurant.

Claude was the only AI that actually engaged with the idea. Not with blind enthusiasm — with genuine curiosity. The early conversations were a feasibility study conducted by someone who wasn't entirely sure this was a sane idea.

Is this even possible?

How difficult would it be?

Can one person with an AI collaborator actually pull this off?

I sent Claude links to xyflow's core — the MIT-licensed engine that powers ReactFlow — and essentially said "read this and tell me what you think." The early exchanges were a lot of back-and-forth analysis. How does the core handle node positioning? What would viewport management look like in Alpine's reactivity model? Where are the hard problems going to be?

That difference in approach is why Claude became the collaborator on this project. Not because it told me what I wanted to hear, yet because it took the idea seriously enough to actually explore it. I wasn't asking Claude to build AlpineFlow. I was asking Claude to help me figure out if AlpineFlow was even worth attempting.

Spoiler: it was.

From "Is This Possible?" to "Okay, What's the Plan?"

Once we established that this wasn't a fool's errand — or at least not entirely — the project shifted into planning mode. And this is where things got genuinely interesting, because the workflow that emerged wasn't what most people picture when they think about AI-assisted development.

There was no single magical prompt. There was no moment where I said "build me a flowchart engine" and went to make coffee. What actually happened was a structured, iterative process that looked a lot like how you'd work with a human collaborator, just faster.

Claude laid it out pretty clearly early on: we had to start with the core. Everything else — directives, plugins, stores, the developer-facing API — depended on getting the foundational engine right. That meant using battle-tested dependencies where they made sense and building custom where Alpine demanded it.

From there, it became a cycle. Plan doc, then implementation doc, then execution. Rinse and repeat for every major piece of the system. Each planning phase involved real discussion — not just "here's what to do next" from either side, but actual debate about tradeoffs and approaches. Then we'd nail down the specifics in an implementation doc and go build it.

If that sounds methodical and slightly boring, good. That's what working software looks like.

The Part Nobody Talks About: Guiding the AI

Here's the thing about building with AI that I think gets lost in the hype. The AI doesn't have taste. It doesn't have opinions about developer experience. It doesn't wake up in the morning and think "you know what would feel really elegant as a directive?" That part is entirely on you.

Early on, I realized that if I didn't set guardrails, the output would drift. Not in a broken way — Claude is genuinely good at producing functional code — just in a way that didn't feel right. It would feel like what it was: code generated by an AI that doesn't use Alpine every day.

So I baked rules into the process. Actual guidelines that governed how we approached every piece of AlpineFlow. Everything had to feel directive-driven. The syntax sugar had to be thoughtful, not just convenient. The API had to feel like a natural extension of Alpine, not a foreign library bolted onto it. I wanted a developer to look at AlpineFlow and think Caleb Porzio himself could have built this.

That last part mattered to me more than I can overstate. Caleb's work on Alpine is brilliant not just because of what it does, yet because of how intentional every piece of it feels. I wanted AlpineFlow to honor that same design philosophy. So every plan doc, every implementation doc, every conversation with Claude had that standard baked in.

The AI brought speed, knowledge, and tireless iteration. I brought the vision, the taste, and a very specific idea of what "good" looked like. Neither of us could have done it alone. (Narrator: Claude definitely could not have done it alone.)

What the Day-to-Day Actually Looked Like

I want to demystify this a little, because I think people imagine AI-assisted development as either magic or chaos, and the reality is neither.

A typical cycle looked like this:

I'd identify the next piece that needed building — say, the edge routing system. I'd start a conversation with Claude about how ReactFlow handled it, what xyflow's core did under the hood, and what the Alpine-native equivalent should look like. We'd go back and forth, sometimes for hours, working through the architecture.

Then we'd write up a plan doc. Not a novel — a focused document covering what we were building, why, the constraints, and the approach. That plan doc became the blueprint.

Next came the implementation doc — more granular, more technical, specific enough that execution was mostly a matter of following through. And then we'd build.

After that? Testing, tweaking, occasionally scrapping something and starting over. Rinse, repeat. For hours.

It's not glamorous. It's software development. The AI just made it possible for one person to move at a pace that would normally require a small team.

The Honest Truth

I'm writing this blog series with Claude, and we're being transparent about that, because I think the developer community deserves a real picture of what AI collaboration looks like in practice. It's not a cheat code. It's not magic. It's a tool — an incredibly powerful one — that still requires a human with a vision, opinions, and the willingness to tell the AI "no, that's not good enough, try again."

AlpineFlow exists because I had an idea and an AI helped me execute it. It's as good as it is because I cared deeply about the details and refused to ship anything that didn't meet the standard I'd set. Both of those things are true at the same time, and I don't think they're in conflict.

In the next post, we'll get into the specifics of how we designed AlpineFlow's API — the directive philosophy, the syntax decisions, and why developer experience was the north star from day one. That's where things get nerdy. You've been warned.

This is Part 2 of a series about building AlpineFlow. Follow along as we build in public — one human and one AI, side by side.