One issue is that developers have been trained for the past few decades to look for solutions to problems online by just dumping a few relevant keywords into Google. But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).

▲ ValentineC 9 hours ago | parent | next [-]

> But to get the most out of AI you should really be prompting as if you were writing a formal letter to the British throne explaining the background of your request. Basic English writing skills, and the ability to formulate your thoughts in a clear manner, have become essential skills for engineering (and something many developers simply lack).

That's probably why spec driven development has taken off.

The developers who can't write prompts now get AI to help with their English, and with clarifying their thoughts, so that other AI can help write their code.

▲ pragma_x 9 hours ago | parent | prev | next [-]

You are correct. You absolutely must fill the token space with unanbiguous requirements, or Claude will just get "creative". You don't want the AI to do creative things in the same way you don't want an intern to do the same.

That said, I have found that I can get a lot of economy from speaking in terms of jargon, computer science formalisms, well-documented patterns, and providing code snippets to guide the LLM. It's trained on all of that, and it greatly streamlines code generation and refactoring.

Amusingly, all of this turns the task of coding into (mostly) writing a robust requirements doc. And really, don't we all deserve one of those?

▲ skydhash 12 hours ago | parent | prev [-]

> the ability to formulate your thoughts in a clear manner, have become essential skills for engineering

  The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.

Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.

And

  Some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.

Dijkstra (1976-79) On the foolishness of "natural language programming" (EWD 667)

▲ godelski 11 hours ago | parent [-]

Oh, we're quoting Dijkstra? I'll add one :)

  by and large the programming community displays a very ambivalent attitude towards the problem of program correctness. ... I claim that a programmer has only done a decent job when his program is flawless and not when his program is functioning properly only most of the time. But I have had plenty of opportunity to observe that this suggestion is repulsive to many professional programmers: they object to it violently! Apparently, many programmers derive the major part of their intellectual satisfaction and professional excitement from not quite understanding what they are doing. In this streamlined age, one of our most under-nourished psychological needs is the craving for Black Magic, and apparently the automatic computer can satisfy this need for the professional software engineers, who are secretly enthralled by the gigantic risks they take in their daring irresponsibility. 

  Concern for Correctness as a Guiding Principle for Program Composition. (EWD 288)

Things don't seem to have changed, maybe only that we've embraced that black box more than ever. That we've only doubled down on "it works, therefore it's correct" or "it works, that's all that matters". Yet I'll argue that it only works if it's correct. Correct in the way they Dijkstra means, not in sense that it functions (passes tests).

50 years later and we're having the same discussions