I've been writing code for long enough to see a lot of cycles come and go. The current LLM hype reminds me of every other "this changes everything" moment we've lived through. Like those other moments, there's some real value buried under a mountain of breathless takes and venture capital.
Here's what I know: LLMs are genuinely useful for development. They can crank out boilerplate, suggest approaches I hadn't considered, and help me think through problems. But they're also fundamentally flawed in ways that make "vibe coding" without guardrails a recipe for issues 1.
The "Army of Juniors" Problem
Every time you start a new chat with an LLM, you're essentially hiring a talented but inexperienced junior developer who has no memory of what you've tried before, no understanding of your project's constraints, and an alarming tendency to suggest rewriting everything because "it would be cleaner that way."
The productivity gains are real, until they're not. You get that initial dopamine hit of rapid progress, then three months later you're staring at a codebase that looks like it was written by five different people who never talked to each other. Because that's basically what happened 1.
The Context Reset Problem
The fundamental issue isn't that LLMs are bad at coding. It's that they have no persistent memory. Every conversation starts from zero. They don't remember:
- Why you chose that particular approach over the obvious alternative
- What you tried that didn't work
- The constraints that shaped your decisions
- The patterns that emerged as you built the system
This creates a vicious cycle. You explain the context, the LLM suggests something you already tried, you explain why that won't work, it suggests something else, and by the time you get to useful output, you've burned through your context window and half your day.
Meanwhile, platforms like Cursor and Claude are trying to solve this by hoovering up all your code and storing it in their systems. Which is fine until you want to switch tools, or the platform changes their model, or you're working on something you can't send to external services.
A Practical Solution (Not a Silver Bullet)
I built checkpoint because I got tired of explaining the same context over and over again. It's not revolutionary, it's just structured note-taking that travels with your code 2.
The core insight is simple: development context should be as portable and persistent as the code itself. Instead of losing your reasoning in chat logs or IDE-specific storage, capture it in git-tracked YAML files that live in your repository 2.
Here's how it works in practice:
# Start a session - see what happened before
checkpoint start
# Make your changes...
# Capture what happened
checkpoint check # Generates input from git diff
# Fill in the structured template (or have your LLM do it)
checkpoint commit # Validates and commits to both git and changelog
The checkpoint check command generates a structured template based on your git diff. You (or your LLM) fill in what changed, why, what you tried that didn't work, and what comes next 2. The key is the human review step, the LLM can draft the checkpoint, but you validate it before it goes into the permanent record.
What This Actually Gives You
The real value isn't in the individual checkpoints. It's in the accumulated context that builds up over time:
.checkpoint-changelog.yamlbecomes a searchable history of decisions and their reasoning 2.checkpoint-context.yamlaccumulates patterns, anti-patterns, and project-specific knowledge 2guardrail explaincan provide rich project context to any LLM, regardless of provider
When you come back to a project months later, or when a new team member joins, or when you switch from Claude to Cursor to whatever comes next, the context is right there in the repository.
What This Doesn't Fix
Let me be clear: this isn't a silver bullet. It won't stop LLMs from implementing return true when they can't figure out the logic. It won't prevent them from adding dependencies you don't need or rewriting working code because they think it's "cleaner."
What it does is give you a fighting chance of maintaining some institutional memory as you work with these tools. It's the kind of systematic governance that treats LLMs like what they are: powerful but junior team members who need experienced oversight 1.
The Compound Effect
The real payoff comes from consistency. Each checkpoint builds on the last. Patterns emerge. You start to see which approaches work in your specific context and which don't. The LLMs get better context to work with, so they make fewer obviously wrong changes.
It's not about slowing down development, it's about avoiding the kind of technical debt that forces you to throw everything away and start over. I've been around long enough to know that "move fast and break things" works great until you actually need the things to work.
The tools are getting better, but they're still fundamentally limited by their lack of persistent context, and tool developers needing to figure out how to constrain them enough that they are profitable. A little structure goes a long way toward keeping the "army of juniors" from burning down your codebase. This improves your odds of maintaining the code long term and still being able to understand where it came from.
Checkpoint is open source and available at github.com/dmoose/checkpoint. It works with any LLM provider and integrates with existing development workflows.
References: