1. It is what you do after the prompt: scan diffs in real time and hit the escape key at the slightest sign of trouble.

2. Deep questioning. Constantly probing the assistant: what does it think it is trying to achieve, why did it just make decision X, is there a better way, what does it think the current constraint is?

3. Fighting drift. Knowing that the model will always try to regress to the mean of the training corpus, and constantly being on guard against that drift.

4. Keeping state in your head, because the model cannot. It is up to the programmer to remeber what connects to what else in what way and why.

▲

Paarthmj 8 hours ago | parent | next [-]

Thanks a bunch Adam! I think the fighting drift point is super interesting, haven't heard that often!

	▲	PaulHoule 8 hours ago \| parent [-]
		in general the context goes bad if it gets long enough. if it seems to be losing the thread and you are fighting with it and going in circles: STOP! You might think it would be useful to keep going in one conversation but unless your next task is "do what we just did in this other part of the code" it makes sense to start new conversations for new tasks.

▲

toomuchtodo 5 hours ago | parent | prev [-]

Are there any artifacts that you could recommend for your fourth point to document the state? An Architecture Decision Record (ADR) or its equivalent perhaps?

https://news.ycombinator.com/item?id=35308838