Have you read this? Hanging Promises for Control Flow.

So, if I understand it correctly, you’re inside a serverless function. You hit a step you can’t finish in this invocation. You need to get the user’s async function off the stack without throwing — because user try/catch might swallow the signal. So you await a promise that never resolves. Function suspends, process gets torn down, GC cleans up the frame, fresh invocation replays from the top using a memoization map of finished steps.

Clever, though isn’t this a workaround for a problem that only exists because suspension isn’t a first-class thing the runtime owns?

Seems like the whole maneuver leans on a property of the language’s runtime, where each language would require its own version of the trick with its own caveats.

As you know I work and we bet (well, bet) that suspension shouldn’t be a clever thing the runtime sneaks past user code — it should be a protocol.

Coincidentally enough, the protocol calls for a durable promise that lives outside any single process, or any single language.

When a function awaits a durable promise, the runtime parks the computation. Promise resolves — same process, different process, one that doesn’t exist yet — computation comes back. No exception to dodge, no GC trick to lean on. The await (or in the current Resonate Typescript SDK version its yield) means what it says.

If that’s right, the hanging-promise technique is a great answer inside one language’s constraints, but Resonate is making the same problem moot one layer down by pinning the answer to a protocol instead of a runtime.

If you think I’ve got something backwards, tell me.

The vibe in "vibe coding" is the developer's intuition about what the code should do, how it should fit together, and when something's off.

Not the agent, or the model. Not your keyboard. The vibe is you.

I've been shipping software for 15 years — tech support, devrel, docs, product, engineering, startups that made it, startups that didn't. When I sit down with Claude Code now, I'm not just prompting an AI to write or build something for me. I'm compressing 15 years of pattern recognition into a structured environment where an AI can actually be useful.

That distinction matters. And I think most of the "vibe coding" discourse misses it completely, though often humorously.

The real magic happens before Claude writes any executable code.

By the time I say, “hey Claude, build me a dashboard”, I've already put together rules to follow, skill directories, and decision structures that Claude reads at the start of every session. Every project has an AGENT.md — a structured document that tells any AI agent exactly what the project is, what the stack looks like, what the architecture rules are, and what not to break. Above that, a workspace-level orientation file maps every project, defines data boundaries, and enforces privacy rules. Below that, a knowledge layer — domain-specific documents covering everything from data source registries to privacy regulations to tax law to investment frameworks, etc.

The AI doesn't guess. It reads. Every new Claude session starts fresh — no memory of yesterday — but within 30 seconds it has full context and is capable of producing quality output.

In other words, my 15 years of experience is now applied to the structure that makes Claude’s output predictable in quality.

And it's the same idea all the way down.

This pattern — write a structured spec, then generate the output — isn't just how I work with Claude Code. It's the same principle behind what we're building at .

Resonate is a durable execution platform. Instead of hand-writing server components for every possible deployment topology, we wrote a formal protocol specification. Language-agnostic. Transport-agnostic. Storage-agnostic. Then we generate the components from the spec.

Need a server targeting Postgres + HTTP? Generate it. Need one for Cloudflare Workers + D1? Generate that. Every line of code exists because your stack needs it. Nothing else ships.

The parallel is almost too clean: I don't hand-write code for each project from scratch anymore. I write structured context — rules, skills, architecture docs — and let Claude generate the implementation. Same mentality. Specify the constraints, generate the output, validate against the spec.

In both cases, the quality of the output is determined by the quality of the specification. Garbage spec, garbage code. Precise spec, precise code. The generation step is the easy part.

Fresh instances and structured workspaces are simple but key aspects to quality Claude usage.

One thing people don't realize about working with Claude Code: every session is a blank slate. The model doesn't remember what you did yesterday. It doesn't learn your preferences over time. Every conversation starts from zero.

That sounds like a limitation. It's actually a usable feature.

Because every session is fresh, you're forced to make your context explicit. You can't rely on "Claude knows what I mean." You have to write it down. The rules, the architecture, the boundaries, the patterns — all of it lives in files, not in your head.

And once it's in files, any agent can read it. Not just Claude. A CI bot. A code review tool. A new team member. The structured workspace becomes a unique product of its own.

I spin up fresh Claude instances for specific tasks all the time. One for frontend work, reading the component library docs. One for data pipeline work, reading the data source registry. One for financial modeling, reading the tax reference corpus. Each one gets exactly the context it needs and nothing it doesn't.

The workspace is the brain. Claude is the hands.

If you're new to programming and you're vibe coding, you're probably generating code you can't fully evaluate. You'll probably accept a function that works but scales quadratically because you've never been burned by that. You'll probably let the AI set up auth in a way that's fine for a tutorial and catastrophic in production.

That's not a reason to stop. It's a reason to build your own pattern library as you go.

Every time Claude generates something you don't understand, that's a learning opportunity you're either taking or skipping. The developers who use AI to learn faster will end up with great instincts — just compressed into fewer years. The ones who use AI to avoid learning will plateau at "can generate code, can't evaluate code."

Velocity comes from having pre-built component libraries, a clear architecture, and an AI that reads the entire project context before writing a line.

One danger for experienced devs isn't going too slow. It's going so fast that everything feels worth building. The cost to produce software has collapsed for everybody. Which means speed isn't the differentiator anymore. Judgment is. Knowing which direction to go is what matters.

The vibe has always been you — about knowing what to make, how it should fit together, and when something's off. AI has just become fast enough to match whatever level of that you bring.

I see it in engineering discussions, cultural debates, even in personal growth.

Here's the paradox:

Intertwingularity is real. Knowledge doesn't sit in neat categories. There are no absolute definitions or rigid boundaries. Everything flows, shifts, and overlaps. The world is messy, fluid, and in constant motion.

Yet, as human beings, we depend on models and definitions. Our ability to communicate, teach, and learn hinges on structure—on drawing lines, labeling things, and following rules. Without these models, society can't function.

This contradiction echoes the Dreyfus Model of Skill Acquisition.

According to the model, beginners need clear rules to operate. They follow step-by-step instructions because they lack the experience to interpret complexity. But as they gain mastery, their intuition grows. Experts don't follow rigid instructions—they feel what to do. Their actions are shaped by context, not checklists.

I’ve seen this in software engineering. Concepts like “durable execution” “event-driven architecture,” or “serverless” are abstract and often fluid in practice. But to discuss them, we need shared mental models. We define things like “pure functions” or “side effects” not because they exist in perfect clarity, but because without these definitions, communication becomes impossible. A beginner might take these models literally. An expert knows they’re just tools—useful simplifications to help navigate complexity.

This paradox explains many individual and societal disagreements.

Take politics. Experts often speak in nuances. But the public—understandably—wants clarity. Politicians exploit this tension. They weaponize simplicity, offering rigid models that feel safe, even if they mislead. They use the paradox to win arguments, votes, or influence—often at the expense of truth.

And yet, we need those simple models.

Most of us are beginners in many areas of life. That's not a flaw—it's just reality. Society needs frameworks and definitions to function. Teachers can't educate without them. Businesses can't operate without clear processes. Even something as basic as a map requires us to define what a “road” is and where it begins and ends.

Without definitions, mental models collapse. And when they do, communication breaks down. Education fails. Society stumbles.

But those same models create tension. Experts may find them limiting. Beginners may find them confusing. And both may talk past each other without realizing why.

As long as we're human, we'll live with this paradox.

We need structure to grow, and we need to outgrow that structure to master.