I think we all recognize that AI changes the way we produce code.
To me it seems it wides the gap what a single dev can reach in terms of output.
The HN discussions shows mixed feelings about this:
news.ycombinator.com/item?id=4550...

What are your thoughts?

Using Coding Agents in combination with software engineering best practices: Unit testing, concept-first, version control, code review, manual testing, etc. for higher output.

⚠️ Recommendations:
At least run: npm/yarn/pnpm audit

npm config set ignore-scripts true --global

What else?

Does anyone know of any specific tooling to check if impacted?

Same attacker as nx?
HackerNews: news.ycombinator.com/item?id=4526...

🗓️ 17 Sep: attack #Shai-Hulud / #CrowdStrike / #tinycolor
Self-replicating worm 😱 started by briefly infecting tinycolor and packages by vendor CrowdStrike. Exposes code and secrets via GitHub and tries to propagate to other packages via npm tokens. Now impacts nearly 500 packages.

🗓️ 8 Sep: #chalk, #debug-js and other packages by maintainer #qix (junon) compromised. They handled this very transparently 👍️

HackerNews: news.ycombinator.com/item?id=4516...
CVE-2025-59144: github.com/advisories/G...

Here is the link for opting out

www.linkedin.com/mypreference...

The switch was really easy.

The only customization I did was to enable the constant reminder of my cloud account and node.js version.

Having the time displayed as part of the prompt also turns out useful when scrolling back up later.

github.com/schnatterer/...

Anyway, here is my workaround (to be executed on the host) 😱

sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.slapd

Anyone ever had similar problems and have a better solution?

Presumably, this is a limitation of k3d running in a container itself, leading to kubelet lacking privilege to modify AppArmor profiles on host.

Eventually found out that my host system has an AppArmor profile for slapd.
However, I was unable to ignore it via k8s' annotation or securityContext setting for unconfined AppArmor profile.

My LDAP pod failed to start with permission denied errors when the startup script used slapadd. These would not go away, even as root.

Anyway, here is my workaround (to be executed on the host) 😱

sudo apparmor_parser -R /etc/apparmor.d/usr.sbin.slapd

Anyone ever had similar problems and have a better solution?

Presumably, this is a limitation of k3d running containerized itself, leading to kubelet lacking privilege to modify AppArmor profiles on host.

My LDAP pod failed to start with permission denied errors when the startup script used slapadd.

Eventually found out that my host system has an AppArmor profile for slapd.
However, I was unable to ignore it via k8s' annotation or securityContext setting for unconfined AppArmor profile.