I'd wanted to learn in the past, but the hardest part was always entry. This year, I dedicated the summer to myself and taught myself how coding languages work. Before attempting to use an AI bot to code with, I wanted to truly know, to actually understand, what I'd be looking at.
The most difficult part was the intro: learning GitHub integration, repo rules, commits, pushes, PRs. npm had made me run away in the past. But this summer I kept chugging along; re-reading, researching outside of video tutorials, independently, without AI, taking a scholastic, human approach. That's what got me here.
September is my birth month. I'd planned on learning to code and having something ready by September. I took on the largest coding idea I felt was feasible and necessary for the times we're in, but it's large, and it's going to require finances I don't currently have to launch properly. I decided to attempt my most ambitious project first anyway. It's turned out to be the best-case scenario for me: learning as I go, bridging the gap between foresight and knowledge.
I thought AI would help me finish that first project quickly, but I quickly learned that's not possible, not even with AI. Speed doesn't necessarily equal quality, so I let go of speed in favor of process and consistent continuity. That's where my first public tool was born. Over 700 commits later, on a project that now runs more than 3,000 tests with zero failures, I know I won't be able to release the large project just yet, so I wanted to share something I could. This tool is an amalgamation of three custom tools I built along the way. I started in May, knowing I wanted to release something before my birthday, something I could proudly stand behind publicly, It's finally here.
I present, driftcheck.
driftcheck is a CLI with three verification passes:
driftcheck repo: confirms whether your working picture of the repository is current: git state against origin, open pull requests, database migration status, and test results with real flake-versus-regression triage. A failure gets re-run in isolation before it's classified as real, not assumed either way.
driftcheck docs: verifies a reference document (CLAUDE.md, AGENTS.md, or similar) still accurately describes the code it names, checking each reference against the actual repository instead of trusting the document.
driftcheck spec: a continuity mechanism for long-running, AI-assisted work: scaffolds a versioned project spec, and spec close checkpoints it forward with a handoff document for the next session, patching only what changed so nothing you hand-edit gets silently thrown away.
That shift, from speed to finishing right, isn't just something I believe, it's the actual design discipline behind driftcheck. A few concrete examples of what that looked like in practice:
Zero LLM dependency in the tool itself; no API call anywhere, including the parts that generate content. A tool whose whole job is catching unverified claims shouldn't be making any of its own.
Real defects were found by testing against production codebases, not by trusting that the logic looked correct. One: a test-output parser that silently dropped "every test in the suite failed" as a case, because the regex assumed a "passed" count would always be present. Another: a file-matching pattern that only recognized .test.ts, inherited from a version of the tool that had only ever run against one TypeScript codebase.
MIT licensed, effectively zero dependencies
All feedback is welcome, especially "this assumption breaks on my stack"; that's the fastest way I'll find the edges of this thing.
If it's useful to you and you feel like tossing something my way, there's a donation section in the README, never expected, always appreciated. Best way to reach me is Reddit DMs.
I'd wanted to learn in the past, but the hardest part was always entry. This year, I dedicated the summer to myself and taught myself how coding languages work. Before attempting to use an AI bot to code with, I wanted to truly know, to actually understand, what I'd be looking at. The most difficult part was the intro: learning GitHub integration, repo rules, commits, pushes, PRs. npm had made me run away in the past. But this summer I kept chugging along; re-reading, researching outside of video tutorials, independently, without AI, taking a scholastic, human approach. That's what got me here. September is my birth month. I'd planned on learning to code and having something ready by September. I took on the largest coding idea I felt was feasible and necessary for the times we're in, but it's large, and it's going to require finances I don't currently have to launch properly. I decided to attempt my most ambitious project first anyway. It's turned out to be the best-case scenario for me: learning as I go, bridging the gap between foresight and knowledge. I thought AI would help me finish that first project quickly, but I quickly learned that's not possible, not even with AI. Speed doesn't necessarily equal quality, so I let go of speed in favor of process and consistent continuity. That's where my first public tool was born. Over 700 commits later, on a project that now runs more than 3,000 tests with zero failures, I know I won't be able to release the large project just yet, so I wanted to share something I could. This tool is an amalgamation of three custom tools I built along the way. I started in May, knowing I wanted to release something before my birthday, something I could proudly stand behind publicly, It's finally here. I present, driftcheck. driftcheck is a CLI with three verification passes:
driftcheck repo: confirms whether your working picture of the repository is current: git state against origin, open pull requests, database migration status, and test results with real flake-versus-regression triage. A failure gets re-run in isolation before it's classified as real, not assumed either way. driftcheck docs: verifies a reference document (CLAUDE.md, AGENTS.md, or similar) still accurately describes the code it names, checking each reference against the actual repository instead of trusting the document. driftcheck spec: a continuity mechanism for long-running, AI-assisted work: scaffolds a versioned project spec, and spec close checkpoints it forward with a handoff document for the next session, patching only what changed so nothing you hand-edit gets silently thrown away. That shift, from speed to finishing right, isn't just something I believe, it's the actual design discipline behind driftcheck. A few concrete examples of what that looked like in practice:
Zero LLM dependency in the tool itself; no API call anywhere, including the parts that generate content. A tool whose whole job is catching unverified claims shouldn't be making any of its own. Real defects were found by testing against production codebases, not by trusting that the logic looked correct. One: a test-output parser that silently dropped "every test in the suite failed" as a case, because the regex assumed a "passed" count would always be present. Another: a file-matching pattern that only recognized .test.ts, inherited from a version of the tool that had only ever run against one TypeScript codebase.
MIT licensed, effectively zero dependencies All feedback is welcome, especially "this assumption breaks on my stack"; that's the fastest way I'll find the edges of this thing. If it's useful to you and you feel like tossing something my way, there's a donation section in the README, never expected, always appreciated. Best way to reach me is Reddit DMs.
[flagged]