Last year my team started using AI coding tools more heavily, and we found ourselves generating tons of code, but spending less time looking at the stuff that's been generated.

We felt like we were losing a bit of grip/understanding of what we were building. Regressions occasionally slipped through. Sometimes changes made it all the way to production only to be reverted later.

We tried several AI code review tools, but most operate at PR time. That felt too late. I wanted review to happen while the implementation was still fresh in the developer's mind at a team level (soft enforcement). I also wanted to emphasize responsibility for keeping prod stable with each individual engineer.

So I built git-lrc.

When you commit, git-lrc opens a review UI with your diff. It summarizes what changed, points out things that deserve a second look, and lets you quickly jump through the important parts of the change.

Over time, git-lrc has grown to check for around 100 common risk patterns across 10 categories, including security, reliability, performance, maintainability, etc.

Note that this is far from a formal review. It's a quick 60 seconds spent looking at your own work before it gets recorded in git.

It also generates a short "summary deck" that highlights the main changes, with special emphasis on potential risks. With git-lrc you can quickly sanity-check what you're about to ship and obtain greater confidence in what's been generated.

In my mind it is less of an AI reviewer and more as a habit for AI-assisted development: a small pause to make sure we understand and stand behind the code we're shipping.

Developers can review the change, vouch for it, or consciously skip the review. Those decisions get recorded in git history, creating a trail of how code was reviewed before it shipped.

It'd be great if you could take a look, give it a try in your projects or teams and let me know what you think.

Happy to take feedback from the HN community and improve it over time!

GitHub: https://github.com/HexmosTech/git-lrc

Comments URL: https://news.ycombinator.com/item?id=48555511

Points: 9

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48402023

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48255501

Points: 33

# Comments: 2

Comments URL: https://news.ycombinator.com/item?id=48105848

Points: 3

# Comments: 2

I thought the whole point of trying to write out TLA+ is so that you get a better idea of what you want and put it into formal language?

I get that an LLM can assist/help with expressing what we want in formal language a bit, but if one automates all this there is no human intent/design anymore.

If the LLM generates both the design (TLA+) and writes an arbitrary program that satisfies said design -- what exactly have we proved?

What assurance do humans get since human doesn't know or cannot specify what they want.

Comments URL: https://news.ycombinator.com/item?id=47554615

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47402524

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47171980

Points: 2

# Comments: 0

As to disposable software, it's harder to get traction/adaption when things constantly break or are slow or the experience is crappy in general.

To make it simpler - all else being equal - as a user would you prefer using highly reviewed/vetted/reliable software, or otherwise?

My bet is reliability is an invariant -- nobody wishes for software that crashes, leaks your private info, gives faulty output, is laggy to use and so on.

Comments URL: https://news.ycombinator.com/item?id=47073351

Points: 46

# Comments: 18

Consider something like TLA+. How can we make things such as that - be useful in an LLM orchestration framework, be human friendly - that'd be the question I ask.

So the developer will verify just the spec, and let the LLM match against it in a tougher way than it is possible to do now.

Many times, these GenAI tools can delete/modify code mistakenly.

I use LiveReview's git precommit features - so the review happens right before I commit code automatically. And it has saved me many (100s of) times.

Give LiveReview's Precommit checks a try.

Comments URL: https://news.ycombinator.com/item?id=46913797

Points: 4

# Comments: 0

Once you look at the present engineering org compositions see what's the error in thinking.

There are other analogy issues in your response which I won't nitpick

Quick check: Do you want to go back to pre-industrial era then - when according to you, you had better options for clothing?

Personally, I wouldn't want that - because I believe as a customer, I am better served now (cost/benefit wise) than then.

As to the point about recursive quality decline - I don't take it seriously, I believe in human ingenuity, and believe humans will overcome these obstacles and over time deliver higher quality results at bigger scale/lower costs/faster time cycles.

What the role of an engineer in the new context - I am not speculating on.

I'd think there'll be a dip in code quality (compared to human) initially due to "AI machinery" due to its immaturity. But over-time on a mass-scale - we are going to see an improvement in the quality of software artifacts.

It is easier to 'discipline' the top 5 AI agents in the planet - rather than try to get a million distributed devs ("artisans") to produce high quality results.

It's like in the clothing or manufacturing industry I think. Artisans were able to produce better individual results than the average industry machinery, at least initially. But overtime - industry machinery could match the average artisan or even beat the average, while decisively beating in scale, speed, energy efficiency and so on.