Resources

All Resources

Learnings for quick notes. Articles for the longer version.

Editorial cover illustration for an article about MCP servers and workflow

MCP Servers Don't Just Expose Tools. They Encode How Work Gets Done.

Most writing about MCP stops at interoperability. The stronger framing is that good MCP servers encode workflow, permissions, context loading, and judgment. That is where the real leverage is.

Apr 8→

Article

How I finally started my game using Scenario

I’ve wanted to build my game for a while. But I needed a solid visual identity to finally start coding. Generic AIs were too inconsistent for a real project. The fix was Scenario.com. By training a custom model on 25 specific images (refined with Claude to hit a \"Zelda meets Clash Royale\" vibe), I finally got a unified look. AI didn't do the creative work for me; it just removed the technical wall. Bestiary is now officially in development.

Feb 17→

Learning Feed

Apr 8, 2026

AI gets more valuable when it has better context, not when it moves faster.

We kept treating speed as the main lever. Ship faster. Prompt faster. Run more in parallel.

But the real jump came from somewhere else. A well-contextualized task can be worth far more than a faster one.

Once the context is right, the output gets sharper without adding more chaos.

Advice: before you add another agent, improve how the current one finds and uses context.

Apr 7, 2026

An MCP server is not an API. It's a teacher.

We built an MCP server with 12 tools. "Create note." "Search notes." "Update note." Clean API, good docs.

The agent used it like a database. It created notes, stored them, never connected them. The vault was a pile of files.

We rewrote the instructions. Same 12 tools. But now each tool says when and why to use it. The server teaches a methodology: capture, compile, query, output, lint. The agent stopped being a CRUD client and started being a knowledge gardener.

Rule: the tools are the verbs. The instructions are the grammar. Ship the grammar.

Apr 6, 2026

The PM won't write tickets anymore. They'll draw the screen.

We flipped the product flow on a client project. Instead of writing user stories, the PM vibes a working screen and tags the blocks "ready to dev" or "ready to dead".

No Jira ticket. The prototype is the spec.

When anyone can build a screen in 20 minutes, why describe it in words?

Rule: the interface between PM and dev is becoming the screen itself.

Feb 23, 2026

AI struggles with CSS precision; don’t over-invest

AI is great at getting you to “looks okay”.
It is much worse at pixel-perfect, design-system-grade CSS.
That’s where time disappears.

Rule: treat CSS polish as a post-MVP phase.

Ship with acceptable UI, then do a targeted cleanup pass with clear design constraints.

Feb 23, 2026

Cheap code makes useless features feel justified

VibeCoding drops the cost of building.

That’s a superpower, and a trap.

When each feature is “only 30 minutes”, you start shipping features nobody asked for.

Rule: every ticket needs a user-facing outcome, a definition of done, and a reason it matters. If it can’t be explained in one sentence, it’s probably scope drift.

Feb 17, 2026

Claude.md is the cheapest architecture you’ll ever write

A good claude.md file does more than “give context”.
It stabilizes decisions, prevents re-explaining, and keeps the AI aligned over time.
Without it, you’re paying in drift and rework on every iteration.

Rule: write context once in a canonical file, and treat it like part of the architecture.

Feb 17, 2026

If the ticket is fuzzy, the feature will be wrong

VibeCoding magnifies unclear intent.
When the feature request isn’t precise, you don’t get “almost right”; you get a different product. The fix is boring but effective: write the ticket like a contract, then let the AI execute.

Rule: if you can’t define “done” in one sentence, the AI will invent it for you.

Feb 17, 2026

The owner’s trap

Trying to keep standards high by touching everything yourself eventually slows the system more than it protects it.

Quality needs mechanisms, not constant personal intervention.