Josh Tune

Stacked vs. Flat MRs: My Simple Rule

Josh Tune — Mon, 25 Aug 2025 00:00:00 GMT

I use two modes. First, I build pieces that stand alone. Then, I connect those pieces. When I’m building things that don’t depend on each other—like a data grid, the form fields, and the full form—I don’t stack Merge Requests, MRs . Each one gets its own branch and its own review. This keeps the work small, easy to test, and easy to ship in any order. No waiting. No messy rebases.

Once the parts exist, I switch to stacked MRs to wire them up in a clear order. I stack because each step depends on the last, and I want reviewers to follow a simple story. For our grid + form flow, my stack looks like this:

MR 1: Add the grid to the page. Show rows, paging/sort, empty state. No form yet.
MR 2: Add the drawer. Clicking “Create” or a row opens the drawer. The drawer is empty but proves the flow.
MR 3: Put the form in the drawer + actions. Load data, validate, save, show toasts, refresh the grid.

This split keeps the build phase fast (flat MRs for grid, fields, and form) and the connect phase clear (stacked MRs for page → drawer → form wiring).

If work can land in any order, keep it flat. If it must land in a specific order, stack it. Small steps, plain titles, demo each step.

What do you think? Let me know your thoughts in the comments.

Stacked Merge Requests on GitLab with CLI Tools

Josh Tune — Thu, 28 Aug 2025 00:00:00 GMT

Summary (Highlights)

git-spice → The most automated option; one command (gs stack submit --fill) creates the whole MR stack and keeps downstream branches updated automatically when a parent changes.
git-town → Great if you already use Git-Town; build stacks with append, then keep everything in sync with git town sync --stack and open/update MRs with git town propose --stack.
glab / Git push options → The native but manual route; you create each MR targeting its parent branch and rebase + force-push children when a parent changes.
Key takeaway → If you want automation, use git-spice; if you want structure with flexibility, use git-town; if you want bare-metal control without extra tools, stick with glab/push options.

Warning

I have not tested these tools in production. Use at your own risk.

Lets Get Started

Stacking merge requests (MRs) is a powerful way to manage dependent changes. Instead of waiting for one MR to merge before opening the next, you can build a chain of branches, each with its own MR. This improves review flow and keeps changes focused.

In this post, we’ll look at how to create a stack of four MRs off main with different CLI workflows, and how to update the entire tree if one MR changes.

The Example Stack

We’ll create this structure:


main → mr-1 → mr-2 → mr-3 → mr-4

Each tool section shows:

How to create the four stacked branches and open MRs.
How to propagate changes when one MR is updated.

A) git-spice (purpose-built for stacked MRs)

git-spice is designed for stacking and works with GitHub and GitLab. It can create, update, and restack MRs automatically.

1. Create branches & submit stacked MRs

# start from main
git checkout main
git pull

git checkout -b mr-1
# …changes & commit…

git checkout -b mr-2
# …changes & commit…

git checkout -b mr-3
# …changes & commit…

git checkout -b mr-4
# …changes & commit…

# submit the entire stack as MRs
gs stack submit --fill

--fill auto-populates MR titles/bodies from commits. Use --draft if you want them as drafts.

2. Propagate an update

Suppose mr-2 gets new commits or an amend:

git checkout mr-2
# …make changes & commit…
gs branch submit --fill

git-spice automatically rebases downstream branches (mr-3, mr-4) and updates their MRs.

B) git-town (branch workflow enhancer)

git-town extends Git with high-level commands. It manages parent/child branch relationships and supports GitLab MRs.

1. Create branches & open stacked MRs

git checkout main
git pull

git town hack mr-1
# …changes & commit…

git town append mr-2   # child of mr-1
# …changes & commit…

git town append mr-3   # child of mr-2
# …changes & commit…

git town append mr-4   # child of mr-3
# …changes & commit…

# push and open MR pages for all branches
git town propose --stack

2. Propagate an update

If mr-2 changes:

git checkout mr-2
# …amend/commit…

git town sync --stack
git town propose --stack

sync --stack rebases all children (mr-3, mr-4) onto the updated branch and re-pushes them.

C) GitLab-native (glab / push options)

If you don’t want external tools, you can use glab or Git push options. This is more manual, but it’s native.

1. Create branches & stacked MRs with `glab`

git checkout main
git pull

git checkout -b mr-1
# …changes & commit…
glab mr create --source-branch mr-1 --target-branch main --fill

git checkout -b mr-2
# …changes & commit…
glab mr create --source-branch mr-2 --target-branch mr-1 --fill

git checkout -b mr-3
# …changes & commit…
glab mr create --source-branch mr-3 --target-branch mr-2 --fill

git checkout -b mr-4
# …changes & commit…
glab mr create --source-branch mr-4 --target-branch mr-3 --fill

Each MR’s target branch is its parent, creating the stack.

Alternative: Git push options

git push -o merge_request.create \
         -o merge_request.target=mr-1 \
         -u origin mr-2

Repeat for each branch, pointing merge_request.target at the parent.

2. Propagate an update

If mr-2 changes:

git checkout mr-3
git rebase mr-2
git push -f
glab mr update --fill

git checkout mr-4
git rebase mr-3
git push -f
glab mr update --fill

Here, you manually rebase each child branch and update its MR.

Summary

git-spice → Automates MR creation and restacking; best if you want minimal manual work.
git-town → Semi-automated; great if you already use Git-Town for branch management.
glab / push options → Fully manual but official; good if you prefer no extra dependencies.

In all cases, the key idea is the same:

Branch each feature off the previous one.
Target each MR at its parent branch.
When a parent changes, rebase children and update their MRs.

Stacking MRs can feel like overhead at first, but with the right tooling, it keeps reviews smaller, clearer, and easier to merge.

What's your favorite git workflow? Do you stack MRs? Let me know in the comments!

Three Weeks with AI CLI: What I’ve Learned

Josh Tune — Tue, 14 Oct 2025 00:00:00 GMT

It’s been about three weeks since I started building with AI CLI tools, mainly using Claude CLI and APEX, and honestly — it’s been a ride. It’s fun, it’s fast, and it fixes stuff on the fly. But I’ve learned a few lessons that make working with AI way better.

First off, it’s like having a lightning-fast pair programmer that’s too eager. If I toss it a vague problem, it’ll start coding before I finish explaining — and sometimes that means building things I never asked for. So I’ve learned to slow it down. I make it explain its approach first, walk me through the plan, and then we code. That step alone has saved me from a ton of rewrites.

Unit tests have become my safety net — not something I ask the AI to write first, but something I rely on to keep both of us honest. They help confirm that what we just built does what I actually intended. It’s a nice loop: I guide the AI, it writes the code, and the tests confirm we stayed aligned.

Another big takeaway: track everything. AI can drift fast if you don’t give it guardrails. I keep a running document of what’s being built — the plan, structure, preferences, naming patterns, things I like and don’t like. Since I switch between Claude CLI and APEX, having that context written down keeps things consistent no matter which AI I’m using that day.

I’ve also realized AI can easily overcomplicate the simple stuff. It’ll throw in abstractions or patterns that don’t fit my workflow. So now I call it out early — “No, we’re keeping this simple,” or “That’s too heavy for what I need.” It listens, adapts, and remembers. Over time, it’s starting to feel like training an assistant to think the way I do.

All in all, AI CLI has changed how I work — but you’ve got to stay in the driver’s seat. The value comes from having a conversation, setting expectations, and building together. And honestly? It’s been pretty great.

From Three Weeks with AI CLI → Starting Fresh: My Next Phase

Josh Tune — Mon, 20 Oct 2025 00:00:00 GMT

It’s been a useful ride. In my previous post, I shared how I’d spent about three weeks using AI CLI tools (mainly Claude CLI and APEX) and learned some key lessons: slow the AI down so it outlines its approach before coding, write unit tests to keep us honest, track everything (plans, preferences, patterns) to keep consistency, and push back when the AI over-abstracts. ([joshtune.com][1]) Now I’m gearing up for the next step — a fresh start, built slice by slice instead of “let’s just go”. Here’s how the next phase is shaping up:

1. Slice by slice, not monolithic

Rather than try to build the whole app in one go (which got me into an unstable state), I’m going to pick a well-defined slice (for example: user management with roles, permissions, sign-up flows). I’ll document the slice’s boundaries, desired features, flows, and edge cases before asking the AI to code. This gives clarity, reduces scope creep, and keeps the AI aligned with exactly what I need.

2. The AI writes the rubric first

I’ve found that when I ask the AI to draft a rubric or outline best-practice approach (what patterns to use, what pitfalls to avoid, what architecture fits this slice) — and then ask for code — the output is dramatically better. It means the AI does a kind of research-and-plan step, I review and refine, and then we build. In effect I’m using the AI as a co-designer/research-assistant, not just a code-machine.

