Abiding with Claude
Why Vibe Code when you can Abide Code™️?
WARNING: This article written entirely by hand by a human.
Ever feel out of your element when vibe coding?
One of the big challenges of vibe coding is keeping context alive. It's like that game where two people try to keep a balloon from touching the ground. You gotta keep running around poking it into the air.
So, I want to share my technique for long-running vibe coding with Claude Code circa right now (April 2026). I'm writing this partly for other developers or hobbyist developers and partly for non-coders who are just interested in how I spend my hours deep into the night.
It’s Tricky to Rock a Context
If you aren't familiar with context windows, it's basically the amount of overhead that goes into every LLM request. Since LLMs don't have memory of what was last said, you have to keep reminding it. As you code, that space fills up. Eventually, you have to drop some detail otherwise you are basically sending an Encyclopedia Britannica set back and forth which is slow and costly--and LLMs won't even accept that.
The trick, then, is to give Claude enough reference to pick and choose from before it tries to code something. With software projects, there are many dimensions to consider: architecture, design, deployment, old code, new code, stale code, specs you aren't going to use, and on and on.
Code commits comments aren't the place to hold all of that. So, when I work with Claude Code I setup an ecosystem of artifacts. The foundation of which is kept in CLAUDE.MD which is a simple text (markdown) document that Claude looks for first. It's basically always in context.
The 2 most important artifacts I call Vibeplan and Vibelog.
These guys do a lot more than what their name suggests.
The Vibeplan
The section of CLAUDE.md for Vibeplan is really quite simple:
## Vibeplan
Before implementing any non-trivial feature or infrastructure change, create a vibeplan document in `./vibeplan/`.
**Naming format:** `YYYYMMDD_plan_N_short_desc.md` (all underscores, no hyphens)
**Content to include:**
- Problem statement
- Proposed architecture or approach
- Files to create or modify
- Step-by-step implementation plan
- Options considered and recommendation
- Out of scope
- Open questions
**When to create it:**
- When the user says "add this to a vibeplan" or "plan this out"
- Before starting any multi-step changeHowever, the output is massively important. It give Claude a place to plan it's next steps and a place to reference the big picture if context is ever lost; which happens when the context window fills up and the chat must be compacted (a dreaded word).
Claude will even suggest creating a Vibeplan when I ask it too do something involved or “meaty”. These plans are also invaluable for historical use. You can ask things to Claude like “why did we originally build X that way?” or “can you tell me if we’ve planned for Y in the past?”.
The longer and more complex your projects become, the more thankful you’ll be for these documents.
The Vibelog
Code commits are mostly mile-markers. The are succinct, referenceable, scannable. Great for troubleshooting and cataloging—not great for context.
Enter the Vibelog (in CLAUDE.md):
## Vibelog
Create a vibelog entry proactively — after every major commit, or after every 2–3 smaller commits. Don't wait for the user to ask. If a vibelog already exists for this session's work, update it rather than creating a duplicate.
**Naming format:** `YYYYMMDD_batch_N_short_desc.md` (all underscores, no hyphens)
- `YYYYMMDD` — today's date
- `N` — batch number for the day (1, 2, 3, …), increment if a file for that date already exists
- `short_desc` — 2–4 word snake_case summary of the session
**Example:** `20260309_batch_3_axiom_logging_fix.md`
**Content to include:**
- Session scope (1–2 sentence summary of the phase/goal)
- What was built (per-file or per-feature breakdown)
- Deploy steps taken (scripts run, resources created/modified)
- Smoke test results if applicable
- Known issues / follow-ups
- Open items for the next session
**When to create it:**
- After the first commit of a session, or after a natural stopping point
- One vibelog per logical work block — if multiple commits happen in one session, a single vibelog is fine unless the scope shifts significantly
**At the start of a new session:**
Read the most recent vibelog(s) in `./vibelog/` to recover context — open items, known issues, and where things left off.This puppy does the real dirty work. Every time a batch of commits is done, it memorializes the critical code-level detail.
I use batches because it means each block of work I do as a human (1-4 per day) can be Vibelogged and realistically managed both for Claude but for me. I don’t want or need a detailed log for every commit—the actual repo history serves that purpose. This log is about implementation, impediments, open questions, features built. All practical and real-world software engineering crap.
The amazing thing is that Claude can use it like a RAG source (retrieval augmented generation) and automatically Read the most recent vibelog(s) bringing itself up to speed when starting a new session or after big condensation event where context is lost.
Other Vibe-guys
I have used Vibepm, Vibeout, and Vibefacts as well:
## Vibepm
Product requirements and design docs live in `./vibepm/`.
**Naming format:** `YYYYMMDD_prd_N_short_desc.md` (all underscores, no hyphens)
**When to create it:**
- When the user says "write a PRD" or "sketch out the direction"
- Vibepm = what & why (requirements); vibeplan = how (implementation)
---
## Vibeout
Temporary, ephemeral files — test scripts, one-off experiments, scratch docs — live in `./vibeout/`. Not committed to version control long-term.
---
## Vibefacts
Evergreen reference/explanation docs live in `./vibefacts/`. Read relevant vibefacts when the user asks about a topic that may already be documented there. Write a new vibefact when a concept is explained well enough in conversation to be worth preserving.A Product Requirements Doc or PRD is a great place to start when you want to build a product or a feature and you only know the problem it solves, not how you want to build it.
Vibepm creating PRDs as a foundation and predecessor to a Vibeplan is amazing. Claude now will understand why it’s building a thing and for whom. Then, it can run with planning. Also, great for pivots and enhancements.
Vibeout (the best name IMO) is the place where Claude can put the byproducts of it’s work. It likes to write migration scripts, test documents, deployment scripts, other markdown while it works. But, it tends to scatter them all over and doesn’t remember they exist. This is just a catch-all for that. It helps keep the codebase clean, too.
And last but not least, Vibefacts.
When I ask Claude to explain a software libary, technology, or architecture pattern like, say, Vector Databases—it can create a fact about it. This one is great for when you as the Vibedude have no idea what Claude is building.
I’m going to post a sample GitHub project in the comments so you can see some ouput of this. Seeing is vibelieving. Ok, that’s enough out of me today.
-Brad