Method Or Fluke

June 1, 2026

Last week I wrote about leaving Cursor for Claude Code and wondering whether the discipline would hold once I started doing real work, or whether I was just polishing in circles.

It held. Mostly.

Here's what helped:

An onboarding flow at the start of each session (reminiscent of my old Cursor workflow), agent memory cut down to a single personal-calibration file, fresh context from the codebase and docs every time. I had coffee with one of my mentors to talk through some of my concerns, and he pointed me at a few GitHub tools I wasn't using — more merge gates sitting on top of the test suite. With the workflow stable, I got real engine work done: moved the bulk of the client-side derivation logic onto the server, did a round of cleanup, worked down toward the end of my to-do list. A lot of this week went into automating the parts of my process that used to be manual, so the next mod moves fast when I get there. I also replaced a lot of agent skills with codegen — same pattern, deterministic output, no dependency on the agent remembering anything.

It still feels slower than I'm used to moving. But that's partly on purpose. I haven't handed it a big slice yet. I want to trust the process before I bet a hard refactor on it, but I can’t help the nagging feeling there’s still something I’m missing.

Now that I've updated you on that, I want to talk about this week's experiment.

I've been approached a few times about teaching beginner programming. And recently, a friend told me she wanted to learn. Mia was in my MBA program, and we bonded through class projects. She's a former accountant, incredibly smart, and more than capable of learning the material. Plus she offered to be a guinea pig while I figure out whether I have a curriculum in me.

Back to Basics

Everyone rolls their eyes when I bring up Glide. I still think it was the key to the whole thing.

A lot of intro CS courses use Scratch to teach the concepts before anyone touches syntax. Glide is the same idea for data modeling. When I think back on how I actually learned software, I didn't start with code. I started with tables. Relationships. Constraints. Changing one value and watching five other things update.

Context before detail has always worked better for me. In flight attendant school, I had a hard time the first two weeks, when we learned normal procedures. It was just memorization — no explanation of why any step came where it did, which made the routine nearly impossible to hold onto. Then in the third week we learned emergencies, and the emergencies explained the why behind all the normal procedures at once. After that I didn't have to memorize the sequence. I could reason my way back to it, and even guess correctly at things we hadn't covered yet, because I finally had the map of how all the details fit together.

This is all to say a syntax-first approach would not have worked on me, or at least not quickly. No-code let me wrestle with the shape of the problems I was solving, decoupled from their implementation.

So when I sat down to teach Mia, I didn't start with syntax either. Mia is a wedding planner, and I've done enough wedding planning myself to understand the process, so I decided to recreate the conditions I learned under. To build in a way that felt more like solving a grade school word problem than jumping into a foreign domain. To prep, I built a small slice of a wedding-planning app for her to rebuild from scratch on her own account.

Teaching Constraints

From my own experience, budgeting is the hardest part of planning a wedding. It's mostly the work of keeping expectations aligned with reality.

People who've never planned an event tend to assume DIY is the cheap route, but guest count is one of the few variables you can't really escape. Catering alone often runs 30–50% of the budget. A backyard wedding with takeout BBQ is one thing; professional venues usually make you choose from an approved caterer list. A rough rule of thumb I've used: take a venue's approved caterers, find their cost per plate, multiply by guest count, then multiply that by about three. If the result is way over what you wanted to spend, it's time to adjust expectations.

I knew Mia would have her own priorities when designing an app, but this seemed like a good place to start because it introduces constraints and variable manipulation.

Glide is a little strange — the client, server, and database layers are all blended together, and everything looks like a table. Later, in code, we'll have to untangle what belongs in persistence versus application logic. That's fine. I learned that distinction later too.

The first table was weddings. Each wedding had a total budget and a guest count, and from those two values it derived a catering budget and a budget per plate. For simplicity, I set catering at one third of the total, and budget per plate is that number divided by guest count.

Next, a caterers table, where the only field that matters is price per plate.