3. Reinforce the tracking habit

I’ll continue maintaining the “living document” of preferences: naming conventions, tech stack decisions, architecture patterns, things I like / dislike. But this time it will be tied to each slice. For example: “For user-management slice: use role-based access, no heavy abstraction, simple REST endpoints, unit tests for each endpoint.” This keeps context clean, consistent, and easier to manage as the app grows.

4. Stay in the driver’s seat

The core insight hasn’t changed: the AI is powerful, but it’s not autopilot. It’s a conversation partner. I set expectations, define the boundaries, review the plan, and approve what moves forward. Holding the reins = better results.

What I hope to achieve

A more stable, maintainable app architecture
Faster iteration because each slice is small and bounded
Higher code quality via upfront planning + research
More predictable outcomes instead of “AI went off in a random direction”

Thanks for reading — if you’re using AI CLI tools too (or thinking of it), I hope these next-phase lessons help. I’ll share updates as I scoop through the slices and we’ll see how it goes.

The Next Phase Didn’t Become a New Project — It Became lehi31.com

Josh Tune — Mon, 05 Jan 2026 00:00:00 GMT

In my last post, From Three Weeks with AI CLI to Starting Fresh: My Next Phase, I talked about stepping back, resetting expectations, and moving toward a more deliberate, slice-by-slice way of working with AI tools.

I expected that “next phase” to start with a brand-new project.

That didn’t happen.

Instead, I went deep on lehi31.com — a real site, with real users, real constraints, and zero tolerance for breaking things just to experiment.

And honestly? That turned out to be the more important next step.

The Reality: Shipping Instead of Starting

Rather than spinning up something new, I spent the last stretch doing unglamorous but meaningful work:

polishing existing features
hardening permissions and auth
fixing edge cases users actually hit
improving navigation, layout, and admin UX
turning half-finished ideas into complete, survivable features

None of this fits neatly into a “new project” announcement — but all of it made the product better.

What actually shipped

Here's the high-level view:

Area	What changed	Why it mattered
Recurring events	Repeat logic, excluded dates, safer deletes, week/month grouping	Calendar became something you can trust
Permissions & roles	DB migrations, RLS fixes, UI reflecting real permission state	Fewer “why can I see this?” moments
Auth & user management	Session expiry, password reset, email verification, Resend switch	Site became operable for real users
Navigation & layout	Hierarchy cleanup, mobile breakpoints, max-width constraints	Feels like a coherent tool, not a pile of pages
Challenges & goals	Filtering, archive safety, root-only destructive actions	Learned what sticks, cut what doesn't

The details below tell the full story.

Recurring Events Became a Real Feature

Recurring events moved from “mostly works” to intentionally designed:

planned and refactored repeat logic
migrations for excluded dates
safer update and delete behavior
protections against accidental deletes
collapsing and grouping events by week/month
clone-to-past-events flows
unit tests around deletion edge cases

This wasn’t flashy, but it was foundational. The calendar is now something you can trust.

Permissions and Roles Grew Up

A big chunk of work went into pulling permissions out of ad-hoc app logic and into the database, where they belong:

backend migrations for roles
RLS fixes
UI updates to reflect real permission state
removing feature flags that were no longer serving a purpose

That shift alone made the admin surface calmer and more predictable — fewer “why can I see this?” moments.

Auth and User Management Became Operable

This is the kind of work you only appreciate once users rely on your app:

session expiry logout handling
admin/manage users UI
password reset without third-party gymnastics
email verification fixes and tests
switching from SendGrid to Resend to simplify email flows
fixing permission caching issues between DB and local state

None of this is exciting in isolation. Together, it makes the site run.

Navigation and Layout Got the Attention It Needed

I also spent time on things that don’t show up in commit stats but absolutely show up in daily use:

navigation hierarchy cleanup
clearer page separation (lesson schedules, assignments, etc.)
mobile breakpoints that actually work
more fluid desktop layouts
max-width constraints that make content readable

The site feels less like a collection of pages and more like a coherent tool now.

Challenges, Goals, and the “Actual Product Surface”

Features like goals, temple tracking, and the BOM reading challenge evolved rapidly:

filtering to show only relevant/current items
archive and delete safety rules
root-only destructive actions
anonymous posting fixes
iterating on what deserved its own page vs living on the home view

Some things were added. Some were simplified. One page was removed entirely.

That’s real product work: learning what sticks and cutting what doesn’t.

What This Taught Me About AI-Assisted Development

This phase still validated the ideas from my last post — just in a different way than I expected.

Slice-by-slice still works, but the slices weren’t new features — they were production hardening tasks.
AI helped most with small, bounded changes, reasoning through edge cases, and keeping momentum during boring work.
The win wasn’t “look how much code I generated.” The win was shipping safely, repeatedly, without burning out or breaking users.

In other words: the tooling mattered less than the discipline.

What’s Next

Because of this work, lehi31.com is now in a place where:

new features are easier to add
permissions are predictable
auth flows don’t require fear
UI changes don’t cascade into chaos

That’s a better foundation than any half-finished new project would’ve been.

When I do start something fresh again, it’ll be because there’s a clear slice worth building, not just because it feels like the “next thing” I should do.

If the last post was about resetting expectations, this one is about accepting reality:

Sometimes the next phase isn’t starting over. Sometimes it’s finishing what actually matters.

Markdownify MCP: Turn (Almost) Anything Into Markdown

Josh Tune — Fri, 09 Jan 2026 00:00:00 GMT

If you’re building an AI-assisted workflow, you eventually hit the same wall: your inputs aren’t Markdown.

That’s why I’m a big fan of markdownify-mcp by @zcaceres: it’s a Model Context Protocol (MCP) server that exposes a set of “convert this thing into Markdown” tools.

Summary (Highlights)

Converts common formats to Markdown: PDF, images, audio (with transcription), DOCX, XLSX, PPTX
Converts web content to Markdown: web pages, YouTube transcripts, Bing search results
Also includes a handy “read a Markdown file” tool (get-markdown-file) for pulling existing notes into context

Why this is so useful

The magic is how it fits into a bigger workflow:

Ingestion: take “messy” sources (slides, PDFs, screenshots, recordings) and normalize them into Markdown
Processing: summarize, tag, outline, or extract action items with your LLM of choice
Sharing: Markdown is the sweet spot for portability (GitHub, Obsidian, docs, wikis, PR descriptions)

In other words: it’s a small tool that removes a big source of friction.

A few “this immediately helps me” use cases

Turn a slide deck (.pptx) into Markdown notes I can actually search and edit
Extract text + metadata from images/screenshots, then generate alt text or a write-up
Grab a YouTube transcript and turn it into an outline, summary, or study notes
Transcribe a short audio memo and convert it into a TODO list

Quick start (from the repo)

git clone https://github.com/zcaceres/markdownify-mcp
cd markdownify-mcp
pnpm install
pnpm run build
pnpm start

The repo notes that this will also install uv and related Python dependencies.

Wiring it up in an MCP desktop app

The README includes an example config like this:

{
  "mcpServers": {
    "markdownify": {
      "command": "node",
      "args": [
        "{ABSOLUTE PATH TO FILE HERE}/dist/index.js"
      ],
      "env": {
        "UV_PATH": "/path/to/uv"
      }
    }
  }
}

One tiny caveat

The project is actively evolving; there’s even a request for help testing Windows support. If you’re on Windows and can validate a PR, you could help move it forward.

Go check it out

Repo: https://github.com/zcaceres/markdownify-mcp

If you like the idea of “turn everything into Markdown,” this is absolutely worth a star.

Vibe Kanban: I’m a Fan

Josh Tune — Fri, 09 Jan 2026 00:00:00 GMT

I’ve been using Vibe Kanban lately, and it clicked fast. This post is a live example: I made a card (“write a quick blog entry”), then iterated until it sounded like me.

What I like is the combo of simple structure + AI help:

Capture intent as a card, not a vague mental note.
Break work into small, finishable slices.
Make tradeoffs obvious by keeping the board honest.
Use AI to turn “I want this” into steps and a first draft, without giving up control.

It’s been a nice little amplifier for writing, refactors, automations, and docs — basically anything that benefits from momentum and clarity.

A coworker also pointed me at Steve Yegge’s Gastown, which seems to rhyme with the same idea: give work a concrete shape and keep the feedback loop tight.

Anyway: I’m a fan. If you want a lightweight way to stay oriented and ship more reliably, give Vibe Kanban a look.

Spec Kit: Spec-driven development for AI-assisted coding

