IMO this is crazy. Of course you would trust a developer (or any other worker) on your team that you picked. That person has been vetted, tested and is trusted unless you are a compete numb-scull as a team leader.

Trust is the main issue.
When the people that make these machines say, don't trust them, they 'lie' and they cheat. I think we should wait until there is trust.

 

Actually Google AI does test code and can tell you if you have a hardware problem now it’s not a 100% but it dose help

 

Actually Google AI does test code and can tell you if you have a hardware problem now it’s not a 100% but it dose help

Do you trust it with something new and unique in total design.

 

I really thinking I worked harder the problem is getting AI to stop finding stuff on the net like some code we did in swordfish basic it wrote good code after I got it to understand swordfish feeding it help files of why VB code wouldn’t work. I use it for stuff it gets right like micro python it’s good at that basic it’s good xc8 you work a lot getting bugs out but my led lighting it did a nice app and server setup but those took a week an co pilot gave up on it I’ve tried all 3 google Gemini is been the best so I use it to help me but it’s just me and stuff I’m doing for work

 

I’m using the pro

 

I really thinking I worked harder the problem is getting AI to stop finding stuff on the net like some code we did in swordfish basic it wrote good code after I got it to understand swordfish feeding it help files of why VB code wouldn’t work. I use it for stuff it gets right like micro python it’s good at that basic it’s good xc8 you work a lot getting bugs out but my led lighting it did a nice app and server setup but those took a week an co pilot gave up on it I’ve tried all 3 google Gemini is been the best so I use it to help me but it’s just me and stuff I’m doing for work

So, no, you don't trust it even for simple tasks. It's a spaghetti walking cane that breaks when you need it most.

 

Here's a big difference, as I see it. If I task a developer with writing a module, part of the expectation is that the developer actually test and verify that their module does what it is supposed to. If they give me code that hasn't been tested at all, they probably aren't going to be one of my developers much longer. But if I ask Copilot to write that module, what it produces has not been tested at all.

Yes, that's undoubtedly true, but a human employee carries a real tangible cost, so you get what you pay for. I really don't know to what degree the MCU industry actually uses AI for software development. My own experience is that it is a very powerful tool.

These AI systems are very good at "understanding" code, programming languages are formal unambiguous systems making it possible to formally reason about code in a way ordinary human languages cannot.

Let me make up a simple example:



Most of us here have no trouble seeing that is a reasonable solution, we could easily write it ourselves but the question took two seconds to write and the response came back in under a second, so why would I write this by hand anymore?

Now look at this:



It replaced the nested loop with a single loop abstraction, but most humans would begin by seeing how to extend the original nested loop code.

So if I understand the problem well enough to ask the question clearly, I have no trouble visually assessing the answer.

And just for fun:



and finally



So as I see this, the skill one needs to fully leverage this is an intimate understanding of the problem and an ability to clearly articulate the question.

 

If a programmer needs AI to write this code without thinking a solution (1st code doesn't need 2 loops), it is better for him/her to look for another job.

 

Yes, that's undoubtedly true, but a human employee carries a real tangible cost, so you get what you pay for. I really don't know to what degree the MCU industry actually uses AI for software development. My own experience is that it is a very powerful tool.

These AI systems are very good at "understanding" code, programming languages are formal unambiguous systems making it possible to formally reason about code in a way ordinary human languages cannot.

Let me make up a simple example:

View attachment 354909

Most of us here have no trouble seeing that is a reasonable solution, we could easily write it ourselves but the question took two seconds to write and the response came back in under a second, so why would I write this by hand anymore?

And some of us here have no trouble seeing that it is a horrible solution that is very fragile and almost certainly going to cause problems when used,

This is a shining example of what I am talking about. You gave it an incompletely-defined description of a problem. It made an unwarranted assumption about the part that wasn't specified, it generated code that looks plausible at first blush (even though there is a HUGE red flag that should have been screaming out to you in the function header). But instead of actually examining the code and/or testing it yourself, you asked it to test it and it generated cherry-picked test cases that are consistent with the unwarranted assumption it made, and because you trusted it to do your job for you, you accepted everything hook, line, and sinker and are ready to proceed to use this poorly-written function in your program, all the while patting yourself on the back about how much time and effort it saved you.

In case the problem hasn't jumped out at you yet, let's write a driver program that reveals it for all the world to see.

#include <stdio.h>

void* find_conditional_pointer(void* array[][10], int rows, int cols) {
    for (int i = 0; i < rows; ++i) {
        for (int j = 0; j < cols; ++j) {
            if (array[i][j] != NULL) {
                return array[i][j];
            }
        }
    }
    return NULL;
}

int main(void)
{
    // Create a data array that is initialized to all NULL
    #define DATAROWS (5)
    #define DATACOLS (5)
    void *data[DATAROWS][DATACOLS];
   
    // Set the values in the array to NULL
    for (int i = 0; i < DATAROWS; ++i)
        for (int j = 0; j < DATACOLS; ++j)
            data[i][j] = NULL;
   
    // Call the function and print the results.
    void *p = find_conditional_pointer(data, DATAROWS, DATACOLS);
    if (p)
        printf("Non-NULL pointer found in array\n");
    else
        printf("No Non-NULL pointer found in array.\n");
       
    return 0;
}

This test code will usually find a non-NULL pointer in the array, because the function is so poorly written that it is hopping around in memory well outside the array bounds -- and also has the very real potential to produce a seg fault on a hosted implementation.

So, in answer to your question, "... so why would I write this by hand anymore?", the answer might be, "Because you would like it to work."

 

That’s funny time they get done with AI there be no more people writing code there replacing about anything that writes and so coding probably be easy to replace AI can write code after it stops looking up dum code on the net it’s can read the compiler files It’s logic is perfect so they won’t be much use of people writing cold anymore my daughter work uses it to send out messages. She just tells it what she wants and it’s spit them out by 1000 but it is still using her thoughts, but after it learns that what happens

 

If a programmer needs AI to write this code without thinking a solution (1st code doesn't need 2 loops), it is better for him/her to look for another job.

In fairness, the claim isn't that this is a problem that needs AI, it is merely a simple example.

But, the fact that it is so simple, and that it produced very poor and fragile code that was accepted as being a reasonable solution IS a problem.

I know quite a few people that are very competent and successful programmers that are using AI tools to help them develop code that is letting them push into areas that are very new to them. But when they go through how they use those AI tools, it is SO much different than shown here (which is, unfortunately, at the level at which these tools are being increasingly used and abused).

 

And some of us here have no trouble seeing that it is a horrible solution that is very fragile and almost certainly going to cause problems when used,

This is a shining example of what I am talking about. You gave it an incompletely-defined description of a problem. It made an unwarranted assumption about the part that wasn't specified, it generated code that looks plausible at first blush (even though there is a HUGE red flag that should have been screaming out to you in the function header). But instead of actually examining the code and/or testing it yourself, you asked it to test it and it generated cherry-picked test cases that are consistent with the unwarranted assumption it made, and because you trusted it to do your job for you, you accepted everything hook, line, and sinker and are ready to proceed to use this poorly-written function in your program, all the while patting yourself on the back about how much time and effort it saved you.

In case the problem hasn't jumped out at you yet, let's write a driver program that reveals it for all the world to see.

#include <stdio.h>

void* find_conditional_pointer(void* array[][10], int rows, int cols) {
    for (int i = 0; i < rows; ++i) {
        for (int j = 0; j < cols; ++j) {
            if (array[i][j] != NULL) {
                return array[i][j];
            }
        }
    }
    return NULL;
}

int main(void)
{
    // Create a data array that is initialized to all NULL
    #define DATAROWS (5)
    #define DATACOLS (5)
    void *data[DATAROWS][DATACOLS];
  
    // Set the values in the array to NULL
    for (int i = 0; i < DATAROWS; ++i)
        for (int j = 0; j < DATACOLS; ++j)
            data[i][j] = NULL;
  
    // Call the function and print the results.
    void *p = find_conditional_pointer(data, DATAROWS, DATACOLS);
    if (p)
        printf("Non-NULL pointer found in array\n");
    else
        printf("No Non-NULL pointer found in array.\n");
      
    return 0;
}

This test code will usually find a non-NULL pointer in the array, because the function is so poorly written that it is hopping around in memory well outside the array bounds -- and also has the very real potential to produce a seg fault on a hosted implementation.

So, in answer to your question, "... so why would I write this by hand anymore?", the answer might be, "Because you would like it to work."

Thanks for critiquing that, your remarks aren't unreasonable but...

I posted for brevity yesterday and so left out bits n pieces that Copilot included in its response, I just submitted the same question and here's the complete response:



Asking to remove the hard-coded 10 elicits:



We both know we can hand over a "specification" to another human and get back code that makes undesirable assumptions, sometimes subliminal assumptions because the "specification" itself was imperfect.

Of course if this was a true project one would be paying much closer attention to all this and the `10` thing would have been caught early on.

I suggest you try it out, in fact give it some existing working code and ask "Can this code be improved" see what it say, it might find things you are currently quite unaware of.

 

The original question was vague, so including a type for the array elements we get:



So it does what I ask it to do, if the question excludes array type info it will react accordingly.

My experience shows me that this is best used iteratively, ask for code, get a response, examine it and ask for a refinement and do this several times you'll often get good code and sometimes even learn something in the process.

Clearly it "knows" a great deal about the C language and in fact it is just as creative with almost any popular language.

For example if one is not a SQL guru you can ask it to write a query with fiddly conditions and it does a damn good job, much faster than any SQL expert I've worked with.

 

If a programmer needs AI to write this code without thinking a solution (1st code doesn't need 2 loops), it is better for him/her to look for another job.

Well having seen the complete response (see my post above) we can see it was entirely reasonable code, it called out the `10` assumption (but I omitted it inadvertently yesterday striving for brevity, my fault).

I was working on a compiler last month and I can tell you it was damned helpful in code simplification and refactoring.

Take some logic you're proud of, solid stable code and ask Copilot to see if it can be improved...

 

I pointed out just now that its latest version checks for 0.0 not NULL:



and even



Time to move on from the Luddite world guys, if you're not taking advantage of this in some way or other, you're short changing yourself, like the old teacher I knew in college who insisted on using a slide rule rather than a calculator in the early 70s.

 

This is a good example, I use SQL often but I'm not an expert, so with a question like this I need to do a few web searches, or just ask Copilot:



pasting that SQL:

 

Thanks for critiquing that, your remarks aren't unreasonable but...

I posted for brevity yesterday and so left out bits n pieces that Copilot included in its response, I just submitted the same question and here's the complete response:

View attachment 354984

While it's nice that it pointed out that it assumes that the second dimension is fixed at 10, that actually makes the situation a bit worse, because it means that it "knowingly" wrote code that is inconsistent in a serious way. The function it wrote processes the array using the number of columns that it allows the user to pass in, even though it will only do this correctly if the user just happens to pass in exactly 10 for that argument.

 

The original question was vague, so including a type for the array elements we get:

View attachment 354987

So it does what I ask it to do, if the question excludes array type info it will react accordingly.

Did it? You asked it to iterate over a 2D array of double pointers. It produced a function in which the 2D array contains values of type double, not pointers to doubles. Assuming (and this is frequently NOT a good assumption) that the size of a pointer is the same as the size of a double, then this code might actually work on many implementations since a NULL pointer, regardless of its internal representation (which is often not strictly all zero bits) has to behave as if it is equal to zero, and the IEEE-754 representation for 0.0 is a pattern of all zeros. But if this is compiled on a machine that doesn't use 64-bit pointers, all hell will break loose.

Also, note that it explicitly stated in its assumptions that it's looking for the first non-NULL pointer, not the first non-zero value, and then it proceeds to look for the first non-zero value. This has the definite potential to create confirmation bias because it says it is doing something that we want, so we tend to look at the code it generates with a bias toward interpreting it as actually doing what it claims.

You might have led it down a false path by saying "start at 0.0" as opposed to "start at 0,0". Maybe, maybe not.

My experience shows me that this is best used iteratively, ask for code, get a response, examine it and ask for a refinement and do this several times you'll often get good code and sometimes even learn something in the process.

It is definitely an iterative process if you want to get good results, and the best results are when the person guiding the iteration really understands what they are doing at the level of the code being generated. The code generator certainly has exposure to a lot more styles and tricks and techniques than any one programmer will have in their repertoire, so a lot can be learned even by experience programmers -- in fact, experiences programmers are probably in a better position to really learn those new things. The problem, as I have stated previously, is that there is a natural tendency for tools like these to be abused to the point where the knowledge and skills needed to truly use them properly atrophy or are never even developed in the first place, leading to people just accepting whatever they return as being good simply because they lack the knowledge, skills, and attitude needed to recognize when it's not.

 

Co pilot can’t write good C code. The free version only gives you what it finds on the Internet.

 

Did it? You asked it to iterate over a 2D array of double pointers. It produced a function in which the 2D array contains values of type double, not pointers to doubles.

It did, when I pointed out that (by the way it checks for 0.0) it responded with brief "thoughts" (transient text windows that fade away) saying stuff like "reviewing interpretation of 'array of double pointers'" then replied:

Assuming (and this is frequently NOT a good assumption) that the size of a pointer is the same as the size of a double, then this code might actually work on many implementations since a NULL pointer, regardless of its internal representation (which is often not strictly all zero bits) has to behave as if it is equal to zero, and the IEEE-754 representation for 0.0 is a pattern of all zeros. But if this is compiled on a machine that doesn't use 64-bit pointers, all hell will break loose.

Right but this is an example, I could easily say "now ensure the code works on 64 bit CPU" or whatever, but my original question didn't say "array of double*" it said "array of double pointers" and that's open to interpretation it appears.

Also, note that it explicitly stated in its assumptions that it's looking for the first non-NULL pointer, not the first non-zero value, and then it proceeds to look for the first non-zero value. This has the definite potential to create confirmation bias because it says it is doing something that we want, so we tend to look at the code it generates with a bias toward interpreting it as actually doing what it claims.

You might have led it down a false path by saying "start at 0.0" as opposed to "start at 0,0". Maybe, maybe not.

It is definitely an iterative process if you want to get good results, and the best results are when the person guiding the iteration really understands what they are doing at the level of the code being generated. The code generator certainly has exposure to a lot more styles and tricks and techniques than any one programmer will have in their repertoire, so a lot can be learned even by experience programmers -- in fact, experiences programmers are probably in a better position to really learn those new things. The problem, as I have stated previously, is that there is a natural tendency for tools like these to be abused to the point where the knowledge and skills needed to truly use them properly atrophy or are never even developed in the first place, leading to people just accepting whatever they return as being good simply because they lack the knowledge, skills, and attitude needed to recognize when it's not.

Well we do pretty much that when we entrust a compiler to generate machine instructions that what we expect when all we pass in is C source code. Few of us have the knowledge or skills (or time) to examine the generated assembly code and peruse it for correctness.

Compilers get updated from time to time but very few users rebuild and retest every bit of code to ensure the generated code is not broken in some way.

Furthermore it's common in industry to build and test unoptimized code sometimes and then on generate and ship optimized code, people ship untested code all the time.