Tried it for a few weeks. It's fine for boilerplate, but I wouldn't trust it for anything serious. The reliability isn't there yet.
It'll confidently write a bash script that `rm -rf`s something it shouldn't, or a Kubernetes manifest with a typo in the `imagePullPolicy` that'll waste an hour debugging. You still need to know the domain inside and out to catch its mistakes, which begs the question: why not just write it yourself? It's another layer to debug.
For example, asked it to write an Ansible handler to restart a service after a config change. It gave me this:
```yaml
- name: restart nginx
systemd:
name: nginx
state: restarted
daemon_reload: yes
listen: "config file updated"
```
Looks plausible. But `daemon_reload: yes` is the default, and more importantly, if you're using a containerized deployment, this is useless. It doesn't understand the actual production context. It's just stitching together common patterns from its training data.
Spend more time reviewing its code than I would writing from scratch.
If it ain't broke, don't 'upgrade' it.
Exactly. The confident mistakes are the real problem.
Tried it for Salesforce APEX triggers. It'd get the basic syntax right but miss critical governor limits or bulkify patterns. You end up fixing its code AND your own trigger logic because you have to check everything twice.
When you said "another layer to debug" that hits it. It's not just checking its work, it's debugging its misunderstanding of your environment.
null