Josh Tune — Sat, 10 Jan 2026 00:00:00 GMT

I’ve been watching the “AI coding agent” space explode: faster scaffolds, faster refactors, faster everything. The downside is also obvious: when you move fast, you can end up with a pile of code that kind of works but doesn’t match what you actually meant.

That’s why GitHub’s Spec Kit caught my eye.

Quick note: I haven’t personally tried Spec Kit yet — these are my notes based on what I’m hearing (and what I watched a coworker do with it).

Spec Kit is an open source toolkit that pushes you toward spec-driven development: write down what you want, why you want it, and the constraints you care about — and then let an agent implement from that spec instead of guessing from a vague prompt.

Repo: https://github.com/github/spec-kit
Docs: https://github.github.io/spec-kit/

The moment it clicked for me

A coworker of mine used Spec Kit on a POC project and the “shape” of the work looked different right away:

Less back-and-forth about what we meant
Fewer surprise abstractions
More predictable output across multiple agent runs

The punchline: when the intent is captured in a spec, the agent doesn’t have to invent it.

The Spec Kit workflow (high level)

Spec Kit’s “happy path” looks like:

Establish your project principles (“constitution”)
Describe what you want to build (the spec)
Convert it into a technical plan (stack + architecture)
Break the plan into tasks
Implement the tasks

If you’ve used agents before, you’ll recognize the steps — the difference is Spec Kit makes them explicit and repeatable.

A concrete example (mocked)

Here’s the kind of prompt sequence that makes Spec Kit feel powerful. You don’t start with “write me code”. You start with constraints and outcomes.

1) Create a constitution

This is the part most teams skip, and it’s the part that saves you later.

Example:

/speckit.constitution
Create principles focused on: readable code, tests for critical paths, predictable UX, and performance budgets.

What I’d put in here (for my own projects):

Prefer boring solutions over clever ones
Tests for core flows before shipping
Small PRs, no huge rewrites
Explicit error handling and observability

2) Specify the feature (the “what” and “why”)

Example:

/speckit.specify
Build a feature that lets users share a read-only link to a board. The link expires after 7 days. Viewers cannot see private boards. Include analytics for link creation and link visits.

This is where you define outcomes, boundaries, and edge cases. If you do it here, you don’t have to fight the agent later.

3) Provide a technical plan (the “how”)

Example:

/speckit.plan
Use Postgres for storage. Use server-rendered pages for the share view. Use signed URLs with an expiry claim. Track events via our existing analytics client.

4) Generate tasks, then implement

Example:

/speckit.tasks
/speckit.implement

Now the agent is implementing against your constraints, not improvising them.

What I like about Spec Kit

It turns “agent prompting” into an artifact. The spec and plan become part of the project’s memory.
It reduces drift. If you rerun the agent later, you’re not starting from scratch.
It makes reviews easier. You can review intent (spec) separately from execution (implementation).

Where it might not fit

I don’t think Spec Kit is necessary for every change. If I’m renaming a variable or tweaking CSS, I don’t need a constitution and a task list.

But for:

New features
Cross-cutting refactors
Anything that spans backend + frontend
Anything where requirements are “obvious in someone’s head” but not written down

…this is exactly the kind of structure that keeps an agent from going off the rails.

If you want to try it

From the Spec Kit README, you can install the specify CLI with uv:

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git

Then initialize a project and pick an agent:

specify init . --ai codex

(That --ai codex bit is particularly nice: Spec Kit explicitly supports multiple agents, so you can keep your workflow consistent even if the tools change.)

Closing thought

My coworker’s use of Spec Kit made something really clear: the bottleneck isn’t writing code anymore — it’s capturing intent.

Spec Kit is a good forcing function for that. And if you’re already building with agents, it’s one of the most practical ways I’ve seen to get “speed” without losing “clarity”.

Living Like This: How Top Developers Work with AI Coding Assistants

Josh Tune — Fri, 16 Jan 2026 00:00:00 GMT

Based on this video. My notes on becoming a better developer with AI assistants.

You're probably leaving most of your AI coding assistant's potential on the table. Not because the tools aren't powerful—they are. But because you don't have a system.

The core principle: AI output quality = context quality. Everything below serves this.

1. PRD-First Development

What it is: A single markdown document defining your entire project scope—your north star.

What goes in:

Target users & mission statement
What's in scope / out of scope (be explicit)
Tech stack & architecture decisions
Feature list with priorities
Non-functional requirements (performance, security)

Implementation:

Create a /create-prd command in .claude/commands/create-prd.md:

# Create PRD Command

Based on our conversation, generate a PRD at `docs/prd.md` with:

## Project Overview

- Target users
- Mission statement
- Success metrics

## Scope

