What it struggles with though is the full picture. It's going to solve the problem you put in front of it, but it's not necessarily thinking about how that solution ripples out to the rest of your app. It might not catch that it's breaking something else, or that the logic it wrote technically passes your test but isn't actually doing what you meant. You get the output you asked for, not always the output you needed.

Take a simple example like this: Ask it for a function that filters published items by date and you will get back something like:

function recent<T extends { date: string; status: string }>(items: T[]): T[] {
  return items
    .filter((x) => x.status === 'published')
    .sort((a, b) => b.date.localeCompare(a.date))
}

Clean, correct, does what you asked. What it didn't catch is that three other files in your repo, including a utility module, already have a byDateDesc helper doing the same thing. And separately, that sort has edge cases on entries with the same date in some browsers.

You can get smarter with your prompts, add more context, be more specific and that helps, it genuinely does. Once you're deep into a feature that touches auth, state, three API layers and a caching strategy, the context you'd need to give it to get a truly informed response is basically the same work as just knowing it yourself. The more complex things get, the more it starts losing the thread of what you were trying to do in the first place.

So look, I'm not knocking it. I use it, and I like it. But at the end of the day it's a tool, and you've got to treat it like one. The experience and judgment of knowing why you're building something a certain way, that still has to come from you.