I think in your case I'd have it write some code to track a sensor. Keep it simple. See what it comes up with. Then I'd start from scratch with what I learned from that and write a more detailed prompt that takes it more in the direction needed. I think what you are describing is doable and AI could potentially speed things up.

As to when I say "knowing what you are doing" if you are working on a project and in the early course you design variables around a method called seamMatching(datatype A) and later on you are using some code that needs to type into that and instead of calling that method it says something like seamJoining(datatype A,datatype B) then you'd likely be able to say "wait a minute, that isn't what we called it, and that isn't how it is implemented." That's the type of error it tends to introduce the most after you've been arguing with it for awhile.

One technique that can help some is every so often in your work with the AI tell it to generate a detailed prompt that you could provide it in the future to get it back to this point. Put that in a notepad and attempt to use it kind of as a a "get back on track" prompt if it starts to make a lot of errors. It can help, but generally speaking the prompt is often too general on the details to completely make up for these issues.

This is why I do it in chunks. Make a project to read the sensors. Then make a separate project saying you have this system to read sensors and you give it the way to interface with that and you say "now I want to make something that uses that to do this..." You keep it so it has no desire to redesign what you already have working by keeping them discreetly different projects.

Oh and these things are quite good at writing code. I've learned code techniques I didn't know working with them. They are just not good at coming up with the ideas themselves or keeping it all together contextually for long periods.