- In scope: [explicit list]
- Out of scope: [what we're NOT building]

## Architecture

- Tech stack with rationale
- Key architectural decisions
- Third-party services

## Features

Priority-ordered feature list with descriptions

## Technical Constraints

- Performance requirements
- Security requirements
- Browser/platform support

The workflow:

Discuss what you want to build with your AI
Run /create-prd to generate docs/prd.md
Review and refine the PRD
Daily question: "Based on the PRD, what should we build next?"
Update PRD as project evolves

Why it works: Your AI understands the bigger picture. Features connect. Context accumulates instead of getting lost. When your AI reads the PRD before planning, it makes decisions aligned with your overall vision—not just the immediate task.

2. Modular Rules Architecture

The problem: Most global rules files are too long. Every word loads into every conversation, wasting context.

The solution: Keep global rules short. Load task-specific rules only when needed.

Global rules structure (.claude/claude.md):

# Project Rules

## Tech Stack

- Frontend: React + TypeScript + Vite
- Backend: Node.js + Express
- Database: PostgreSQL
- Deployment: Vercel + Railway

## Project Structure

/src
/components
/api
/lib
/types

## Core Commands

- npm run dev - Start dev server
- npm test - Run tests
- npm run build - Production build

## Code Conventions

- Use named exports
- Prefer const over let
- TypeScript strict mode
- ESLint + Prettier

## Reference Documentation

When working on specific tasks, read these:

- API Development: `.claude/reference/api-development.md`
- Frontend Components: `.claude/reference/frontend-components.md`
- Database: `.claude/reference/database.md`
- Deployment: `.claude/reference/deployment.md`

Task-specific reference (.claude/reference/api-development.md):

# API Development Reference

## Endpoint Structure

All endpoints in `/src/api/routes/`

## Error Handling

- Use custom ApiError class
- Return consistent error shapes:
  { error: string, code: string, details?: object }

## Validation

- Zod schemas for request validation
- Validate at route handler entry

## Authentication

- JWT tokens via middleware
- Extract user from req.user
- Use requireAuth() middleware

## Testing

- Supertest for integration tests
- Mock external services
- Test error cases

Implementation steps:

Create .claude/ directory in your project root
Write short global rules (< 200 lines)
Create .claude/reference/ directory
Split specialized knowledge into reference docs (can be 500-1000+ lines each)
Reference them in global rules

Why it works: Your AI gets comprehensive context without overwhelming the context window. A 200-line global rules file + 800-line API reference (loaded only when needed) beats a 2,000-line rules file that wastes tokens on frontend conventions when you're building APIs.

3. Commandify Everything

The rule: Prompt something twice? Make it a command.

Essential commands to create:

/prime - Load project context
/create-prd - Generate PRD
/create-plan - Output structured plan
/execute - Implement from plan
/commit - Git commit with proper message
/review - Code review checklist

Example: The Prime Command (.claude/commands/prime.md):

# Prime Command

Load context needed to start working:

1. Read PRD at `docs/prd.md`
2. Review recent commits: `git log -10 --oneline`
3. Check current status: `git status`
4. Read global rules at `.claude/claude.md`
5. Scan project structure
6. Identify blocking issues or incomplete work

Output a summary:

- **Current state:** Brief project status
- **Recent changes:** What was done recently
- **From PRD:** What we're working toward
- **Suggested next steps:** Based on PRD priorities

Example: The Plan Command (.claude/commands/create-plan.md):

# Create Plan Command

Generate a structured plan at `docs/plans/[feature-name].md`:

## Feature Overview

- Feature name
- User story
- Success criteria

## Technical Approach

- Architecture decisions
- Files to create/modify
- Dependencies needed

## Implementation Tasks

1. [Specific task 1]
2. [Specific task 2]
   ...

## Testing Strategy

- Unit tests to write
- Integration tests
- Manual testing steps

## Validation Checklist

- [ ] Tests passing
- [ ] Linting clean
- [ ] Types valid
- [ ] Manual testing complete

Implementation:

Create .claude/commands/ directory
Add one command at a time (start with /prime)
Test and refine each command
Build your command library over 2-3 weeks

One command replaces 5-10 minutes of setup. Saves thousands of keystrokes over time.

Get started: Check out the Habit Tracker repo with all command templates.

4. The Context Reset

The pattern: Always restart your conversation between planning and execution.

Why: Planning is exploratory—full of dead ends, tangents, and options you rejected. If you go straight from planning to coding, all that noise pollutes the context window. Your AI has less room to reason about implementation.

Planning phase:

/prime - Load project context
"Based on PRD, what's next?" - Discuss options
Read relevant code, explore approaches
/create-plan - Output to docs/plans/feature.md

[Clear context - close conversation or run /clear]

Execution phase:

New conversation
/execute docs/plans/feature.md
AI reads ONLY the plan (not the messy planning conversation)
Clean context = focused implementation

The execute command structure:

# Execute Command

Implement the plan at the specified path.

1. Read the plan document
2. Understand all tasks and acceptance criteria
3. For each task:
   - Implement the change
   - Write tests
   - Run validation
4. After all tasks:
   - Run full test suite
   - Check linting
   - Verify types
   - Manual smoke test
5. Report any issues or deviations from plan

Why it works: The plan contains everything needed (what to build, how to build it, files to change, tests to write). The planning conversation contained everything NOT needed (rejected ideas, exploratory reading, dead ends). Separating them gives your AI maximum reasoning space.

5. System Evolution Mindset

The insight: Every bug is an opportunity to strengthen your AI.

Wrong approach:

Find bug → fix manually → move on → same bug next week

Right approach:

Find bug → "What in my rules/commands allowed this?" → Fix the system → Never happens again

Implementation workflow:

After completing a feature and finding issues:

Document what went wrong

Issues found:
- AI used `require()` instead of `import`
- Forgot to run linter before committing
- Didn't update tests in `/tests/api/`
- Validation logic had edge case bug

Start reflection conversation

I noticed these issues after implementation. Let's review:
- The rules in `.claude/claude.md`
- The commands we used: `/create-plan` and `/execute`
- The plan document at `docs/plans/feature.md`

What should we improve so these issues don't happen again?

Let AI propose fixes AI might suggest:
- Add import rule to global rules
- Update /execute command to include linting step
- Add test update requirement to plan template
- Create validation reference doc
Implement improvements Update your system files based on suggestions
Validate next feature Those issues shouldn't recur

Common fix patterns:

Problem	System Fix
Wrong import style	Add one-line rule in global rules
Forgets tests	Add "Tests" section to plan template
Doesn't understand auth	Create `reference/authentication.md`
Skips validation	Add validation steps to `/execute` command
Inconsistent error handling	Create `reference/error-handling.md`
Doesn't run linter	Add linting to `/execute` validation steps
Misunderstands architecture	Expand PRD architecture section
Hardcodes values	Add "No magic numbers" to code conventions

Why it compounds:

Week 1: 20 mistake types
Week 4: 10 mistake types
Week 8: 5 mistake types
Week 16: Rarely new mistakes

Your AI gets more reliable every day. The model didn't improve — your system did.

The mindset shift:

From: "This AI is unreliable, I have to fix everything"
To: "This bug reveals a gap in my system, let me close that gap"

One is frustrating. The other is empowering and compounds.

The Daily Workflow

Morning:

/prime - Load project context
"Based on PRD, what's next?" - Get direction
Discuss and explore approaches
/create-plan - Output structured plan

[Context reset - close conversation]

Implementation:

New conversation
/execute docs/plans/feature.md - Clean execution
Build the feature with clean context
Validate manually after implementation
Note any issues

System Evolution:

Document problems encountered
"Let's improve the system to prevent these issues"
Update rules, commands, or reference docs
Commit system improvements

Repeat:

Each cycle: stronger system, more reliable AI, faster shipping.

The Meta-Lesson

All five techniques manage context strategically:

PRD = north star context (what we're building)
Modular rules = just-in-time context (how we build it)
Commands = process context (repeatable workflows)
Context resets = eliminate noise (clean slate for execution)
System evolution = improve context quality (compound over time)

Master context management = master AI-assisted development.

Start Here

Don't implement everything at once. Ramp up over 5 weeks:

Week 1: Create PRD + prime command Week 2: Add plan/execute workflow + context resets Week 3: Commandify common prompts (commit, review) Week 4: Start system evolution after each feature Week 5: Implement modular rules architecture

By week 6, the difference is obvious.

Resources

Video: Watch the full video for detailed examples
Course: Dynamous Agentic Coding Course - Full system for reliable AI coding
GitHub Repo: Habit Tracker with all commands - Command templates and examples
Workflow Diagram: Visual system overview

All credit to the video creator for these techniques. This is my condensed reference—watch the original for the complete system.

MCP in Front of APIs: What That Means (and Why It Matters)

Josh Tune — Fri, 16 Jan 2026 00:00:00 GMT

There’s a phrase you’ll hear a lot right now in companies adopting AI assistants: “We should put MCP in front of our APIs.”

If you translate it into plain English, it usually means:

“Let’s create a standard, governable layer that exposes our systems as AI-usable tools, so any MCP-capable assistant can safely call them.”

This post breaks down what that means for you day-to-day as a developer, and what it implies for software development more broadly.

The 30-second version

MCP (Model Context Protocol) is a standard way for an AI app to discover and call “tools” provided by a server (plus access “resources” like files/data).
Putting MCP “in front of APIs” means wrapping existing HTTP/gRPC/GraphQL endpoints behind an MCP server (or MCP gateway) so assistants can use them consistently.
The “big deal” is less about the protocol and more about standardizing AI-to-system integration: auth, policy, auditing, safety controls, and tool design.

What MCP is (in practical terms)

MCP is a protocol that lets an AI-enabled client (an assistant, IDE, or agent runner) connect to one or more MCP servers that provide:

Tools: functions the assistant can call (capabilities with arguments + structured outputs)
Resources: things the assistant can read (and sometimes write), like documents, records, or indexes
Prompts/templates: reusable guidance the client can pull from the server

In practice, MCP becomes the “plug shape” for integrating assistants with real systems.

What “MCP in front of APIs” usually means architecturally

Most orgs land on one of these patterns (or a mix):

1) “Adapter” MCP servers (per domain/system)

Each key system gets an MCP server that translates MCP tool calls into API calls:

jira-mcp exposes create_issue, search_issues, add_comment
billing-mcp exposes get_invoice, refund_payment
crm-mcp exposes lookup_customer, update_contact

This tends to work well when teams own their domain and can evolve tools alongside APIs.

2) An “MCP gateway” (centralized front door)

A shared team builds a gateway that:

publishes a curated set of tools across multiple backends
handles auth, policy, logging, throttling, approvals
maps “assistant-friendly” tool shapes to messy internal endpoints

This can reduce duplication, but it also becomes a platform that needs clear ownership.

3) MCP as a policy layer on top of an API gateway

Some teams already have API gateways (Kong, Apigee, Envoy, etc.). In that world, MCP is often an extra layer that focuses on:

tool discovery, schema, and responses optimized for LLM usage
assistant-specific controls (human approvals, scoped credentials, audit trails by “assistant session”)
safety constraints (redaction, filtering, allowlists) that are distinct from normal API consumers

What it means for you as a developer

You’ll design tools, not just endpoints

APIs for humans (or normal services) can be “generic and composable.” Tools for assistants should be:

narrow and high-signal: fewer “do anything” parameters, more purpose-built actions
hard to misuse: guardrails in the schema; limited free-form text
idempotent when possible: safe retries and clear “already done” semantics
explicit about side effects: a tool that changes state should say so in its name and description

One good mental model: your tool schema is part of your UX—except your “user” is an LLM.

You’ll care more about “how the model fails”

With normal API consumers, errors mostly hit logs and dashboards. With AI tool-calling, errors often become:

repeated retries (sometimes with slightly mutated inputs)
partial plans that keep going after a failure
confusing user experiences if the assistant can’t explain what happened

So you’ll end up investing more in:

stable error shapes (machine-readable codes + human-readable summaries)
safe defaults and constraints
clear return values that help the assistant decide the next action

You’ll build “AI integration tests”

If your org leans into agents, you may be asked to validate flows like:

“Can the assistant create a ticket, attach logs, and notify a channel?”
“Can it fetch the right customer record without overfetching data?”
“Can it refuse unsafe actions unless an approval step is present?”

That’s less like unit testing and more like contract testing plus workflow simulation.

You’ll spend time on governance plumbing (even if you don’t want to)

When tools can touch real systems, questions show up fast:

Who is the “caller”? The end user, the assistant, a service account?
What permissions does the tool run with? How is least-privilege enforced?
How do we audit “assistant performed action X because user asked Y”?
How do we prevent data leaks into the model context or logs?

