Comment by fooster
15 hours ago
I think you need to open your mind to the possibilities? For example:
- scanning logs for errors and
- opening issues which are then auto-triaged and
- PRs are opened for them and auto-reviewed and
- merged (and deployed).
This workflow alone is immensely powerful, and takes alot of burden off the team.
> This workflow alone is immensely powerful, and takes alot of burden off the team.
ITSM those unsupervised workflows are essentially an attempt at purported productivity in the near term at the expense of meaningful incremental long term burden for teams.
The only ostensible benefit is in the eyes of the AI-psychotic tinkerer, who knows no better, or in those of the clout-chasing developer farming likes on their LinkedIn posts.
Really they're not. But it seems you have decided that you, above all, know best.
I started my post with "it seems to me" precisely because I haven't decided that I know best.
A company at the scale to benefit from this almost certainly has some kind of development sandbox environment and/or periodic job runner that's integrated into its environment and maintained by a team, not random Mac Minis.
None of these are things I want or need in the product I maintain with a team, there's really no point to any of this unless you run a vibe coded SaaS (?)
Your non-vibecoded non-SaaS application never has errors?
You want your team spending their time fixing these simple errors? The secret sauce is in the triage. We've adopted solutions alot like this, and now our team spends its time on much more meaningful work.
Why are the errors occurring, though? That's what boring analyse-and-fix addresses, through familiarity, recognition of patterns and "hang onnn..." moments.
It's like your AI agent is just plugging the leaks in the dyke each time, instead of fixing the architecture of the dam.
1 reply →
Yes, I want my team to be deeply familiar with the codebase and every single little bug that needs fixing both trains them and let's them learn a little bit more about the codebase.
They can use agents. Like, team members don't need to be replaced, they can simply use agents when they deem it useful. If they see a trivial bug,they can put their agent on it and go work on something else meanwhile.
None of this requires running it 24/7.
So someone has to be in the office to press the "observe logs" button every 5 minutes?
> scanning logs for errors
famously a good job for a tool that takes 10-50k logs to run out of context and forget what it's doing.
Not really? Imagine for example looking for http status code 500 in an api log over the past hour. The nice thing here is it doesn’t matter if you get them all because it’s reoccur (or not).
> Imagine for example looking for http status code 500 in an api log over the past hour.
1. On a blog that no one visits maybe?
2. It's called a grep
3. For bigger projects it's called sentry
[dead]