Feedback in Slack, merge left to the engineer
At his last company Sid had Devin sort bugs and requests in a Slack channel. The user talked to Devin. An engineer pressed merge if it was needed. He was a top 200 user globally.
Done with Valgfri agentModerate
What was done
On 30 September 2026 Sid Nanda (@sidstronaut) writes that he used Devin heavily at his last company, to the point that he was a top 200 user globally. They had a Slack channel just for app feedback. Devin triaged every bug and every feature request. Users talked to Devin to resolve the issue, and an engineer pressed merge if it was needed. With read-only access it could debug async flows or infrastructure in depth. He writes that it was expensive, and that they paid the premium. Devin Review was expensive, and caught some bugs for him. Non-technical staff could coauthor pull requests, while engineers watched the threads, without the staff having to set up local environments. The profile says New York, NY.
How it went
The engineer merges when it is needed. The post does not say how many bugs were merged, and it does not name the company.
Worth knowing
He writes that Devin Review caught some bugs, without saying which. Read-only access is what he describes for deep debugging, not write access.
How to do it
- Let the agent reply in [channel] and write a draft change. Do not merge.
- Give it read-only access if it is to debug. Do not give it the right to ship.
- Let an engineer read the thread and press merge, or leave it.
Try it with Valgfri agent
In [channel], triage this feedback and write a proposed change. Use read-only access only. Do not merge. Do not deploy. An engineer takes the merge after reading [thread].
Replace text in brackets with your own.
Done when. An engineer has read the proposal, and nothing has been merged without that press.
Safety rule. The agent does not merge and does not deploy. A person responsible presses merge.
Read the original
Read the original · @sidstronaut on X ·