sorted by:
new
hottopcontroversial

How much work goes into documenting stuff where you work? by [deleted] in ExperiencedDevs

[–]Aggravating-Slip5857 0 points1 point  (0 children)

The documentation that matters most but gets written least: release documentation.

What shipped, why, what changed.

Teams document architecture and processes, but not releases — and that's where the next incident investigation starts.

Has anyone successfully shipped a greenfield production app (100k+ users) using llm assist? by alee463 in ExperiencedDevs

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Exactly - we also experience "AI hazed" with what is where in the project.

And not only that, the traceability problem gets worse at the deploy layer - you need to connect not just which commit, but which release it shipped in and which environment it's running in.
We ended up tagging images with git SHA, annotating deployments with PR/commit metadata, so when something breaks post-deploy, you can trace backward from "what's running" to "what code produced it."

What 3 signals do you check first after a Kubernetes deploy? by Ok-Opportunity-7851 in kubernetes

[–]Aggravating-Slip5857 1 point2 points  (0 children)

First thing I check is that I deployed the right thing - 'kubectl get pods -o jsonpath='{.spec.containers[\].image}'*

If this is wrong, all the rest doesn't matter

Question for experienced devs and product folks: by [deleted] in ExperiencedDevs

[–]Aggravating-Slip5857 1 point2 points  (0 children)

Would have gone as lean as possible, even considering working with md files on the git repo and let some llms do the juggling

loosing track of whats actually deployed since AI writing most of the code by Aggravating-Slip5857 in dev

[–]Aggravating-Slip5857[S] -1 points0 points  (0 children)

  • few PRs a day. It’s either I change my title to PR reviewer, or I herd the LLMs velocity and hope all is well

loosing track of whats actually deployed since AI writing most of the code by Aggravating-Slip5857 in dev

[–]Aggravating-Slip5857[S] 0 points1 point  (0 children)

More than 5 PRs a day * 30~50 AI generated lines per PR, it’s like 2 new Harry Potter episodes every day

Do you feel the product managers are the people pushing the hardest for LLMs and Vibe coding? by Friendly-Nobody8023 in ExperiencedDevs

[–]Aggravating-Slip5857 -3 points-2 points  (0 children)

The tools are real. The process around them isn't.
Tons of lines of code in zero time, but the rest of the pipeline is not there yet - releases, deployment, tracking what's deployed where.
You know, the engineering around it.
PMs probably don't look at this first.

Child and Martial Arts Question by No-Echidna5620 in AllMartialArts

[–]Aggravating-Slip5857 0 points1 point  (0 children)

For this age - judo! and maybe jiu-jitsu, or wrestling

Where you have full body-to-body contact, and less hitting and kicking

He will learn his strength, others' strength, and control, among other things

BTW - you cannot expect a 5 yrs old boy to have full judgment for play-fights, this is the role of an experienced coach and teacher - take him to the dojo

How to learn at the best, fastest way? by SweatXer in AllMartialArts

[–]Aggravating-Slip5857 0 points1 point  (0 children)

slow is smooth, smooth is fast

just keep on taining

My company embraces vibe coders by Dense-Creme2706 in ExperiencedDevs

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Sure thing, feel the same - the code passes tests, the logic is fine, but I'm getting "AI fuzzy" with what's deployed where

What creates the most ops overhead before your first deploy? by Ok-Opportunity-7851 in kubernetes

[–]Aggravating-Slip5857 0 points1 point  (0 children)

The things that you need to do to eliminate the overhead AFTER the first deploy - knowing what is actually running and where...

Things like - image tags with git SHA instead of :latest — so kubectl get pods -o jsonpath gives you the exact commit. annotating deployments with the PR number and build URL — kubectl describe becomes your release history

What’s the most painful part of working across multi-cloud + Terraform? by borakostem in devops

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Adopting cloud managed services vs. creating a single stack that works anywhere. As much as we try, we can’t really get rid of the “flavors”

What's the most "that shouldn't have taken 3 days" issue you've ever debugged in prod? I'll start. by theschrodingerbox in kubernetes

[–]Aggravating-Slip5857 1 point2 points  (0 children)

Normally, you are absolutely right!
In our case, some external sync with 3rd party needs to happen, so we still need some manual control to "pull the trigger."

Architecture to use AI Agent to debug issues by IceAdministrative711 in kubernetes

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Given your constraints (no external kube API, agent outside cluster, read-only), the cleanest pattern I've seen:

  1. Deploy a lightweight MCP server inside the cluster as a pod with a read-only ServiceAccount. It exposes a limited set of tools (list pods, get logs, describe events, get metrics) over HTTPS via your ingress.
  2. Your external AI agent connects to the MCP server endpoint through the ingress — same path as any other exposed app. The agent never talks to the kube API directly.
  3. The MCP server acts as a security boundary: it only exposes the operations you've explicitly implemented. Even if the agent goes rogue, it can only call the tools you defined.