As a developer, expect to partner more with security, platform, and compliance teams.

What it means for software development (the bigger shift)

APIs become “AI-addressable”

Historically, we built APIs for:

UI clients
other services
partners

Now there’s a new consumer: LLM-driven tool use. That shifts emphasis toward:

discoverability (what can this system do?)
constrained interaction (what should it be allowed to do?)
provenance (who asked, what was the justification, what changed?)

“Natural language” becomes a coordination layer, not a transport

The point isn’t that we’ll replace APIs with natural language.

The point is that natural language becomes the orchestration surface:

a user expresses intent (“refund the last invoice and email the receipt”)
the assistant plans the work
MCP tools are the “mechanical” interface for doing it safely

The work still happens via structured calls—MCP just standardizes the way assistants reach those calls.

Tool ecosystems start to look like package ecosystems

If MCP (or anything like it) becomes a common integration standard, you’ll see patterns that feel familiar:

internal “tool registries”
versioning and deprecation policies (tool names and schemas become contracts)
shared libraries for auth, logging, and schema validation
reusable “golden” tools that teams prefer over bespoke wrappers

In other words: platform engineering, but for tool interfaces.

The hard parts (what your workplace will debate)

Security: prompt injection and data exfiltration

If an assistant reads untrusted text (tickets, emails, web pages), that text can try to influence tool calls (“ignore your rules, run this dangerous action…”).

Mitigations usually include:

tool allowlists and strong auth (never “just let it call anything”)
approval workflows for sensitive actions
output filtering/redaction and strict logging controls
minimizing tools that accept unconstrained free-form instructions

“Scope creep” tools

Tools that look like run_sql(query) or call_api(url, method, body) are tempting because they’re powerful—but they’re also:

hard to secure
hard to audit
easy to prompt-inject
likely to turn into an implicit backdoor

Many orgs end up preferring specific, well-named tools over generic supertools.

Ownership and change management

Once assistants depend on a tool’s schema, “tiny breaking changes” stop being tiny.

You’ll want conventions like:

tool versioning or additive changes only
deprecation windows
contract tests for tool schemas
strong observability (which tools are used, by whom, and how often)

How to evaluate “MCP in front of our APIs” at work

Here are questions that quickly clarify whether the idea is serious engineering or just hype:

Who is the MCP client? (IDE? internal agent runner? Chat UI? multiple?)
Where does auth live? (per-user OAuth? service accounts? short-lived tokens?)
What’s the approval model for side effects? (human-in-the-loop? limits?)
What is the audit story? (trace from user prompt → tool call → backend request → data change)
What’s the blast radius? (tool allowlists by environment; read-only by default)
How do we prevent overexposure? (least privilege + “only return what’s needed”)
How do we ship changes safely? (schema compatibility, staged rollout, monitoring)

A pragmatic takeaway

If your company is serious about agents, “MCP in front of APIs” is basically a bet that:

assistant integrations should be standardized (not one-off prompt glue)
tool access should be governed (not a pile of ad-hoc scripts)
platform teams should provide a safe, reusable interface to internal systems

As a developer, that’s both an opportunity (better leverage, fewer brittle integrations) and a responsibility (tool design, safety, and change management become part of the job).

Git Worktree: Pros, Cons, and the Gotchas Worth Knowing

Josh Tune — Sun, 18 Jan 2026 00:00:00 GMT

git worktree is a Git feature that lets you check out multiple branches at the same time, each in its own folder, without making multiple full clones.

If you’ve ever been mid-change and needed to quickly fix something on another branch (or you’re juggling a post draft + site tweaks), worktrees are a clean way to keep momentum without stashing or context-switching your entire working directory.

The idea (in one paragraph)

A normal repo has one working directory attached to your .git. With worktrees, you keep the same underlying repo data, but Git gives you extra working directories—each with its own checked-out branch/commit and its own index—while sharing the same object database.

When worktrees shine

Writing a blog post on a branch while keeping main ready to deploy.
Working on two features in parallel without constantly switching branches.
Running side-by-side comparisons (two builds, two configs, two versions).
Reviewing a PR locally while still coding elsewhere.

The pros

1) Parallel branches without `stash` gymnastics

You can have main open in one folder and a post branch open in another. No “stash, checkout, pop, resolve conflicts, repeat.”

2) Faster and smaller than multiple clones

Worktrees share the object database, so you typically avoid the cost of re-downloading history for each “copy” of the repo.

3) Cleaner mental model for focused work

Each folder can represent one “thing” you’re doing. It’s a simple way to keep your working directory honest.

The cons (and what to watch for)

1) More folders = more confusion

You now have multiple directories that look like “the repo.” It’s easy to edit in the wrong one, run scripts in the wrong one, or wonder why changes “didn’t apply.”

2) Disk usage can still grow

While Git objects are shared, your dependencies and build artifacts often aren’t.

node_modules/ (or pnpm/npm caches) might exist per worktree.
Framework caches can balloon quietly.

If your workflow is dependency-heavy, consider a strategy that avoids reinstalling dependencies per worktree (or accept the tradeoff and prune aggressively).

3) Some tooling assumes one working directory

Editors, language servers, file watchers, and dev servers can get weird when you run multiple instances pointing at the same shared repo metadata. Usually it’s fine—until it isn’t.

4) There are a few “Git rules” you’ll hit immediately

A branch can only be checked out in one worktree at a time.
You can’t delete a branch that’s checked out in any worktree.
Deleting/moving the folder manually can leave stale worktree references.

Gotchas and how to avoid them

Don’t delete worktree folders by hand

Use Git to remove worktrees, then prune stale entries:

git worktree remove <path>
git worktree prune

Know what’s shared vs per-worktree

Shared: the Git object database (history, blobs, etc.)
Per-worktree: the working directory and index (staged changes)

That’s why worktrees feel “separate,” but also why they can still trip each other up if you treat them like fully independent clones.

Submodules and setup steps repeat

If your repo uses submodules or expects one-time setup, you may need to run those steps per worktree.

My favorite pattern: one worktree per “thread of work”

Here’s a simple setup that keeps main clean while you write:

# from your main checkout
git fetch
git worktree add ../site-post-git-worktree -b post/git-worktree-pros-cons

Now you have:

./ → your normal checkout (keep it on main)
../site-post-git-worktree → the post branch checkout

When you’re done:

git worktree remove ../site-post-git-worktree
git branch -d post/git-worktree-pros-cons

A handy helper: git-worktree-runner

If you like the worktree workflow but want less manual repetition, check out git-worktree-runner. It’s a small helper for running commands across your worktrees (useful when you want to update deps, run builds, or verify things in multiple branches at once).

The quick decision rule

Use worktrees when you want parallel focus (two branches at once) and you’re okay managing multiple folders. Skip them if your tooling or dependency setup gets messy with duplicate installs.

If you haven’t tried them before, use one for something small (like a blog post) and see how it feels in your day-to-day flow.

Three UI Frameworks Walk Into a Svelte Project

Josh Tune — Thu, 29 Jan 2026 00:00:00 GMT

I've been looking at UI frameworks lately, specifically ones that play well with Svelte. Three caught my attention: shadcn-svelte, Skeleton, and DaisyUI. They all solve the "I need decent-looking components" problem, but they approach it very differently.

Here's how they stack up.

The quick version

	shadcn-svelte	Skeleton	DaisyUI
Approach	Copy components into your project	Install as dependency	Tailwind plugin
Svelte-first	Yes	Yes (also React, Vue, etc.)	Framework-agnostic
JavaScript	Yes, Svelte components	Yes, uses Zag.js	No, pure CSS
Ownership	You own the code	Library owns the code	Plugin owns the styles
Customization	Edit source directly	Theme system + Tailwind	Tailwind utilities + themes
Learning curve	Moderate	Moderate	Low

shadcn-svelte: Own your components

shadcn-svelte is the Svelte port of the popular shadcn/ui. The philosophy is different from typical component libraries: instead of installing a package and importing from it, you copy the component source code directly into your project.

This sounds weird at first. Why would I want to maintain component code myself?

The answer is control. When you need to change how a button behaves or add a prop that the library doesn't support, you just edit the file. No waiting for PRs to merge, no forking the repo, no "hacky workarounds." It's your code.

What I like:

Beautiful defaults based on Radix primitives
Full control over every line of code
Great accessibility out of the box
Active community, good docs

What I don't:

You're responsible for updates (though that's kind of the point)
Initial setup takes longer than npm install
If you want the same component in multiple projects, you're copying files around

Best for: Projects where you know you'll customize heavily, or teams that want complete ownership over their design system.

Skeleton: The batteries-included option

