I’m working on something in a similar direction and would appreciate feedback from people who’ve built or operated this kind of thing at scale.
The idea is to hook into Bitbucket PR webhooks so that whenever a PR is raised on any repo, Jenkins spins up an isolated job that acts as an automated code reviewer. That job would pull the base branch and the feature branch, compute the diff, and use that as input for an AI-based review step. The prompt would ask the reviewer to behave like a senior engineer or architect, follow common industry review standards, and return structured feedback - explicitly separating must-have issues from nice-to-have improvements.
The output would be generated as markdown and posted back to the PR, either as a comment or some attached artifact, so it’s visible alongside human review. The intent isn’t to replace human reviewers, but to catch obvious issues early and reduce review load.
What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness. I’m also concerned about failure modes - for example, noisy or overconfident comments, review fatigue, or teams starting to trust automated feedback more than they should.
If you’ve tried something like this with Bitbucket/Jenkins, or think this is fundamentally a bad idea, I’d really like to hear why. I’m especially interested in practical lessons.
> What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness.
The results of a diff-only review won't be very good. The good AI reviewers have ways to index your codebase and use tool searches to add more relevant context to the review prompt. Like some of them have definitely flagged legit bugs in review that were not apparent from the diff alone. And that makes a lot of sense because the best human reviewers tend to have a lot of knowledge about the codebase, like "you should use X helper function in Y file that already solves this".
At $DAYJOB, there's an internal version of this, which I think just uses Claude Code (or similar) under the hood on a checked out copy of the PR.
Then it can run `git diff` to get the diff, like you mentioned, but also query surrounding context, build stuff, run random stuff like `bazel query` to identify dependency chains, etc.
They've put a ton of work into tuning it and it shows, the signal-to-noise ratio is excellent. I can't think of a single time it's left a comment on a PR that wasn't a legitimate issue.
I work at Graphite, our reviewer is embedded into a bigger-scope code review workflow that substitutes for the GH PR Page.
You might want to look at existing products in this space (Cursor's Bugbot, Graphite's Reviewer FKA Diamond, Greptile, Coderabbit etc.). If you sign up for graphite and link a test github repo, you can see what the flow feels like for yourself.
There are many 1000s of engineers who already have an AI reviewer in their workflow. It comments as a bot in the same way dependabot would. I can't share practical lessons, but I can share that I find it to be practically pretty useful in my day-to-day experience.
cursor has a reviewer product which works quite well indeed, though I've only used it with github. not sure how they manage context, but it finds issues that the diff causes well outside the diff.
We have coding agents heavily coupled with many aspects of the company's RnD cycle. About 1k devs.
Yes, you definitely need the project's context to have valuable generations. Different teams here have different context and model steering, according to their needs.
For example, specific aspects of the company's architecture is supplied in the context. While much of the rest (architecture, codebases, internal docs, quarterly goals) are available as RAG.
It can become noisy and create more needless review work. Also, only experts in their field find value in the generations. If a junior relies on it blindly, the result is subpar and doesn't work.
I’ve been working as a backend developer for close to six years now, but reading this brought me right back to college.
Like many others, I started with C. It taught me the basics - memory, pointers, writing data structures from scratch - but most of the time it felt like I was just trying not to break things. Solving problems became more about handling the language than understanding the logic.
Then I came across Java, and something just clicked. It felt structured, readable, and intentional. Almost like reading good English. For the first time, I could focus on the actual problem instead of building the tools to solve it. Collections, built-in libraries, and a reliable runtime made coding feel productive, not just painful.
Even now, years later, Java still feels like home. It’s not perfect, but it gave me the space to learn, grow, and build things that last. I really appreciated this article - it captures that quiet strength Java has, and the care so many people have put into making it better over time. It reminded me why I still enjoy writing Java after all these years.
Similar story - did half the university courses in C or C++, then picked up this new language called Java for next semestral project. I made 3D map of my home country from a set of 3D points in something called Java3D, long-abandoned effort that could make 3D objects and interactions ie in desktop UI but also on web via applets (I told ya long time ago, this was early 21st century).
Working under it, apart from usual initial pains was marvelous - the language itself somehow forced me to make much cleaner code compared to C, which as a beginner became horrible mess pretty quickly. Suffice to say, debugging was trivial, no pointers just easy life.
25 years later, Its close to 100% of all work I ever done professionally and I don't mind surfing that wave till retirement, Java is so spread into corporate sphere that there will be enough work especially for seasoned experts for decades to come.
Stuff juniors often complain - OO bloat, EE megabloat etc become invisible pretty quickly, and you just work with the code, however you like it. Its a great platform to see that premature optimization is really not something to worry about during initial implementation (unless you do N-th rewrite of some performance-critical app, which most of us rarely if ever do). It doesn't mean any spaghetti code is fine, just that following normal design principles is normally good enough and one can focus on things like security, clustering and actual features.
Funny I had the exact opposite reaction to Java when I needed to use it in college. So many abstractions, forced design patterns and boilerplate. Absolute soul sucking joyless development.
> So many abstractions, forced design patterns and boilerplate.
Important to remember none of that is part of Java.
There was a period of time (and it goes in waves) when extreme complexity was the thing, and one peak of this mania coincided with the rise of Java, so a lot of people on this high horse of complexity latched on to Java because it was the place to be.
None of that is related to the language Java though, nor its fault! I've been writing java since 1996 (including many years at Sun) and not once have I worked on those silly MethodHelperContainerParameterEventPrincipalGetterBean-style codebases.
That's purely a choice and one best avoided. Just use java as a very fast very scalable memory-safe language, keep the code simple.
It had abstractions but you were never forced to use them. Ditto with design patterns - you could use them, but none were forced, unless you _had_ to use a framework (like spring), but that's a choice! May be it wasn't your choice, but it was a choice someone made.
If you used java like you used C, java is much easier and less mentally demanding, and therefore less prone to mistakes.
> Ditto with design patterns - you could use them, but none were forced, unless you _had_ to use a framework (like spring), but that's a choice! May be it wasn't your choice, but it was a choice someone made.
Every language has a koolaid aspect to it. Java drinks the OOP+design patterns koolaid, so it was standard to use it incessantly. Yeah in theory there is a choice, not really in practice though. I find the typical over abstracted, one line functions everywhere java codebase revolting.
> Yeah in theory there is a choice, not really in practice though. I find the typical over abstracted java codebase revolting.
It has gone extremely out of fashion to try to use abstractions over abstractions in Java the past 10-ish years. It used to be The Thing to do in the early 2000s, over time people got fed up with such obtuse way of programming, everything hidden under abstractions of abstractions, fucking nightmare.
Of course, there are still large remnants of this era, and folks who were trained in this still trying to apply the same bullshit design patterns to overcomplicate simple stuff, but in my experience it's been a pretty big shift away from that to more readable and simple code.
I still dread the years I worked in Java codebases with their factories of factories, registries of delegates, all the JEE bullshit, and extremely glad I haven't had to deal with this kind of stuff for at least the past 10 years or so...
> Solving problems became more about handling the language than understanding the logic.
I've worked with Java for 25 years and have a love/hate relationship.
Java garbage collection is both great, and terrible. Sometimes objects are instantiated in a method, and should be marked for GC when you leave the method but aren't. There isn't logic or reason, and it trips up juniors hard and reworking "new" features like streams into basic for loops fixes it, even though there isn't any really good reason why.
When it works first time you never even need to think about it, and its awesome. When it doesn't, there is no escape hatch to fix it. Its probably for the best, I would probably prefer someone switched a stream to a loop to fix a GC bug than to keep the stream and add additional code for flagging objects.
> Java garbage collection is both great, and terrible. Sometimes objects are instantiated in a method, and should be marked for GC when you leave the method but aren't.
In the last decade of writing Java software I didn't ever come across a genuine GC bug where a unreferenced object wasn't collected. I'm not disputing that they exist, but if you regularly hit such "bugs" I'm wondering if your understanding of Java GC might be flawed.
Do you expect objects to be immediately collected when they are not reachable anymore?
No its not regularly, I think just once in at least 10 years, probably longer.
And it could easily be either a Spring bug, or bad configuration through misunderstanding.
My point was more that it can be opaque when it doesn't act as expected. Sometimes heap inspection is helpful, but if you use Kafka or Spring Data, etc, it can easily just appear to be a char or int array.
So you hit this bug about one and a half times in your entire career, you're not sure Java caused it or even if it was really a bug, but due to it you have a love/hate relationship and garbage collection is terrible?
Apart from the comment of happymellon (blaming Spring for doing things behind your back), it happens that a factory , building objects for you , will have a “bug” and retain a reference to them for whatever reason.
That is sometimes tricky to figure out.
Nothing Java can be blamed for, as these kind of tricks can happen in any language.
([newbie at C but] I suppose in C, the consumer of the object can force its deallocation, which may lead to other nasty side effect]
They expected not to have to deal with memory at all, I presume ;)
[to go a bit off topic, the debugging of those issues is reasonably tool-assisted in Java, whereas I honestly don’t know how to solve them in, let’s say, Javascript/TS).
This reminded me of something that happened to a friend of mine not long ago. He’d just been laid off from a pretty good Salesforce Admin job and was already in a tight spot financially when his laptop’s motherboard fried after a voltage spike.
Local shops were quoting ₹25,000–₹30,000 (roughly $300–$360), which he just couldn’t afford. Then a friend told him about Nehru Place. He sent the laptop there through someone he knew, and the repair only cost him around ₹5,000–₹10,000 ($60–$120). Way more reasonable.
He was glad to get it fixed without spending a lot but it does make you wonder how reliable those reused parts are. Like, how long is it gonna hold up before something else goes wrong?
Delhi NCR in general looks like a pretty nice place to source tech in India. The Bangalore counterpart of Nehru Place, SP Road felt expensive and a bit less competent than I expected.
I could also see unscrupulous businesses swapping out original parts in machines sent for repair for cheaper ones as a way to drive their costs down. The vast majority of customers wouldn’t be able to tell/prove what happened.
Spare parts are expensive in general in India. Add to the fact that there are unscrupulous repair centers, I am certain that the theft of genuine parts happen regularly.
this is all the more important since 60$ in india is enough for a meal for four in an expensive restaurant in one of the better malls ( for e.g. in Mumbai ) ... and 25k to 30k is just ludicrous for a laptop. Even 5-10k will easily hurt his pockets but it depends on what the laptop's specs were and what it was worth
Heh, my brother got his Xbox original controller fixed for ₹200 which was just misbehaving due to old battery gunk. He could have afforded a new one, sure, but the charm of having the thing get another life, is a separate kick altogether :)
Wow! Brilliant Read. I love how our mind loves to read and visualize scripts and it's like in between infinite thoughts going within. The time we repeat we think in some different way thinking "Oh yeah! Now I understand this more".
Curious to know from the people who have read a lots and lots of text or books or watched movies.
I have read a lot. And contemplative re-reading certain passages or re-watching scenes truly does activate further analysis. For your mind no longer has to decode the surface layer and then has time to search for other patterns.
The more you read or watch the faster this becomes.
The neat part is when you can do a double or even triple reading near instantaneously. It’s a little trickier for films, but still possible. I believe this is how your friends who are really good at just breaking down meaning on first watch are doing it —- they have gained media literacy skills that let them take in scenes in a blink of an eye.
Practice your memory, and you can also hold past scenes in your head as new scenes come up. New connections made there too.
Once I get started on a piece of fiction, I don’t exactly see the text anymore either — my brain starts constructing a sort of movie/diorama in my head and every subsequent sentence builds it more and more. Makes reading fiction great and emotional/symbolic analysis great but funnily enough makes me a weak analyst of the language and craft itself. Made my years in undergrad ironically challenging.
If you are coming from Java Background with some basic understanding of JavaScript/Typescript you should try using Spring framework with React. Try reading blogs from Baeldung.com[1] which provides lots of different articles on how you can use spring for your particular use case.
Developing markets (starved for dollars to pay back loans) and and Europe (starved for energy) will suffer the most imo. The US will be infuriatingly fine (given the warmongering they are doing). It is most likely the FED will be able to pull of the soft landing (even if there is a small recession it will probably not be too deep and long)
The idea is to hook into Bitbucket PR webhooks so that whenever a PR is raised on any repo, Jenkins spins up an isolated job that acts as an automated code reviewer. That job would pull the base branch and the feature branch, compute the diff, and use that as input for an AI-based review step. The prompt would ask the reviewer to behave like a senior engineer or architect, follow common industry review standards, and return structured feedback - explicitly separating must-have issues from nice-to-have improvements.
The output would be generated as markdown and posted back to the PR, either as a comment or some attached artifact, so it’s visible alongside human review. The intent isn’t to replace human reviewers, but to catch obvious issues early and reduce review load.
What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness. I’m also concerned about failure modes - for example, noisy or overconfident comments, review fatigue, or teams starting to trust automated feedback more than they should.
If you’ve tried something like this with Bitbucket/Jenkins, or think this is fundamentally a bad idea, I’d really like to hear why. I’m especially interested in practical lessons.