This is how I compare Laplace Conjecture with AI Hype Conjecture

K, I am more and more becoming a believer that if we do not learn AI we are at a disadvantage. Since joining ChatGPT Plus, I’ve had to confront many personal biases to maximize my effectiveness.

I refused to upgrade my big-button cell phone until finally it prevented me from doing what I wanted to do. The same for my AI subscription. I had reached a point that no AI or free AI limited, me.

I have 40 years of learning to apply when I use AI. I find it difficult to direct its actions toward my goals, as it asserts its own will. Microsoft unilaterally determines this approach, removing your choice.

My quest at the moment is to learn how to talk to AI. If you could follow my problem-solving chats with ChatGPT, you would find the response. STOP: Tell me how to tell you how I want our interaction to occur. Since getting a subscription, I have discovered there are personal settings that i am using more often.

Learning how to interact with AI appears to be a self-learning exercise. If you find someone willing to share their insight, it can make the interaction more fruitful. I wish I could still have my big button cell phone. That is not reasonable, but then again I liked wooden hockey sticks. You bring one of those into a dressing room today, no one will sit next to you.

Bt the way. Great topic. I only wish it was with a bunch of folks around a table drinking coffee and trying to solve world hunger.

P.S. I even used AI to proof this document so these are not my words. No that statement is not true. AI doesn't like my grammar or lack of spelling skills. My grade 10 teacher had the same AI issue.

I'm learning as I go, still not sure how optimal I'm being, but I noted some (seemingly/hopefully) plausible suggestions somewhere in an element14 discussion comment but can't remember where. 

Anyway, long story short, it was along these lines (and this is mostly just personal perspective, others will have better ideas I'm sure):

(1) There is a dichotomy, on the one hand you want to provide decent explanation of your goal and objectives, but on the other hand you also want to split up things so the AI is not overwhelmed with unnecessary detail in parts, so sometimes more than one AI session could be helpful

(2) If you're coding, then really split up your files (or tell AI how to architect) because otherwise you will find it hard to delve into the results, and AI may make more mistakes later

(3) Try to speed up the compile/build and the testing, because you will be the slow part of the loop, not the AI. Heavily prefer command-line for all this (get the AI to help make it all command-line driven if you don't have prepared makefiles etc).

(4) For hardware, consider describing what you want in text, not diagrams or schematics, and don't ask for schematics, but ask for descriptions. I appreciate this might become old-fashioned very quicky, since AI capabilities are improving rapidly

(5) Ask for tools/libraries/architecture/languages advice from the AI, don't assume that the tools you were planning to use were the best idea. If it suggests a different language or library for instance, then I will strongly consider it for coding even if it means having to learn it slightly first (most languages have the same concepts so this doesn't take long)

(6) Try to make the AI create tests or stub out things, to reduce the amount of effort when it comes to manual testing. Sometimes the AI will automatically run tests if it can (e.g. I believe Chat GPT will prepare and then run some Python code itself on it's own before providing you with the code) - but AI can go further of course, actually hooking in to real hardware so the user doesn't need to be the tester, the AI can do that and retrieve results from the real testbed, and iteratively improve things with no user interaction.

(7) I find I get quite good results if I am very specific in describing behavior that is important to my needs, but deliberately give some free reign in other areas where I don't care as much. But see point 8 next.

(8) Definitely inspect the code, not necessarily for bugs (the AI can identify bugs from described symptoms by itself usually) but to see how things were implemented, and push back for rewrites if it took a lazy approach. With hindsight, you'll see the areas where perhaps one should have been more specific in the request to the AI. For example, if you don't specify a desired data structure, it may use something entirely different. It is important to push back, because otherwise you may end up with code you cannot easily maintain.

(9) Although AI is excellent at understanding when you're referring to something you have already referred to in a slightly different way in the past, recently I have been trying to be a lot more strict with my terminology. You can make up the terminology as long as it is consistent. For example, if there are a load of items in a system I probably would give them specific names or acronyms and their ports specific names too, and then refer to them consistently.

(10) This is quite hard, but in general I try to not lock myself down too much, e.g, just because I cannot envisage a need or a scale for something, doesn't mean the code shouldn't be "ready" for it, thus I tell the AI things that might be needed in the future, but not needed now. I don't succeed always, because I get ideas and feature creep temptations later (not as much as an issue with hobby stuff of course).

(11) Write extremely long prompts if necessary, For instance, it shouldn't be unusual to spend the day just writing the prompt, before even submitting that to the AI. Some prompts can be a dozen pages of one's thoughts/notes, even for hobby projects.

(12) Ignore 1-11 as necessary : ) All is in flux, and you'll come up with way better guidelines for yourself over time - plus I am sure there are probably good guides elsewhere. I like "Code" magazine, I am learning a lot from that, well worth the subscription for the paper+digital copy.

shabaz said:

11) Write extremely long prompts if necessary,

I use a different technique (at this moment :) . Have a conversation in short sentences - one-liners. Precise when needed, fuzzy if I don't have an idea myself yet.

I like that incremental approach.

(13). If you get an error, just paste in AI and ask what the likely causes (and maybe solutions) are. It's often right.

Even when its own code throws a compile- or run-time error, pasting that error results in better/working code.

Less is more, so to speak.

There's one thing that is guaranteed. It will ALWAYS respond to you, no matter what. No silent treatment. No ghosting etc.

I find that I am starting to use key action words, no matter the task. "Delve/Dive into...", "Expand on this...", "Explore...", "Investigate this problem...", and of course "Proceed with that recommendation/solution/suggestion..."

Less is more, so to speak.

There's one thing that is guaranteed. It will ALWAYS respond to you, no matter what. No silent treatment. No ghosting etc.

I find that I am starting to use key action words, no matter the task. "Delve/Dive into...", "Expand on this...", "Explore...", "Investigate this problem...", and of course "Proceed with that recommendation/solution/suggestion..."