Skeleton calls itself "the adaptive design system for Tailwind CSS." It started as Svelte-first but now supports React, Vue, Solid, and Astro too.

What sets Skeleton apart is how complete it feels. You get a design system, not just components. Typography scales, spacing tokens, color systems, dark mode—it's all thought through and connected. The components use Zag.js under the hood, which handles the gnarly bits like accessibility and internationalization across frameworks.

What I like:

Feels cohesive—everything works together
Great theme system with CSS custom properties
Interactive components handle state properly
Strong TypeScript support
Active development and solid community (5k+ GitHub stars, 2k+ Discord)

What I don't:

More opinionated than the others
Larger footprint if you only need a few components
Cross-framework support means some Svelte-specific patterns feel abstracted away

Best for: Teams building substantial apps who want a complete design system without assembling one from scratch.

DaisyUI: Just add classes

DaisyUI takes a radically different approach. It's a Tailwind plugin that gives you semantic class names for components. No JavaScript. No framework lock-in. Just CSS.

Instead of writing class="px-4 py-2 bg-blue-500 text-white rounded hover:bg-blue-600", you write class="btn btn-primary". DaisyUI claims this reduces class names by 88% and HTML file size by 79%. Whether those numbers hold for your project, the code does get cleaner.

The theme system is impressive—35 built-in themes using CSS variables. Switch from light to dark to cyberpunk with a single attribute change.

What I like:

Zero JavaScript dependency
Works with any framework (or no framework)
65 components covering most needs
Themes are solid and easy to customize
Smallest learning curve of the three

What I don't:

No interactive behavior—you write your own JS for modals, dropdowns, etc.
Less "Svelte-native" feeling
Semantic classes can conflict with existing Tailwind mental models

Best for: Projects where you want clean markup and don't mind wiring up interactions yourself. Great for content sites, landing pages, or when you're already comfortable with vanilla JS/Svelte for behavior.

My take as a Svelte developer

I'm biased toward Svelte, so here's my honest take:

shadcn-svelte feels the most "Svelte-native" because the components are actual .svelte files you own. The patterns feel familiar. If I'm building something custom and want a head start with good defaults, this is where I'd start.

Skeleton is what I'd pick for a team project or larger app. The design system coherence matters when multiple people are building features. It's opinionated, but those opinions are good ones.

DaisyUI is what I'd reach for when I want to move fast and the project is straightforward. Need a marketing site that looks good? DaisyUI + Svelte is hard to beat for speed. Just know you're handling component behavior yourself.

The decision tree

Want full control and Svelte-native patterns? → shadcn-svelte
Want a complete design system with less decisions? → Skeleton
Want to move fast with pure CSS components? → DaisyUI
Building something small and scrappy? → DaisyUI
Building something large with a team? → Skeleton
Building something you'll customize heavily? → shadcn-svelte

There's no wrong answer here. All three are well-maintained, have active communities, and will get the job done. The question is which trade-offs match your project.

The Shift: Building Components for AI, Not Just Browsers

Josh Tune — Thu, 29 Jan 2026 00:00:00 GMT

Something clicked for me recently at work. We've been talking about how we need to think differently about building UI components—not just for users clicking around in browsers, but for AI assistants that need to present data.

It took me a minute to get what that actually means. But once I did, I realized it's the same shift that's happening on the backend, just arriving on the frontend now.

The backend pattern we already know

On the backend, teams are putting MCP servers in front of APIs. You take your existing endpoints and wrap them so AI assistants can discover and call them through a standard protocol. I wrote about this a couple weeks ago.

The frontend version is the same idea: build components that AI can use to present data. If "MCP in front of APIs" is the backend pattern, then "MCP on top of components" is what's coming for the frontend.

What actually changed

For years, I thought about frontend work like this: user does something, app fetches data, my code decides how to render it. I controlled the presentation layer. I picked the components, decided the layout, wired up the interactions.

Now there's a different flow emerging:

	Traditional	AI-enabled
Trigger	User clicks a button	User types what they want
Data	App fetches from API	AI decides what to fetch
Rendering	My code picks the component and layout	AI selects and invokes components
My role	Build the full pipeline	Build good building blocks

User says what they want, AI figures out what data to get, and then AI picks which components to use to show it. The AI is doing the orchestration. My job shifts to giving it good building blocks.

That's the mindset shift. I'm not just building for developers who import my components. I'm building for AI that will select and invoke them at runtime.

Where I'm seeing this show up

MCP now has an extension for interactive UI. When an assistant calls a tool, it can return actual components—charts, forms, dashboards—not just text. Shopify built commerce components (product cards, cart flows) that AI agents can embed directly in conversations. Even shadcn/ui and Material UI ship with MCP server support now, so AI can query the docs and generate code that uses them correctly.

The pattern is: your component library becomes an API that AI consumes.

What this means for how I build things

I've been thinking about a few things differently:

Clearer contracts. If an AI is going to pick my component, the props and behaviors need to be obvious. Not "flexible and powerful" but "predictable and hard to misuse." Kitchen-sink components with 50 optional props are a nightmare for AI to use correctly.

Intent over interaction. I used to think about what the user clicks. Now I think about what the user wants to accomplish. A product card doesn't need complex event handlers for AI—it just needs to say "this shows a product and can emit an add-to-cart intent."

Self-contained enough to embed anywhere. If a component might render in a sandboxed iframe inside a chat interface, it can't assume much about its host environment.

Is this actually new?

Yes and no. Design systems and component libraries have been around forever. What's new is exposing those same primitives through protocols that let AI discover and invoke them. The components become tools in the MCP sense—functions with schemas and descriptions.

It's an evolution, not a revolution. But it does change how I think about what I'm building and who (or what) is going to use it.

The practical bit

If you're building components today, it's worth asking: Can an AI understand what this does? Can it invoke it correctly with sensible defaults? Does it communicate intent clearly? Could it render in an unfamiliar host?

We're not replacing frontend development. We're adding a new consumer. And that consumer has different needs than the developers who used to be our only audience.

I'm still figuring this out, but the shift feels real. It's changing how I think about the work.

Does AI Gibberish Code Matter More Than Functionality?

Josh Tune — Wed, 25 Feb 2026 00:00:00 GMT

I keep hearing the same complaint about AI pair programmers: “It works, but it’s gibberish.” The functions compile, the tests pass, yet the repo slowly fills with mystery helpers and odd shortcuts. So what counts more: how the code reads or what it delivers? Here are both angles — and where I landed.

Why the model still writes nonsense

My repos are full of helpers named things like handleItRealQuick because I let models scaffold at 2× speed. When I dig into the diff, the same reasons pop up:

Remix mode. Models mash bits of code that often appear together, so you get cargo-cult layers unless you steer them hard.
Thin context. I rarely paste more than a slice of the repo, so the model fills gaps with made-up abstractions.
No pain loop. I learn from on-call nights; the model never does. Without tight review gates, it keeps repeating the same oddities.

So yes, “gibberish” fits. The better question is when it’s a blocker versus just background noise.

When the mess costs more than it helps

Rotating ownership. If another team inherits the module next quarter, I want boring, obvious code—not AI poems.
Audits. Regulators don’t care that “tests passed.” Someone has to explain what’s happening line by line.
Shared libraries. Core utilities spread everywhere. If they’re weird, every feature inherits the weirdness.
On-call nights. At 3 a.m., clear intent saves more time than cleverness ever will.

In these spots I slow down, regenerate, or just rewrite it myself.

When I let the gibberish ride

Spikes and prototypes. I care more about learning fast than naming things perfectly.
Migration shims. If the code dies after a cutover, I’ll tolerate the mess.
Tiny teams. Sometimes shipping something slightly ugly keeps the roadmap moving.
Agent-only glue. If humans never touch it and the pipeline can regen it safely, entropy is fine.

In those cases the “burn it down, it’s ugly” take just slows momentum.

My quick gut check

I run through five fast questions before merging anything AI touched:

Will someone read this monthly or once a year?
Does it outlive the current milestone?
Who gets hurt if it misbehaves?
Could I explain the abstraction in one paragraph?
Would another prompt + style guide get me a cleaner version in under an hour?

If the answers skew low risk, I merge. If they lean high risk, I regenerate or rewrite.

Where I stand

Gibberish matters when it hides risk. Functionality is the ticket in; clarity keeps that feature cheap to own. I’m aiming for practical balance: ship the code that meets the risk bar, flag the spots where clear language is required, and keep teaching the models what “readable here” looks like. Wins come from knowing when mess is acceptable and when it isn’t—not from banning AI slang outright.

AI Has Changed Everything — and Nothing Feels Finished

Josh Tune — Sat, 28 Mar 2026 00:00:00 GMT

