I've been working on a software tool for myself, to lighten the load of my job (software engineering), and also *just because*. I'm honestly proud of it. `acre` v0.9 is out there.
**acre** is a code review engine: a personal tool for tracking and managing code review progress.
So much of my job in software engineering is about code review. It wasn't part of the first decade, oddly enough, and it emerged as a best practice, even as the exact justifications fluctuated.
With the addition of LLM-generated code, code review becomes more essential: you must deeply review the code you, yourself, had prompted from the language model, and you're going to have to be accountable for those changes made on your behalf. As much as vibe coding produces indistinguishable magic, you're still left with three hard questions:
- How do you know that it does what you want?
- How will you change it?
- How will you fix it?
To answer those, you might need code review.
- `0.9`: a version I'm using daily and finding useful - `1.0`: a version I'm confident that others can use
Months ago, I brainstormed what my own dream code review tool would be like, trying to distill my own manual process. (And I don't know for certain it's the best process, but in any case, it's what I'm doing, so I may as well make it go more smoothly.) There are versions I did in the past - creating big `*.diff` files and deleting them down to zero as I read through them. In some sense, I made do with just using web PR interfaces and wearing out my mouse wheel.
A few weeks ago, I brushed off my brainstormed notes, and began to create the smallest shim that I'd find useful daily. The first versions were prompted and vibe-coded (ironically), but I ended up rewriting more and more in order to land on a codebase I'd actually want to live with.
$ acre --help
usage: codereview.py [-h] {init,status,ls,overview,reset,metadata,review,interactive} ...
It felt like a case of acceleration, where the more I used it, the more clearly I knew the next step I needed, and with a tool that's 80% useful, the feature gap leading to 90% seems that much more plausible and missing.
It's important to start, but it's also important to pause. I'm calling the current version `v0.9.0` since I'm using it daily, but still have additional features for myself (and more importantly some rough corners to sand off) before I'll grant it `v1.0.0`, in the truest traditions of sentimental versioning.
I hope someone finds it useful, but also I really did make it for myself, and there's one kind of pride for doing something to make my own technical practice better, but there was also some joy at writing the software the way I wanted - chasing some kind of feeling that there was more to the craftsmanship, some kind of meaning beyond the definition of the work.
Thanks to the *Lobsters Blog Carnival* as being inspiration for writing this post.
https://lobste.rs/s/0nstyk/join_lobsters_blog_carnival
The announcement post suggested this one unanswered question:
**What does `acre` stand for?** acre = ACRE Code Review via ECRA. (ECRA = enhanced command-line routine for ACRE.)
Beyond that, there's probably some fragile assumptions about git repos and GitHub APIs.
Probably!
I feel lucky that I was inspired andhad the knowledge to make something I enjoy. I'm glad I've somehow learned
to not just start but also *finish* a side project (even if there are other finish-lines ahead). I'm glad I had some
downtime at the end of summer to give this some time. And...
Thanks to my lovely spouse, @labmouse, for encouraging me to follow my inspirations (and for laughing with me at my corny programming jokes).
https://github.com/devp/acre/commit/da22ac92568e9f0bf3760d7a689a5eff9fa86d03
-----