Comment by alwa

I almost entirely agree with this. However, after coding quite a few large projects with LLM assistance, I can say with certainty that there is some form of "art" at play with regards to structuring requests for LLMs.

However, this "art" is not so much about how to present a given request to the LLM, but rather guestimating what the scope of the next chunk of work should be to balance getting as much out of the model as possible while avoiding the machine going off the rails.

Obviously, this is a moving target and different models perform differently for various chunk/scope of work. I look at my successful sessions with LLMs and I'm not sure I'd be able to articulate a clear set of rules to apply here. You just... gradually build a intuition for how much you can throw at the LLM at once.

That being said, I'm pretty convinced at this point that this is a property of the coding assistants as they exist today, and what "working well with LLM assistance" means will keep on changing.

I agree. These skills apply to interacting with any coworker, or any person for that matter.

Indeed. It sounds more like management (Minus the 'people skills' since you don't technically need Claude to like you... yet).

IME "creating a good spec" (and good acceptance criteria) has always been one of the most valuable skills in... well, everything.

The machine is really good at working the spec on its own now, which is amazing, science fiction shit. But you've still got a garbage in, garbage out problem at the end of the day, which is pretty much the only hope we who work in software have of remaining somehow employed.

Having domain expertise isn't specific to using AI.

Not being able to tell when it's hallucinating has led to some very adverse outcomes.