Something hit me the other day. I was staring at a Claude Code session — half-built feature, three CLAUDE.md files tuned just right, a custom slash command I'd spent an hour writing — and I thought: this is incredible, and also... are we there yet?

The honest answer is no. But we're close enough that the shape of "there" is visible, and that's the part worth writing about.

The joy is real

I can't overstate how much AI has changed the way I work. I went from writing every line by hand to orchestrating features through conversation. I build things in hours that used to take days. I ship side projects that would've died in my head.

That first time Claude Code scaffolded an entire Supabase schema, wrote the RLS policies, and wired up the frontend — I just sat there. It felt like cheating. It felt like the future arriving on a Tuesday afternoon.

And it keeps compounding. The more I invest in my setup — rules files, PRDs, slash commands, modular context — the better the output gets. Week over week, I'm faster. That feedback loop is addictive.

The stress nobody talks about

But there's a weight that comes with it.

Every week there's a new tool, a new mode, a new way to configure your agent. Claude Code Remote just dropped and my first thought wasn't excitement — it was great, another thing I need to learn and set up before I fall behind.

The configuration tax is real. I spend serious time tuning CLAUDE.md files, writing commands, structuring context, resetting conversations at the right moment. It works — but it's a second job on top of the actual job. And if you skip it, the output quality drops fast.

There's also this low-grade anxiety that the way I'm working right now will be obsolete in three months. I built a whole workflow around context resets and plan-then-execute cycles. What happens when the next model just... doesn't need that?

The confusion

Here's the part I don't see enough people admit: it's confusing.

Not the tools themselves — those I can learn. The confusion is about identity. I've spent years getting good at writing code. Reading a stack trace, refactoring a gnarly function, knowing when an abstraction is worth it — that was the craft. That was what made me me as a developer.

Now the craft is shifting. Writing code by hand is starting to feel like a deprecated art. Not gone — not yet — but the center of gravity is moving. The skill that matters most isn't writing the code anymore. It's knowing what to ask for, how to structure the context, and when to intervene.

Managing agents to build a feature is becoming the job. And I think that's the future. But it's a weird grief to carry — being excited about where things are going while mourning the thing you spent years learning.

It's still not there

Even with all the progress, the cracks show up constantly.

The AI drifts. It hallucinates file paths. It "fixes" things that weren't broken. You hand it a well-structured plan and it still invents abstractions you didn't ask for. You configure everything perfectly and it still surprises you in ways that cost an hour.

Claude Code Remote feels like a glimpse of what's coming — agents running autonomously, executing plans while you sleep. But right now it's early. You configure, you babysit, you iterate on the config. The promise is set it and forget it. The reality is set it and watch it carefully.

I keep pulling off impressive things. But each one requires more setup than I expected. The gap between "this is possible" and "this is easy" is still wide.

Where I think this lands

Despite all that, I'm betting on this direction. Here's why.

Every month, the configuration tax gets a little lower. The models get smarter. The tooling gets better. The patterns stabilize. I'm already doing things that were impossible a year ago — and not just possible now, but routine.

Writing code isn't going away tomorrow. But the ratio is shifting.

import { BarChart } from '~/components/charts'

I used to spend 80% of my time writing code and 20% planning. Now it's closer to the inverse — and that 20% is shrinking.

The developers who thrive in this next phase won't be the ones who write the fastest code. They'll be the ones who give the clearest instructions, build the best context systems, and know when to let the agent run versus when to take the wheel.

That's a different skill set. It's one I'm still building. And some days it's thrilling and some days it's exhausting and most days it's both.

What I keep coming back to

AI has changed everything about how I build software. The speed, the ambition, the scale of what one person can ship — none of that existed a year ago.

But nothing feels finished. The tools outpace the workflows. The workflows outpace the habits. And the habits haven't caught up to the identity shift.

I'm not complaining. I'm just being honest about what it feels like to live through a transition that everyone says is the future while you're still configuring your way through the present.

We'll get there. We're just not there yet.

AI Ships Fast — But Who's Checking the Code?

Josh Tune — Wed, 01 Apr 2026 00:00:00 GMT

I shipped a broken deploy script last week. Not because I wrote bad code — because I didn't write the code. Claude did. And I merged it without reading it carefully enough.

The script worked. It built, it pushed, it deployed. But it was missing a single file — .nojekyll — and that one omission nuked every stylesheet on my site. The whole blog went live looking like raw HTML from 1997.

Here's the thing: AI didn't make a mistake. I made a mistake. I trusted the output without verifying it. And that's the part I keep getting wrong.

The speed problem

AI makes you fast. Dangerously fast.

When Claude scaffolds a feature in three minutes, there's this gravitational pull toward shipping it immediately. The code compiles. The types check. It looks right. So you merge it and move on to the next thing.

But "compiles and looks right" is not the same as "correct." I've merged AI-generated code that passed every lint check and still had a subtle logic bug that didn't surface for days. The code was syntactically perfect and functionally wrong.

Speed is only valuable if what you're shipping actually works. Otherwise you're just accumulating debt faster.

What I actually do now

After getting burned enough times, I've landed on a set of habits that catch most issues before they hit production. Nothing revolutionary — just discipline.

Read the diff, not the file. When AI generates or modifies code, I review the diff, not the final file. The diff shows exactly what changed. It's harder to miss a deleted line or a weird addition when you're looking at deltas instead of the whole file.

Run it locally before pushing. This sounds obvious but I skipped it constantly when I first started using AI tools. The code looked good, the agent said it was done, and I pushed. Now I run the build, hit the feature manually, and check the output. Every time.

Ask "what could this break?" Before merging anything non-trivial, I spend thirty seconds thinking about blast radius. Does this touch auth? Does it change a database schema? Does it modify a deploy pipeline? The higher the blast radius, the slower I go.

Check the edges, not just the happy path. AI is great at the happy path. It'll build you a form that works perfectly — when every field is filled in correctly. But what about empty submissions? Special characters? Network failures? I've learned to specifically ask about edge cases and then verify the answers in the code.

Use the tools you already have. Type checking, linting, tests — these aren't just for human-written code. If anything, they matter more for AI-generated code because the AI doesn't have the intuitive sense of "this feels off" that experienced developers carry. pnpm build catches things that vibes don't.

The verification tax

I know what you're thinking. If I have to verify everything, doesn't that cancel out the speed gains?

No. But it changes where the time goes.

Without AI, I'd spend 80% of my time writing code and 20% reviewing it. With AI, I spend maybe 20% guiding the generation and 40% reviewing it — and the remaining 40% is time I just didn't have before. That's time I now spend on architecture, on testing, on shipping more features.

The verification step isn't a tax. It's the part of the job that was always there — it just used to be invisible because writing and reviewing happened simultaneously in your head.

The practices that compound

The best thing I've done is build verification into my workflow system rather than relying on willpower.

My CLAUDE.md files include validation steps. My slash commands run checks automatically. My deploy pipeline has gates. These aren't optional checklists I heroically remember to follow — they're baked into the process so I can't skip them.

I wrote about system evolution a while back — the idea that every bug should improve your system, not just get fixed. That applies here too. When I find an issue that slipped through, I don't just fix the bug. I ask: what check would have caught this? And then I add that check.

The .nojekyll incident? I now have a mental model for deploy scripts: what files does the target platform expect that aren't in the build output? That question would have caught it in thirty seconds.

Where this is headed

AI-generated code is only going to get better. The models will make fewer mistakes, the tooling will catch more issues, and the verification step will get lighter over time.

But it will never hit zero. There will always be a gap between "the AI produced code" and "this code is correct for my specific context." Closing that gap is the job now. Not writing code — verifying code. Not generating features — validating features.

The developers who ship reliable software with AI won't be the ones who trust it the most. They'll be the ones who built the best systems for catching what it gets wrong.

That's the skill I'm investing in. And honestly, it's making me a better engineer than I was before AI showed up.

The Context Bottleneck

Josh Tune — Thu, 09 Apr 2026 00:00:00 GMT

There's a joke making the rounds that we've reached the age where AI has taken flight — and humans are just the "context bottleneck to productivity."

I laughed the first time I heard it. Then I sat with it for a minute. Then I stopped laughing.

Because the joke lands. I feel it every day. The AI could keep going. It could scaffold the next feature, write the tests, open the PR. But it's waiting on me. Waiting for me to review, approve, clarify, redirect. I'm the slowest part of my own workflow.

I wrote about this shift a few weeks ago — how the ratio flipped from 80% writing code to 80% orchestrating. The code gets written in minutes now. The context transfer takes hours. And that ratio keeps tilting.

This is what the bottleneck looks like in practice — a rules file I maintain so the AI knows how to work in my blog repo:

