I think the credit belongs to Sascha still. Look at this:
> The agent surfaced a suspicious issue: the anetd pods in our Google Kubernetes Engine cluster were restarting constantly, around 120 restarts per pod over six days, which is almost one crash per hour. Surely, this couldn't be right!
> Sascha dug into the crash dumps. The stack trace pointed to a concurrent map-access panic, multiple goroutines trying to read and write to the same data structure at the same time without proper locking. But the key detail was where the panic happened: inside the Wireguard module of anetd.
AI: Your anted pod is crashing.
Engineer: Looks in the logs and finds a stack trace.
Your agent didn't find the bug. It's really that simple.
therealpygon 2 days ago [-]
100% but it doesn’t benefit an AI company to properly assign credit. Their AI identified a generic problem, not this problem, and then their AI was guided like a child into the correct spot to start searching for a a bug that it eventually traced.
Enginerrrd 2 days ago [-]
> 100% but it doesn’t benefit an AI company to properly assign credit.
Does credibility really mean nothing anymore?
therealpygon 2 days ago [-]
These days that seems to depend on how much that credibility (or lack thereof) nets.
emkoemko 2 days ago [-]
just noticed your comment, yea the title is misleading and the whole article is annoying AI slop
binoct 2 days ago [-]
A new bug appears, it’s in an encryption layer. You solve this by deciding to disable the encryption layer because user experience is better without the errors. You write it up as a recruitment piece for your engineering team.
There may be some good answers and lessons, but they didn’t make it into the article. Saying it’s on a cloud provider’s private network so encryption between your nodes isn’t necessary is a bold choice. Also, what happened to the root cause? Why did it start failing a week ago? Was a downgrade of the offending code not possible?
Not all bug investigations are worth really digging into. Sometimes the right call is to find any fix and move on. But all the nuance, judgement, implications, and lessons learned failed to make it into this post. And they are what make reading incident reports interesting for most engineers.
emkoemko 2 days ago [-]
am i missing something?
'Sascha dug into the crash dumps. The stack trace pointed to a concurrent map-access panic, multiple goroutines trying to read and write to the same data structure at the same time without proper locking. But the key detail was where the panic happened: inside the Wireguard module of anetd.'
this is person right? not a agent... and this whole article seems like it was written by AI...
jbaiter 3 days ago [-]
Isn't this like the #1 problem people have with wireguard? I've had clients with the MTU issue every time I've set it up for more than a few clients. Also how on earth is "connection reset by peer" dreaded?
arm32 2 days ago [-]
Yes, almost without fail—the term "MTU" is included whenever someone mentions an issue with WireGuard. Big ol' nothin'burger here.
aliasxneo 3 days ago [-]
This article reeks of desperation. I'm pretty sure Lovable's days are numbered.
soupdiver 3 days ago [-]
hate how it all has the same tone now
owenthejumper 3 days ago [-]
came to say this. it's the AI writing cadence, I can smell it from 1000ft:
- Lots of "The" headings
- Always "why it matters"
- Machine gun style cadence of short sentences
kandros 3 days ago [-]
convergence that we see in all kind of medium when some things are considered “working better” (true or not)
AI writing takes these to an extreme but we have see the same happening everywhere even before AI
i_think_so 3 days ago [-]
I hate that AI has stolen my emdashes and I can't use them without looking like slop. But I will die defending markdown as my preferred note taking format. They're not taking that away from me.
IanCal 3 days ago [-]
I felt like this with the word delve. Seemed like nobody had ever heard the word before, and that the only possible way it’d be written was if an llm did it - but it’s just a nice word.
SoftTalker 3 days ago [-]
Delve was used a lot in corporate writing. A lot of the so-called "whitepapers" that businesses like to publish to show how smart they are were ingested in training models.
sleepybrett 3 days ago [-]
the premiere golang debugger is called delve. Also you must not hang out w/ many ttrpgers.
IanCal 2 days ago [-]
I mean I use it and then it seemed like everyone was acting like it it was a weird llm only word.
yomismoaqui 3 days ago [-]
How about not caring about what people on the internet say about your writing using emdashes?
They are a false positive signal for identifying AI texts anyway.
i_think_so 2 days ago [-]
It's not what they say, it's what they click on.
Unfortunately, in a place like this, if a bunch of people falsely accuse you of being a slop spreader your karma drops like a rock.
Can you imagine how hard it is to start up a new Reddit account lately? Even in a small and isolated community of niche enthusiasts just getting to the point where your posts aren't auto-modded takes serious effort. One stray emdash and you can lose it.
Ask me how I know.
Oh yay, I'm in HN jail again. "You're posting too fast." Faster than once per 30 minutes? Sigh.
g8oz 3 days ago [-]
Without markdown I don't even know who I would be anymore.
wolttam 3 days ago [-]
Em dashes aren’t stolen, it’s still clear from the overall voice of the text if it’s AI written or not.
At least, in reasonably long sections of text. I find it can be hard to tell one way or the other in shorter texts (like comments)
i_think_so 3 days ago [-]
Just on HN alone I think I've seen roughly 3948538902748750897520938 mentions of emdashes when others were complaining about slop in the past 2 months. It might as well be the unofficial slop logo. Folks are treating it like a dead giveaway.
I feel like a school friend of mine has been taken from me.
peyton 3 days ago [-]
It’s just people who don’t read books outing themselves. Ignore.
dwedge 3 days ago [-]
Even bookz aee ruined for me now. I was reading careless people and hate all the emdashes even though in a book it's just normal
twoodfin 3 days ago [-]
The real dead giveaway is that the writing is bad.
I can't tell if my main source of hate there is the homogeneity itself, or that it's excessively marketing-flavored (fluffy and aggrandizing, mere inches from "our incredible journey..." at all times).
_caw 2 days ago [-]
A dead simple, deterministic threshold alert on the pod restart metric in any monitoring tool could also surface this same issue.
In fact, it happened to me today at work!
parliament32 3 days ago [-]
This piece might be a record for how quick it took me to smell the AI-tone and close the tab.. one paragraph! I'm sure it's an interesting bug but I can't stomach reading any more slop.
cootsnuck 3 days ago [-]
I think "AI-tone" is a much better way to characterize this stuff than accusing people of using AI. The problem has always been the same. Putting out slop feels disrespectful to the people you want to read/watch your stuff.
Makes me think of how pre-chatGPT I still could barely handle most recipe blogs because of their well known attempts at "filling space". And yea the problem is significantly magnified now everywhere else.
Anyway, my point is, whether or not someone uses AI is almost secondary in a way (even though it can seem pretty obvious to most of us when it's being used). All that matters is if the writing seems like it cares more about throwing words at people instead of actually conveying its points in a way to elicit understanding.
emkoemko 2 days ago [-]
yup, if you can't be bothered to write a article i can't be bothered to read it... i don't get why people are so lazy
SaucyWrong 3 days ago [-]
Came here to say this. It’s a shame that I’m so exhausted reading slop that I’m probably missing many interesting stories from the industry
bzmrgonz 2 days ago [-]
Which agent did you guys let loose on clickhouse log server??
rachidsahde 2 days ago [-]
[flagged]
frameworkeGPU 2 days ago [-]
[dead]
siliconc0w 2 days ago [-]
[flagged]
Aachen 3 days ago [-]
A bug in Wireguard? What did Google change, since it affects only them? Any lessons learned about modifying cryptographic software?
...
Skipping past the investigation bit (minimising my daily slop intake), it's a wrong MTU value causing failing connections when Wireguard is disabled:
> When we disabled WireGuard, we expected the configuration to change to use the full 1500 bytes. However, some nodes in the cluster hadn't been restarted [and were] using the old 1420-byte MTU.
> [paraphrased] This particularly affected Valkey connections because they were distributed across nodes with mismatched MTU settings. So your API pod might not connect. The fix was rerolling all the nodes to get a consistent MTU configuration
Aachen 1 days ago [-]
Three downvotes but not one comment. Should I just not post informational comments here or what's the message these faceless votes are trying to get across?
Rendered at 02:59:43 GMT+0000 (UTC) with Wasmer Edge.
> The agent surfaced a suspicious issue: the anetd pods in our Google Kubernetes Engine cluster were restarting constantly, around 120 restarts per pod over six days, which is almost one crash per hour. Surely, this couldn't be right!
> Sascha dug into the crash dumps. The stack trace pointed to a concurrent map-access panic, multiple goroutines trying to read and write to the same data structure at the same time without proper locking. But the key detail was where the panic happened: inside the Wireguard module of anetd.
AI: Your anted pod is crashing.
Engineer: Looks in the logs and finds a stack trace.
Your agent didn't find the bug. It's really that simple.
Does credibility really mean nothing anymore?
There may be some good answers and lessons, but they didn’t make it into the article. Saying it’s on a cloud provider’s private network so encryption between your nodes isn’t necessary is a bold choice. Also, what happened to the root cause? Why did it start failing a week ago? Was a downgrade of the offending code not possible?
Not all bug investigations are worth really digging into. Sometimes the right call is to find any fix and move on. But all the nuance, judgement, implications, and lessons learned failed to make it into this post. And they are what make reading incident reports interesting for most engineers.
'Sascha dug into the crash dumps. The stack trace pointed to a concurrent map-access panic, multiple goroutines trying to read and write to the same data structure at the same time without proper locking. But the key detail was where the panic happened: inside the Wireguard module of anetd.'
this is person right? not a agent... and this whole article seems like it was written by AI...
AI writing takes these to an extreme but we have see the same happening everywhere even before AI
They are a false positive signal for identifying AI texts anyway.
Unfortunately, in a place like this, if a bunch of people falsely accuse you of being a slop spreader your karma drops like a rock.
Can you imagine how hard it is to start up a new Reddit account lately? Even in a small and isolated community of niche enthusiasts just getting to the point where your posts aren't auto-modded takes serious effort. One stray emdash and you can lose it.
Ask me how I know.
Oh yay, I'm in HN jail again. "You're posting too fast." Faster than once per 30 minutes? Sigh.
At least, in reasonably long sections of text. I find it can be hard to tell one way or the other in shorter texts (like comments)
I feel like a school friend of mine has been taken from me.
and the comments above it
In fact, it happened to me today at work!
Makes me think of how pre-chatGPT I still could barely handle most recipe blogs because of their well known attempts at "filling space". And yea the problem is significantly magnified now everywhere else.
Anyway, my point is, whether or not someone uses AI is almost secondary in a way (even though it can seem pretty obvious to most of us when it's being used). All that matters is if the writing seems like it cares more about throwing words at people instead of actually conveying its points in a way to elicit understanding.
...
Skipping past the investigation bit (minimising my daily slop intake), it's a wrong MTU value causing failing connections when Wireguard is disabled:
> When we disabled WireGuard, we expected the configuration to change to use the full 1500 bytes. However, some nodes in the cluster hadn't been restarted [and were] using the old 1420-byte MTU.
> [paraphrased] This particularly affected Valkey connections because they were distributed across nodes with mismatched MTU settings. So your API pod might not connect. The fix was rerolling all the nodes to get a consistent MTU configuration