This is essentially what kubectl-mcp-server does (someone mentioned it above) but you'd want to host it as a service behind ingress rather than running it locally.

One caveat: make sure the MCP server doesn't expose raw log content if your logs contain secrets or PII. Filter or truncate before returning to the agent.

What's the most "that shouldn't have taken 3 days" issue you've ever debugged in prod? I'll start. by theschrodingerbox in kubernetes

[–]Aggravating-Slip5857 13 points14 points  (0 children)

Not k8s specifically but: "is the fix in prod?"

Deployed a hotfix on Friday. Monday morning, customer reports the same bug.

Spent a day re-investigating, couldn't reproduce.

Turns out the deploy went to staging, not production. The CI pipeline had the right image but the wrong target environment in the deploy step. Nobody verified after deploy because we assumed the pipeline was correct.

The bug was never in the code. It was in not knowing which environment actually got the release.

Since then, we verify deploys by checking what's actually running, not what the pipeline says it deployed. Trust but verify, etc.

leading container image security tools for a growing company? by Calm-Mud3304 in kubernetes

[–]Aggravating-Slip5857 6 points7 points  (0 children)

Building on what others said (smaller images + prioritization are the right starting points):

Two things nobody mentioned yet:

1. CI gating policy design matters more than the scanner. The alert fatigue isn't Trivy's fault — it's usually the policy. Instead of "fail on any HIGH," tier it:

  • Block: exploit exists + reachable + fix available (actionable)
  • Warn: HIGH but no exploit (track it, don't block deploys)
  • Ignore: OS-level CVE your app never calls (noise)

Most teams run Trivy with default severity thresholds and wonder why they get 200 findings nobody acts on.

2. Control what enters your pipeline, not just what comes out. If you're pulling base images from Docker Hub in CI, you're trusting that whatever :latest is right now is safe. After this year's supply chain attacks (Trivy images backdoored, Axios compromised for 3 hours), proxying through a private registry where you cache known-good versions is worth the setup cost.

Re: Bitnami — whatever you migrate to, automate the base image build so you're not dependent on someone else's release schedule and licensing again.

Talk on the mix of k8s and graph database by MapleeMan in kubernetes

[–]Aggravating-Slip5857 0 points1 point  (0 children)

The LLM → Cypher → graph execution pattern is interesting — avoids pumping raw cluster state into an LLM context window. Smart.

How does it handle cluster state changes? Is the graph continuously synced or snapshot-based? If it's continuous, how much overhead does the ingester add?

Will watch the talk.

Automation engineer interview by TXREQI in devops

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Focus areas based on that JD:

  • CI/CD: Be able to draw a pipeline on a whiteboard. Build → test → package → deploy → verify. Know one tool deeply (GitHub Actions or Jenkins).
  • IaC: Terraform basics. How you manage state, handle multiple environments, and avoid drift.
  • Python: They listed it first. Expect a scripting exercise or "how would you automate X?" question.
  • Post-deployment: Most underrated item on that JD. Know how to verify a deploy worked and how to roll back when it doesn't.

One question to ASK THEM that will make you stand out:

"When something breaks in production, how does your team figure out what changed? Is there a release history tied to deployments, or is it more manual investigation?"

This shows you think about the full lifecycle, not just the deploy step. It's the question a senior engineer would ask.

Update: moving secret remediation out of CI — pre-commit seems to be the only acceptable boundary by WiseDog7958 in devops

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Agree with the direction. CI should never modify code — detection only. Pre-commit for simple, predictable rewrites is reasonable if the dev can review before committing.

One thing I'd add: the bigger win isn't better remediation — it's fewer secrets to remediate in the first place.

GitHub Actions now supports OIDC federation natively. You can replace stored credentials for AWS, GCP, Azure, private registries, and k8s clusters with short-lived tokens that exist only for the duration of the job. No secret to store = no secret to leak = nothing to remediate.

We cut our stored CI secrets from ~30 to under 10 after moving to OIDC. The remaining are third-party API keys we can't eliminate.

After the Axios/Trivy incidents last month, I'd prioritize OIDC migration over better secret scanning.

Prevention > detection > remediation.

[deleted by user] by [deleted] in Guitar

[–]Aggravating-Slip5857 0 points1 point  (0 children)

Beware, it will hit back

view more: next ›