When I first brought AI into my Kubernetes workflow, the problem was not that it could not write YAML. The problem was that it could write YAML after looking at only one file. It could quickly produce a Deployment without knowing whether the service belonged behind Argo CD, where its Secret came from, or whether the public entry point also needed work outside the cluster.
I stopped pasting a request and a few configuration snippets into a chat. Instead, I let AI start with the GitOps repository. That repository is already where I maintain the cluster, and its directories, README files, and configuration fill in much of the context that otherwise lives only in my head.
Give AI a map first
My repository does not try to be clever. The point is that someone can start at the entry point and follow it to the deployment content:
gitops/
├── bootstrap/ # Things needed only for the initial installation
├── clusters/apps/ # Argo CD Applications
├── apps/ # Service manifests and values
├── terraform/ # Cloud resources outside the cluster
└── docs/ # Architecture and operating notes
With that map, “add a service” is no longer just “add a Deployment.” AI can first find the Application, Kustomization, values, Secret reference, and Terraform that the service may touch, instead of guessing at a configuration that looks plausible but does not connect to the rest of the system.
For example, a root Application has one straightforward job: it points at the directory in Git that defines the child Applications.
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: platform-root
namespace: argocd
spec:
source:
repoURL: <git-repository-ssh-url>
targetRevision: main
path: clusters/apps
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
Ask it to repeat the plan before editing
I no longer ask AI to edit files as the first step. I ask it to read the relevant directories and explain the current deployment path, the files a change would affect, missing dependencies, and what should be checked afterwards.
This is similar to confirming that a teammate understood the task. If the answer mentions only an application YAML and skips Argo CD or external IaC, I know it has not read enough. If it can separate the desired state in Git from facts that need checking in the cluster, then we can discuss the change.
The instruction I reuse is short:
Read the IaC, Argo CD Applications, Kustomizations, and documentation related to this request.
First explain the current design, affected files, dependencies, risks, and validation steps.
Do not read or request Secret values, private keys, tokens, IP addresses, internal domains, or Vault paths.
Until I confirm, do not edit files or take any action against the cluster.
It is a little slower than saying “deploy this service,” but it cuts down on back-and-forth. The plan also remains available when I review the diff later and want to check whether the original assumptions held up.
Argo CD gives dependencies a place to live
Some things cannot be applied together. A CRD and its operator need to exist before resources that use them make sense. If the Secret-delivery path is not ready, an application can have valid YAML and still fail to start. I do not rely on repeatedly explaining this in a prompt; the layers and synchronization order are already encoded in the Argo CD Applications.
That means AI reads more than a component list. When it suggests changing a service, I ask whether it is only an application change or whether it also touches an entry point, secret delivery, or a resource outside the cluster. The answer determines what I check next.
Secret examples stop at the reference layer. This is enough to show what a workload depends on without disclosing a value:
envFrom:
- secretRef:
name: app-runtime-secrets
Desired state in Git, facts in the cluster
AI can read configuration, compare a diff, render Kustomize, and help turn checks into a clear list. None of that requires administrator access. I keep repository access and live-cluster observation separate.
The repository answers what I want the system to look like. When I need to inspect the cluster, I provide only narrow, read-only observations: whether an Application is synchronized, whether a rollout completed, whether Events contain an error, and whether a Service has usable endpoints. AI can see the outline of a problem, but it cannot run an arbitrary shell, read Secrets, enter a Pod, or restart a workload.
That limitation makes diagnosis more orderly. It can first say, “the version in Git changed, but the rollout is not ready yet,” and I decide whether the next manual action is justified. Any lasting change still goes back through Git, review, and Argo CD reconciliation.
Writing comes last
After a change is complete, AI can help turn the work into an article. By then it has seen the actual file layout, diff, and validation results, so it can outline the background, reason for the change, implementation order, and lessons learned. I remove details that should not be public and make sure an article does not turn a one-off troubleshooting command into general advice.
I like this order: make a change that Git and Argo CD can verify, then write about it. The article is no longer a Kubernetes tutorial assembled from memory. It is a record of real maintenance work.
Here, AI is more like a collaborator who knows the repository than an authority over the cluster. It saves me context switching and catches dependencies I may have missed. The change itself still has a source of truth, a review, and a security boundary. That is the point at which I am comfortable using it in everyday infrastructure work.