Just look at what they are stating:

> that did exactly what I needed

> I have zero knowledge of k8s, helm or configmaps.

Obviously this is not anything resembling engineering, or anything a respectful programmer would do. An elevator that is cut lose when you press 0 also works very well until you press 0. The claims of AI writing significant chunks of code come from these sort of people with little experience in programming or engineering in general, SPA vibe coders and what not. You should tremble at the thought of using any of the resulting systems in production, and certainly not try to replicate that workflow yourself. Which gives you a sense of how overblown these claims are.

Because after 25 years of coding and a dozen infrastructure description languages I know that you test your code and you get someone expert in the field to look at your PRs.

LLMs are _really_ good at writing infra code if you know how infra works, believe it or not. And the ultimate responsibility still lies in human beings for code ownership.

* Infra code description languages like Terraform and K8s/helm spec files are like magic; they get 90% of the code right 90% of the time. In my experience that's about half of the work; the other half is spent debugging and correcting details that matter, but still applies to the code that I write myself.

* SQL works almost as good. It's especially useful when you need to generate queries with long lists of fields and complex query criteria. Give it a schema and let it rip.

* Python code works reasonably well. If your description is terse and clear it will generally do the right thing. It has a knack for being excessive in comments and will sometimes do things in ways that feel unnatural, but business code will be as good as the context that surrounds it. For boring, repetitive tasks like setting up program args, annotating types, and writing generic request/response cycles with common frameworks it will do boring old vanilla code. You'll likely want to touch it up and adapt it to your personal preference.

* Debugging is very much or miss. It has been absolutely fantastic at troubleshooting failed and stuck k8s jobs and service configuration issues, having no qualms about creating its own shell or python scripts to investigate ports or logs, and writing JSON parsing scripts that are snoozefest for a human to write. The regexes that I'd barely be arsed to write to parse enormous logs it writes trivially. For business logic, the more convoluted your logic the harder the time it will have, and for most debugging issues I prefer to let it run and list some hypotheses and potential issues and my intent is to learn and understand the problem myself deeply before committing to a fix.