Then a matching table pairing every wedding with every caterer — three weddings and five caterers gives you fifteen pairings. Each pairing compares the wedding's budget per plate against the caterer's price per plate. If the budget covers the price, the pairing is eligible. If not, it isn't. I could pull the compiled results back into the wedding table, producing the list of caterers each couple can afford. Change the guest count or the budget, and the list of available caterers changes with it.

As a follow-up lesson, I added venues: cost, capacity, approved caterers. This is where it gets interesting, because a venue isn't only judged on its own properties. It also constrains the catering options downstream. Starlight Conservatory only approves Moonlight Provisions, and Moonlight Provisions charges $90 a plate. Two of the weddings had per-plate budgets of less than that — which meant they couldn't use Starlight Conservatory at all, regardless of what the venue itself cost or how many people it held.

Unless they cut their guest count or raise their budget. Just like real life.

The venue matching table mostly exists to make that reasoning visible. The logic actually lives in pieces: the wedding computes which caterers it can afford, the venue stores which caterers it allows, and the matching table just exposes the overlap and checks whether at least one valid option survives. By the end, venue eligibility was the tail of a chain:

Budget + guest count → budget per plate → eligible caterers → venue's approved caterers → eligible venues.

It sounds simple because it is. None of the individual pieces are complicated. But built right, it's a powerful system. Change one number and watch the consequences fan out. Glide makes those consequences visible.

The Actual Lesson

Tonight Mia came over and I helped her rebuild the whole thing on her own account.

Then I had her upload screenshots into ChatGPT — not to have it teach her software, but to brief it on what we'd built and how I learned, so it would recognize the exercise and keep nudging her in a useful direction once she started working alone and had questions. The first thing it told her, while we were still sitting there, was that this wasn't really a wedding app. It was a matching app that happened to be about weddings.

Which was the entire point.

After briefing her agent, I asked her what she actually wanted to build. Something that would make her life easier as a wedding planner. She came up with a timeline generator for wedding days — not "generate" in the AI sense, generate in the wedding-planner sense. Feed in guest count, bridesmaid count, ceremony time, song lengths, and the rest, and have the day's timeline populate itself. She asked whether that was even possible in Glide, or too complex. I told her it was a great place to start, and I meant it, because it's the exact same problem wearing different clothes. Facts, relationships, constraints, derived outputs. Once you can see the skeleton, the surface details are just content.

That's what I'm actually trying to teach — not Glide, not weddings, but the habit of seeing the skeleton first.

I spent three weeks in Glide before any of it felt intuitive. Nobody explained pairings to me. Nobody explained derived state or constraint systems or event sourcing. I built things, broke them, changed the structure, built them again. The understanding came out of the repetition — out of being stuck on something for a day, and out of the small high of recognizing a pattern I'd fought through once and could now reuse somewhere new. Again and again, until the build started to feel like a story with a chapter for each lesson learned.

Which is why I don't think I can hand someone my intuition fully formed. I can explain the patterns, build the examples, point at what matters — but I believe programming is kinesthetic. The most I can do is set up the conditions to shorten the learning loop as much as possible, and then get out of the way. What I don't know yet is whether that's a method or just how I happen to work — whether the conditions that made it click for me can be set up deliberately for someone else.

There's a real worry about AI in learning — that people use it to generate the answer and skip the work. That worry is legitimate, and skipping the work is still the wrong way to use it. But it's not the only way to use it.

I built my whole Glide prototype by hand. The tool may have an autofill feature by now; my account never had one, and I wouldn't recommend it if it did. You plug in every relationship yourself and watch it break. The reps don't get faster. What's changed is that you no longer get stranded in the middle of one. When I was learning, getting stuck on a single concept could cost a week of waiting to find someone who knew the answer. An agent tutor sitting next to a manual build collapses that dead time without doing the building for you — it explains the pairing, points at what I'm missing, answers the question at 11pm when no one's around, and then I still have to go build the thing. That's the version I'd recommend to a beginner: an agent to keep you unstuck, a no-code tool to make you do the reps.

Tonight’s “app” was just me walking her through the first rep. I’m excited to see what happens when she takes them on her own.