Posted on
Artificial Intelligence

Artificial Intelligence for Platform Engineering

Author
  • User
    linuxbash
    Posts by this author
    Posts by this author

Artificial Intelligence for Platform Engineering (with Bash-first workflows)

If you’re a platform engineer or SRE, your day is a steady stream of diffs, logs, incidents, and YAML. The problem: this work is text-heavy, repetitive, and time-sensitive. The value of AI here is simple—let it read the text so you can make the decisions. In this post, you’ll turn large language models (LLMs) into practical Bash tools that summarize diffs, triage logs, and audit Kubernetes resources—without ripping out your stack.

What you’ll leave with:

  • A tiny shell wrapper that talks to any OpenAI-compatible API (cloud or self-hosted)

  • 3 drop-in scripts you can use in your local workflow or CI jobs

  • Guardrails for cost, privacy, and reliability

Why AI belongs in platform engineering (now)

  • It’s natively text-in, text-out: diffs, logs, manifests, plans, alerts—LLMs thrive on this.

  • Modern endpoints are fast and cheap enough for routine tasks.

  • You can keep data under your control: self-host open-source, OpenAI-compatible inference servers if needed.

  • The ROI is immediate: faster reviews, clearer incidents, fewer misconfigurations.

Prereqs and setup

Tools we’ll use:

  • curl (HTTP client)

  • jq (JSON CLI)

  • git (for diff examples)

Install them with your distro’s package manager.

  • Debian/Ubuntu (apt):
sudo apt update && sudo apt install -y curl jq git
  • Fedora/RHEL/CentOS (dnf):
sudo dnf install -y curl jq git
  • openSUSE (zypper):
sudo zypper refresh && sudo zypper install -y curl jq git

Configure your AI endpoint:

  • Works with any OpenAI-compatible API (e.g., OpenAI, a self-hosted vLLM, LocalAI, etc.).

  • Set environment variables (use your shell profile or a CI secret store).

# Example: OpenAI (replace with your provider and key)
export AI_BASE_URL="https://api.openai.com/v1"
export AI_MODEL="gpt-4o-mini"
export AI_API_KEY="sk-REPLACE_ME"

Add a reusable Bash function to call the model:

ai() {
  local input="${1:?usage: ai 'prompt text...'}"
  curl -sS "${AI_BASE_URL:-https://api.openai.com/v1}/chat/completions" \
    -H "Authorization: Bearer ${AI_API_KEY:?Set AI_API_KEY env var}" \
    -H "Content-Type: application/json" \
    -d "$(jq -n \
      --arg model "${AI_MODEL:-gpt-4o-mini}" \
      --arg prompt "$input" \
      '{model:$model,
        messages:[
          {role:"system",content:"You are a terse, practical platform engineering assistant."},
          {role:"user",content:$prompt}
        ],
        temperature:0.2,
        max_tokens:800
      }')" \
  | jq -r '.choices[0].message.content'
}

Tip: for determinism in CI, keep temperature low (0–0.2). Clip inputs to avoid high token costs.


1) Summarize risky diffs before you hit “merge”

Skim faster and spot riskier changes (config, secrets, auth, infra). Use this script locally or in CI.

#!/usr/bin/env bash
# pr-summarize.sh — summarize a git diff with risks and actions
set -euo pipefail

range="${1:-HEAD~1..HEAD}"   # e.g., origin/main..HEAD
max_bytes="${MAX_DIFF_BYTES:-30000}"

diff_out="$(git diff --unified=3 --no-color "$range" | head -c "$max_bytes")"
[ -n "$diff_out" ] || { echo "No diff for $range" >&2; exit 0; }

prompt=$(cat <<'EOF'
Summarize this git diff for a platform engineer. Output:

- risk_level: low|medium|high

- summary: one paragraph

- actions: 3-5 concise bullet points
Keep it terse and practical.
Diff:
EOF
)

ai "$prompt"$'\n'"$diff_out"

Usage:

bash pr-summarize.sh origin/main..HEAD

Example output:

risk_level: medium
summary: Updates Kubernetes Deployment resource limits and modifies an auth middleware to skip token validation for health checks.
actions:

- Verify new limits on prod workloads won’t trigger OOMKills

- Confirm health-check bypass is scoped only to /healthz

- Add test ensuring 401 remains for other unauthenticated routes

2) Incident triage from raw logs (structured JSON out)

Turn noisy logs into a quick severity read and next steps. Handy for on-call and postmortems.

#!/usr/bin/env bash
# logtriage.sh — classify and suggest actions from a log sample
set -euo pipefail
file="${1:?Usage: logtriage.sh /path/to/logfile}"
lines="${LINES:-400}"

sample="$(tail -n "$lines" "$file" | sed 's/\x00//g' | head -c 30000)"

prompt=$(cat <<'EOF'
You are an SRE incident triage assistant. From the following log excerpt:

- classify severity: info|warning|critical

- probable_cause: one sentence

- suggested_next_actions: 3 bullets
Return strict JSON with keys: severity, probable_cause, suggested_next_actions.
Keep answers concise and operational.
Log excerpt:
EOF
)

resp="$(ai "$prompt"$'\n'"$sample")"
# Pretty-print or fail if not valid JSON
echo "$resp" | jq .

Usage:

bash logtriage.sh /var/log/myapp/app.log

Example output:

{
  "severity": "critical",
  "probable_cause": "DB connection pool exhaustion after a deployment increased concurrency.",
  "suggested_next_actions": [
    "Scale DB read replicas and reduce app pool size to baseline",
    "Apply connection timeout and circuit-breaker settings",
    "Roll back last release if errors persist >5m"
  ]
}

Pipe this into alert tooling, Slack, or your incident bot to give responders a head start.


3) Ask AI to lint your live Kubernetes resources

LLMs are strong at spotting risky defaults and missing fields. This script fetches objects via kubectl and asks for only concrete, fixable issues.

Requires: kubectl already installed and configured for your cluster.

#!/usr/bin/env bash
# kube-lint-ai.sh — AI-aided review of live K8s objects
set -euo pipefail
ns="${1:-default}"
kind="${2:-deployments}"   # deployments|statefulsets|services|ingresses|pods|jobs|cronjobs|...

json="$(kubectl -n "$ns" get "$kind" -o json)"

prompt=$(cat <<'EOF'
As a Kubernetes reviewer, find misconfigurations and risky defaults in the following JSON objects.
Respond with:

- summary: paragraph

- findings: an array of {resource, issue, why_it_matters, fix}
Only flag concrete, actionable issues. Be concise.
Resources JSON:
EOF
)

ai "$prompt"$'\n'"$json"

Usage:

bash kube-lint-ai.sh prod deployments

Example finding:


- resource: deployment/web-frontend issue: Container runs as root and has no memory limits why_it_matters: Increases blast radius and risks node instability under load fix: Set securityContext.runAsNonRoot=true and add memory/resource limits

Drop this into a CI job to comment on PRs that change Helm charts or Kustomize overlays.


Good practices and guardrails

  • Redact secrets before sending:
redact() { sed -E 's/(api[_-]?key|password|token)=\S+/\1=REDACTED/Ig'; }
  • Clip inputs:
head -c 30000   # keep payloads small and costs predictable
  • Keep it deterministic in CI:
export AI_TEMPERATURE=0   # and set in the payload if you extend the ai() helper
  • Log prompts/responses for audit (watch secrets):
AI_LOG=ai.log
ai() { ... | tee -a "$AI_LOG"; }
  • Self-host if you must keep data in-house:
    • Run an OpenAI-compatible server (e.g., vLLM or LocalAI) behind your VPN and set AI_BASE_URL to that endpoint.

Where to go from here

  • Start with the ai() helper and the diff summarizer. Tweak prompts until it feels native to your workflow.

  • Wire the log triage script into your alert pipeline to give responders structured first steps.

  • Add the Kubernetes linter to CI for config PRs.

Your next step: 1) Install the prerequisites with apt/dnf/zypper. 2) Export AI_BASE_URL, AI_MODEL, and AI_API_KEY. 3) Drop these scripts into your dotfiles or a tools repo and iterate.

Platform engineering is still human work—but with AI reading the text for you, you’ll spend more time deciding and less time deciphering.