You need to iterate. I've had decent luck having it "fill in the blanks" of a spec, then produce outlines of code with placeholders, then fill in placeholders. Granted, each time with me in the loop to go "hold on, do this slightly differently". So basically treating it as a junior doing the typing and gruntwork, while providing regular feedback on the direction. But you need to effectively constantly refine and narrow down a harness it can be told to work within. But that's often how I work on my own as well, so that's fine.

My problem with this is that the interface sucks and the iteration is slow.

Supposedly copilot x will have a deeper IDE integration and voice commands.

The iteration is faster than asking a person to do the same tasks. I've started toying with the API to address the interface bit, though.

That’s exactly what I did when I’ve experimented with it teaching me how to make a watchOS app (with me having zero iOS and Swift experience), but the issue us that it started to “forget” what we have talked about.

It helped me to bootstrap the project and pointed out at some APIs I needed, but then it was a constant fight for code quality. I wanted proper actor abstraction (because I was dealing with Bluetooth, even if I don’t know the language I can see the patterns) and it just loved to write code in style of some cheapest-grade “how to use CoreBluetooth in Swift for dummies” blog articles.

Were you using vanilla ChatGPT or GPT4?

Vanilla ChatGPT uses a GPT-3.5turbo version with a context window of 4096 tokens. GPT-4 has twice the context window by default, and has a variant with a context window 8x as big.

It's not "8x better" with regards to forgetting what it's doing, but it's substantially better.

Yes, that was GPT-3.5. GPT-4's 25 messages/3 hours ratelimit wouldn't have led us anywhere, even with me doing my own research and compiling larger lists of change requests would've exhausted that very quickly.

Yup, GPT-4 is still likely too expensive for this application at a dollar or two per interaction with the huge context window (or 30 cents-ish with an 8k window). Especially with the tooling not proven for strong interactive use in big codebases.

But we don't need to make much improvement in tooling and economics for it to start to look pretty good.

That's why I have it iterate on a spec first, and then an outline, and then specifics. The point is to have it produce something that narrows the scope so I can feed it specific sections back in again and have it fill in the details.