[fooster]

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.

[airstrike]

> 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.

[fooster]

Really they're not. But it seems you have decided that you, above all, know best.

[airstrike]

I started my post with "it seems to me" precisely because I haven't decided that I know best.

[hjkl0]

> 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.

Truly open minded

[airstrike]

I'm open minded, I just haven't seen evidence to the contrary. Speaking as someone who's spent an ungodly amount of time in claude code

[closeparen]

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.

[lionkor]

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 (?)

[fooster]

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.

[dingaling]

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.

[fooster]

There are many sources of boring predictable errors which nonetheless are easy to miss and easy to fix. API validation errors for example.

[lionkor]

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.

[theshrike79]

Your non-vibecoded non-SaaS application never has errors?

[lionkor]

It doesn't have a central stream of logs if it's running on an isolated system without internet, so while there are errors, you can't have a 24/7 Claude looking at it. At my previous role, similar issue, you can't put Claude 24/7 on a PC with patient data on it. Just not happening.

[troupo]

> 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.

[fooster]

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).

[troupo]

> 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

[fooster]

Dude, really open your mind and stop arguing mindlessly. We're using this to great success on a serious sass product with hundreds of thousands of users. I'm not some AI influencer, or blowing smoke.

The source of errors can be whatever you like. Sentry, grep, whatever. Its not the point. The point is that many of these errors are real issues, and can be fixed automatically and safely by agentic systems. It really saves time, and work by our team leaving them to actually concentrate on the thing that delivers real value.

[troupo]

You started with "scanning logs for errors" with LLMs which is one of the most stupid things could do with LLMs on a "serious SASS product with hundreds of thousands of users" (aka logs easily in gigabytes to hundreds of gigabytes per minute).

But now it's suddenly not "we use LLMs to scan logs for errors", but "we use actual tools to find erots in logs, but then just hand them off to an LLM and hope for the best".

As in "let's repeat what @troupo said but pretend it somehow goes against what @troupo said" lol

[mystifyingpoi]

None of this requires running it 24/7.

[theshrike79]

So someone has to be in the office to press the "observe logs" button every 5 minutes?

[mystifyingpoi]

Alerting on level=ERROR doesn't require agentic monster systems burning tokens constantly.

[theshrike79]

No, but the agentic monster system can have the relevant code checked out, manuals and runbooks analyzed, the error investigated and a fix proposed by the time the on-call engineer gets up from bed, grabs a Red Bull from the fridge and logs in to their work computer.

Then they have a starting off point to see if the agent was correct or not. If not, they lost maybe 2 minutes of reading. If yes, they can go "yea, push the fix and monitor", put down the Red Bull and go back to bed.