My honest first take on NI Nigel’s LabVIEW coding.
NI Nigel is the AI agent built into LabVIEW that writes code for you. The code-writing version shipped with LabVIEW 2026 Q3 at the end of July. I had a real project in front of me last week, so I used it. Here is my honest take.
The job
A client had a LabVIEW test program that talks to a controller over plain HTTP. Their cybersecurity upgrade moved the controller to HTTPS, and the test program needed to follow. Simple enough on paper. Open a TLS connection, log in, send a command, read the response.
It was not simple in practice, and that turned out to be the whole story.
What NI Nigel did well
It builds fast. I described the VI I wanted and got a front panel with a dozen controls and indicators, properly typed, properly labeled, wired to a block diagram that compiled and ran. That is maybe fifteen minutes of dragging terminals around if I do it myself. Nigel did it in about a minute.
For boilerplate, it is genuinely good. Building request strings out of concatenated pieces, converting numbers to decimal strings, laying out an error cluster, wiring a case structure. This is the tedious part of LabVIEW and Nigel handles it without complaint. Later on, when I asked it to take my working code and reorganize it into clean subVIs, it did that well too.
If you are building something conventional, I think you will be happy.
Where it fell apart
My project was not conventional; no project is, and that is where the cracks showed.
The first thing Nigel reached for was the built-in HTTP client VIs. That is the obvious answer, and it is the wrong one here. This controller streams events continuously over a connection that never closes. The HTTP client VIs wait for a response to finish before they hand anything back, and this response never finishes. Pointed at that endpoint, they sit there until they time out and return nothing. The job needed a raw TCP connection with TLS layered on top, driven manually. Nigel went with the common answer instead of the correct one.
Next was the connection count. The controller uses three separate TCP connections. One stays open the whole time streaming events. The other two are short lived, one for the login and one for each command. I said this clearly in my specification. Nigel built it with a single connection, because a single connection is what almost every example on the internet looks like. The result compiled, ran, and returned no errors. It also did not work, and the reason was invisible unless you already knew what to look for.
Then the login request came back missing one blank line between the headers and the body. HTTP requires that blank line. Leave it out and the server reads your credentials as part of the header block and never answers. In a normal string display it looks completely fine.
The one that stuck with me most was the state machine. I asked for a state machine so I could step through the connection process one piece at a time and stop wherever I wanted. Nigel gave me a state machine. It had all the right states, a proper enum, a shift register, a clean case structure. It was also empty. None of the subVIs that actually do the connecting were inside it. It was a very tidy shell with nothing running in it.
That captures the pattern. Nigel is good at producing the shape of a solution. It is much less reliable at producing the working parts inside the shape, and it cannot tell the difference between the two.
The thing I actually took away
NI Nigel has no feedback loop with the hardware.
It cannot run the VI, point it at the controller, and notice that nothing came back. It writes code that looks like working code, and it has no way of knowing whether it is. On a task where correctness is obvious, that is fine. On a task where a wrong answer and a right answer look identical on screen, it is a real problem.
The bugs were eventually found the old fashioned way. I put indicators on the front panel showing the exact bytes going out and coming back, and read them with my own eyes. That is how every defect got caught. Not one of them was found by the tool that wrote the code.
I also learned that shorter instructions work better than longer ones. My first specification ran several pages and covered a state machine, a streaming parser, and acknowledgement logic all at once. Nigel got lost. I cut it by about seventy percent, stripped it back to the bare minimum needed to prove the protocol worked, and the next attempt was much closer. Ask for less and you get more.
In the end I took over and made the changes myself. Then I handed the working version back to Nigel to package into subVIs, and it did a nice job of that.
In fairness
This is version one of the code-writing NI Nigel. The advisor side has been in LabVIEW since 2025, but generating a VI from a prompt is brand new, and NI’s own documentation says plainly that Nigel “supports a limited set of LabVIEW features when generating VIs.” That matches what I saw.
Every AI agent I have used in the last two years has improved fast, and there is no reason to think this one will be different. The gaps I ran into are the kind that get closed, and some of them will probably be closed by the time anyone reads this. I would rather NI ship it now and iterate than wait three years for something perfect.
So take this as a snapshot, not a verdict.
Would I use NI Nigel again
Yes, with clear eyes about what it is today.
Nigel is a fast draftsman. It gets a structure on the screen quickly and saves real time on the parts of LabVIEW that are just typing. It is not an engineer. It does not know when it is wrong, and it cannot test its own work against real hardware.
For a straightforward data logger or a user interface, let it do the first pass. For protocol work, hardware integration, or anything where a plausible looking wrong answer costs you a day, treat everything it produces as a draft that nobody has checked yet.
Because that is exactly what it is.
Joe Zarycki, Dynamic Engineering LLC. We do LabVIEW and test system engineering for industrial clients. More about the engineer behind the work, or get in touch if you have a test system that needs to talk to something stubborn.
