[lukaslalinsky]

This depends entirely on how you use said AI. You can have it read code, explain why was it done this or that way, and once it has the context you ask to think about implementing feature X. There is almost no gambling involved there, at best the level frustration you would have with a colleague. If you start from blank context, tell it to implement full app, you are purely just gambling.

[skydhash]

> You can have it read code, explain why was it done this or that way,

The thing is that, once you're experienced enough, it's faster to just glance at the code and have the answer right, instead of playing the guessing game with AI.

> and once it has the context you ask to think about implementing feature X

I'm always amazed at someone using that methodology. When I think about a feature, first is to understand the domain, second is which state I'm like to start from and where all the data are. If you don't get these two steps right, what you'll have is a buggy/incomplete implementation. And if you do get these steps right, the implementation is likely trivial.

[lukaslalinsky]

I'm not sure where is the misunderstanding but your second paragraph is exactly why I ask AI the questions you question in the first paragraph. I ask the AI to do the domain research, see what we are starting from and THEN ask it to think about a feature. They are not really for me, they are for the AI to have good context what we are working on. As you said, the implementation is then almost trivial and the AI is less likely to mess it up.

[skydhash]

The thing is, the domain is often more difficult than the actual implementation. And often only a subset matters (different for each task). So I’m wondering if teaching the AI the correct subdomain is indeed faster than just code the solution.

Also trivial work can benefit the coder. Like a light jog between full sprints for your brain. Reviewing code can be more taxing than writing it as you need to retieve the full context at once instead of incremental steps.