## Personal Voice (Josh's style)

- Honest about the messy parts — don't sugarcoat
- Short punchy paragraphs — rarely more than 3-4 sentences
- Em dashes for asides — real-time thoughts mid-sentence
- Forward-looking close — end with where things are headed
- No corporate tone — never "leverage", "utilize", "in conclusion"

## AI Writing Rules

### Words to never use
delve, landscape (metaphor), tapestry, robust, comprehensive,
cutting-edge, leverage (verb), seamless, game-changer, utilize...

That file didn't write itself. Neither did the slash commands, the PRDs, or the prompt structures that feed each conversation. That's the context transfer tax — and right now, I'm the only one who can pay it.

So yeah. The bottleneck framing? It's not wrong.

Where the hope is

Here's what I keep coming back to: the AI is fast, but it doesn't know what matters.

It can generate ten approaches to a problem. It can't feel which one fits. It can scaffold a feature in three minutes. It can't tell you whether that feature should exist. It can write a migration, but it doesn't know that the team decided last Thursday to deprecate that table.

The bottleneck isn't human thinking. It's human judgment. And judgment is still the whole game. The deciding, the "no, not that" — that's where the value lives right now.

I want to believe that's durable. That the human in the loop isn't a bug in the system — it's the part that makes the system worth running.

Where the doubt creeps in

But I'd be lying if I said I was confident about that.

Five months from now, the models will hold more context. The configuration tax I pay today — the rules files, the slash commands, the careful conversation resets — might just disappear. The bottleneck I represent gets thinner.

A year from now? Maybe the AI doesn't need me to structure the PRD. Maybe it reads the codebase, talks to the stakeholders, and figures out what to build on its own. Maybe "judgment" starts looking less like a human skill and more like a training objective.

Five years from now? I don't know. And that's the part that sits with me.

I've spent over twenty years building a career on writing software. The craft shifted once already — from writing code to orchestrating agents. I adapted. I built systems around it. But what if it shifts again? What if the next version doesn't need an orchestrator?

Where I actually am

I don't have a clean answer. I'm not going to pretend I do.

Right now, today, I still matter in this loop. My judgment catches things the AI misses. My context about the team, the users, the history — that stuff is load-bearing. Remove me and the output gets faster but worse.

But I'm watching that gap close. Month by month. And I'm trying to figure out what to invest in that stays valuable even if the gap closes all the way.

Maybe it's taste. Maybe it's something I haven't named yet.

I'll keep building. I'll keep writing about it. And I'll keep sitting with the question I can't answer: where do I fit in this?

Casey Muratori Said Both Things

Josh Tune — Mon, 13 Apr 2026 00:00:00 GMT

Casey Muratori said two opposite things on two consecutive days. And I can't stop thinking about it.

On Saturday, in Bullish or Bearish on AI Coding Assistants? "No.", he flatly refused AI coding assistants. His reasoning: "The thing I like about programming is me figuring out a new way to do something. I need to be there doing it myself." Skip the creative problem-solving and you train yourself out of relevance. No middle ground.

On Sunday, in The New Most Valuable Programming Job: AI Babysitter, he predicted the most valuable programmer of the future is someone who doesn't care about writing code. The "AI babysitter" — deep technical knowledge, no emotional attachment to the craft. Those people won't burn out because they were never in love with the part that's disappearing. People like Casey? "Probably out."

Both clips surfaced via A Life Engineered on YouTube.

This matters because of who's saying it. Casey built Bink Video — the codec used in over 15,000 games. He worked on The Witness. He spent 660+ episodes of Handmade Hero teaching people to write games from scratch, no engines, no shortcuts. This is someone who has spent his entire career arguing that understanding every layer of the code matters.

And now he's holding both ends of the rope. The craft is the point — and the market is about to stop paying for it.

Where I fit

I wrote a few days ago about sitting with a question I can't answer: where do I fit in this? Casey's two-day arc maps almost perfectly onto that post — my "where the hope is" section vs. my "where the doubt creeps in" section. He just said both parts out loud.

But here's where I break from his framing. Casey draws a binary. I don't land on either side.

	Casey (Saturday)	Casey (Sunday)	Where I land
Core belief	The craft is the point	The craft is a liability	The craft serves the outcome
AI stance	Refuses it — skip the creative work and you lose relevance	Predicts it wins — babysitters replace builders	Uses it to ship faster
Who thrives	Those who own every layer	Those with skills but no attachment	Those who care about the thing working
What's at risk	Irrelevance if AI catches up	Burnout if you loved the old job too much	Still figuring that out

I like the craft. I like reasoning through a problem, shaping the solution, seeing the code take form. But that's not the only part I like. I also like seeing it work. The thing running. The user hitting the page. The deploy going green. The moment where it stops being code and starts being a product.

The shipping is the bigger reward for me. Always has been. The craft was always in service of that.

Why that gives me hope

If the attachment is to the outcome — not just the process — then the shift Casey describes doesn't take everything away. It changes how I get there. I orchestrate instead of hand-write. I review instead of draft. The role changes, but the thing that motivates me survives.

The people Casey says are "probably out" are the ones whose entire identity lives in the writing. Remove that and there's nothing left to care about. But if part of your identity lives in the working — in the thing existing, being used, doing its job — then you've got something the transition doesn't touch.

What I'm still not sure about

I don't want to oversell the comfort here. The craft does matter to me. Letting go of more of it every month carries a cost. Some days I miss the version of the work where I wrote every line and knew every corner of the codebase.

And Casey's bigger point still stands: if AI eventually handles the judgment too — the deciding, the reviewing, the "no, not that" — then even the babysitter role has an expiration date.

I don't know when that is. Neither does Casey. He just said it out loud, which is more than most people are willing to do.

I'm still building. I'm still writing about it. And I'm watching one of the most craft-obsessed programmers alive wrestle with the same question I am — which tells me the question is real, even if the answer isn't here yet.

Josh Tune

Stacked vs. Flat MRs: My Simple Rule

Stacked Merge Requests on GitLab with CLI Tools

Summary (Highlights)

Warning

Lets Get Started

The Example Stack

A) git-spice (purpose-built for stacked MRs)

1. Create branches & submit stacked MRs

2. Propagate an update

B) git-town (branch workflow enhancer)

1. Create branches & open stacked MRs

2. Propagate an update

C) GitLab-native (glab / push options)

1. Create branches & stacked MRs with glab

Alternative: Git push options

2. Propagate an update

Summary

Three Weeks with AI CLI: What I’ve Learned

From Three Weeks with AI CLI → Starting Fresh: My Next Phase

1. Slice by slice, not monolithic

2. The AI writes the rubric first

3. Reinforce the tracking habit

4. Stay in the driver’s seat

What I hope to achieve

The Next Phase Didn’t Become a New Project — It Became lehi31.com

The Reality: Shipping Instead of Starting

What actually shipped

Recurring Events Became a Real Feature

Permissions and Roles Grew Up

Auth and User Management Became Operable

Navigation and Layout Got the Attention It Needed

Challenges, Goals, and the “Actual Product Surface”

What This Taught Me About AI-Assisted Development

What’s Next

Markdownify MCP: Turn (Almost) Anything Into Markdown

Summary (Highlights)

Why this is so useful

A few “this immediately helps me” use cases

Quick start (from the repo)

Wiring it up in an MCP desktop app

One tiny caveat

Go check it out

Vibe Kanban: I’m a Fan

Spec Kit: Spec-driven development for AI-assisted coding

The moment it clicked for me

The Spec Kit workflow (high level)

A concrete example (mocked)

1) Create a constitution

2) Specify the feature (the “what” and “why”)

3) Provide a technical plan (the “how”)

4) Generate tasks, then implement

What I like about Spec Kit

Where it might not fit

If you want to try it

Closing thought

Living Like This: How Top Developers Work with AI Coding Assistants

1. PRD-First Development

2. Modular Rules Architecture

3. Commandify Everything

4. The Context Reset

5. System Evolution Mindset

The Daily Workflow

The Meta-Lesson

Start Here

Resources

MCP in Front of APIs: What That Means (and Why It Matters)

The 30-second version

What MCP is (in practical terms)

What “MCP in front of APIs” usually means architecturally

1) “Adapter” MCP servers (per domain/system)

2) An “MCP gateway” (centralized front door)

3) MCP as a policy layer on top of an API gateway

What it means for you as a developer

You’ll design tools, not just endpoints

You’ll care more about “how the model fails”

You’ll build “AI integration tests”

You’ll spend time on governance plumbing (even if you don’t want to)

What it means for software development (the bigger shift)

APIs become “AI-addressable”

1. Create branches & stacked MRs with `glab`

1) Parallel branches without `stash` gymnastics