Today marks a personal milestone: I have finally finished a massive, six-month-long refactoring of my other project, gomarklint.
After spending half a year staring at Go code structures and AST nodes, I realized something painful. Our current tools are still "dumb" when it comes to understanding the intent of our changes. We are still reviewing code line-by-line, even though we think in structures and logic.
That’s why I’m excited to announce my next OSS project: gosemdiff.
The Problem with Current Solutions (Including AI)
We now have AI tools that can summarize Pull Requests for us. They are helpful, but let's be honest: AI summaries are often "vibes-based." An AI might say, "This PR refactors the processing logic," but it can't mathematically guarantee that the logic remains unchanged. AI can hallucinate, overlook edge cases, or fail to distinguish between a variable rename and a subtle logic bug.
As engineers, we don't need a "guess." We need proof.
Standard git diff treats code as text. But code is not just text; it’s a tree of logic.
The Solution: gosemdiff
gosemdiff is a semantic diff tool designed specifically for Go. Instead of comparing lines, it parses your source code into an Abstract Syntax Tree (AST) and compares the underlying structures.
The goal is to provide a "Truth Machine" for your Pull Requests.
Key Concepts:
-
Semantic Labeling: Automatically identify changes as
MOVE,RENAME, orLOGIC CHANGE. - Logic Integrity: Prove that a refactor hasn't changed the execution flow by comparing normalized AST hashes.
-
Test-Gap Detection: Alert you if a logic change was made without any corresponding updates to your
*_test.gofiles. - Zero-Noise Mode: Completely ignore comments, formatting, and import ordering.
The Roadmap to v1.0.0
I’ve laid out an ambitious roadmap in the repository, moving from basic function inventorying to a fully integrated GitHub Action.
The ultimate goal? A CI bot that tells your reviewers:
"This PR is 90% refactoring. Logic changes detected in only 2 files. One logic change is missing a unit test."
I Need Your Feedback!
I’m taking a short break to recharge after the gomarklint marathon, and full-scale development on gosemdiff will kick off in about two months.
However, the "Grand Vision" is already live in the README. I want to build this for the community, so I need your input:
- What kind of diffs annoy you the most during code reviews?
- What "semantic" features would make your life easier?
- What’s your dream CI summary?
Please check out the repo and leave your ideas, feature requests, or "what-ifs" in the GitHub Issues!
Let's make code reviews about logic again, not just lines.
Top comments (0)