There was a time when a pull request could get a quick look, a passing CI run, maybe a familiar name attached to it, and a simple “LGTM”.
Looks good to me.
That did not mean maintainers were careless. It did not mean nobody cared about quality. It meant the world around the pull request was smaller.
You knew the project. You recognized the contributor. You knew which parts of the code were sharp. You knew whether someone had tested the change in a real setup. You knew, or at least had a pretty good feeling, that if something went wrong, the person who changed it would still be around for the conversation.
“LGTM” was short because the context around it was rich. I miss that sometimes. I also know we are not going back.
Open source won
The uncomfortable part is that this is not a story about open source failing.
It is the opposite.
Open source became very good at its core mission. It made software available, reusable, inspectable, improvable, and shared. It moved from “that thing people do on the side” to the default way a lot of software is built. That is a huge win. It also changed the stakes.
When a project becomes widely used, a pull request stops being just a change to a repository. It becomes a change to something people depend on. Sometimes a lot of people. Sometimes in places the maintainer will never see. I feel this very directly with Home Assistant.
Home Assistant is not a small hobby project anymore. Millions of households run it nowadays. People use it for lighting, heating, energy, notifications, accessibility, family routines, security-adjacent automations, and a ridiculous number of personal setups nobody on the Home Assistant team can fully predict.
That is beautiful. It is also a responsibility. A change that looks small in a pull request can affect a real home. Not an abstract user. A person. Their partner. Their kids. Their morning routine. Their energy bill. Their trust in the system.
That changes how you review.
I changed too
I am not the same reviewer I used to be.
That is not a proud confession or a sad one. It is just true. I changed how I approve changes in Home Assistant because the project changed around me. The amount of usage changed. The type of usage changed. The number of contributors changed. The amount of code changed. The number of integrations changed. The blast radius of a mistake changed.
So yes, sometimes I am a wall. 🧱
Not always the nicest wall to run into as a contributor either. I know that... 😬
You open a pull request with good intentions. You fixed something. You improved something. You finally had the courage to contribute. Then, instead of a quick merge, you get questions. More tests. A request to rethink the approach. A maintainer asking why this belongs here at all.
That can feel bad. Honestly, it is not always fun on the maintainer side either. But as a maintainer, I am not only reviewing your code. I am also protecting the people who will never see your pull request, never read the discussion, and only experience the result in their home. That sentence is where “LGTM” got heavier.
Review is not only about the diff
The old idea of review is simple: does this diff look good? Modern open source review is not that simple anymore. Now I am often asking different questions:
- Is this the right problem to solve?
- Is this the right place to solve it?
- What breaks if this is wrong?
- Does this behavior make sense for existing users?
- Is the migration path clear?
- Did the boring edge cases get tested?
- Can we maintain this after the contributor leaves?
- Does this fit the trust users place in the project?
That last one matters more than we sometimes admit. Users do not care that a change looked elegant in review if it breaks their setup on a Tuesday morning. They do not care that the code was neat if the behavior is surprising. They do not care that the contributor meant well if the project now has to carry a bad abstraction for the next five years.
Intent matters. Ownership matters. Understanding matters.
A pull request can pass CI and still be wrong. A diff can look clean and still move the project in a direction we should not go. A contribution can be technically correct and still create work that maintainers have to pay for later.
That is not a reason to distrust contributors. It is a reason to take the responsibility seriously.
AI made this impossible to ignore
AI is part of this story, but it is not the whole story. It would be easy to make this article about AI-generated pull requests and stop there. I do not think that is the full picture.
The shift started before that. Open source became more critical. Supply chains became more interesting targets. Projects got more users than maintainers can personally understand. More companies built on top of community work. More contributors arrived without the old social context.
AI poured gasoline on that fire. 🔥
It lowered the cost of producing plausible code. It lowered the cost of opening a pull request. It lowered the cost of sounding confident in an area you may not actually understand. That does not make AI evil. I use AI. I think it can be useful. I also think useful tools can make existing problems louder.
The dangerous contribution is not always the obviously bad one. Obviously bad code is often easy to reject.
The hard one is the plausible change. The one that looks reasonable at first glance. The one that passes tests, but solves the wrong problem. The one that copies a pattern without understanding why the pattern exists. The one where the contributor cannot answer the second follow-up question without going back to the machine.
AI did not create the need for stricter review. It removed the last excuse for pretending the old model still scales.
This is not gatekeeping
I know how this can sound from the contributor side.
“Maintainers are making it harder”.
Sometimes, yes. We are. But harder is not always worse. A maintainer who says yes too easily is not being kind. They are pushing the cost of that yes onto users, future maintainers, and sometimes the contributor themselves.
There is a version of open source that sounds welcoming but silently burns everyone behind the scenes. Merge fast. Accept everything. Avoid uncomfortable review. Keep the contributor happy today, and let someone else clean up the consequences later.
That is not kindness. Good review can be annoying. It can be slow. It can ask for more than you expected. It can make a small change feel bigger than you thought it was. But good review is also how a project protects its users, its maintainers, and its future contributors.
The trick is doing that without becoming cold.
That is the part I think we need to keep working on. Stricter review does not have to mean hostile review. Saying no does not have to mean being dismissive. Asking for tests does not have to mean distrusting someone. Requesting context does not have to mean building bureaucracy for sport.
It should mean: this project matters, so we need to understand what we are about to carry.
What LGTM means now
I still like “LGTM”. I just think it means more now.
It cannot only mean “the diff looks fine”. It has to mean I understand the change. I trust the reasoning. I believe the project can carry it. I believe the contributor has taken responsibility for it. And I am willing to put it in front of the people who rely on this software every day.
That is heavier than it used to be. It should be.
Open source won. Home Assistant won in its own weird, wonderful way too. Millions of households running it is something to be proud of. 🥇
But success has a cost.
Sometimes that cost is that “looks good to me” is no longer enough.
../Frenck
