LabVIEW and the AI coding revolution: are we being left behind?

[andcadev]

Hi everyone,

I wanted to share some thoughts and doubts that have been on my mind lately regarding the future of LabVIEW and the AI revolution.

I've been developing in LabVIEW for about 13 years. It's not a perfect language, but there are many things I appreciate about it: its dataflow model, its seamless hardware integration, the way it makes parallelism feel natural. But lately I've been sitting with an uncomfortable question.

I do use AI in my LabVIEW work (for architecture, for documentation, for thinking through design decisions). But the moment I sit down to write and review actual code, I'm on my own. An LLM cannot generate LabVIEW code, and can do very little with existing code either. It can't navigate a codebase, trace a bug, or suggest a meaningful refactor. The binary, visual nature of LabVIEW puts it out of reach of the tools that are reshaping software development everywhere else.

NI/Emerson has introduced Nigel, and I really appreciate the effort. But I'll be honest, I haven't used it yet. To those who have: is it genuinely closing the gap with tools like Claude? Or are we still far behind?

In the meantime, a few ideas I keep coming back to:

• A LabVIEW MCP server. Exposing VI Scripting as tools that an external AI agent could use to read, create, and modify VIs. This wouldn't require changing the language itself.
• A structured textual representation of LabVIEW code. Not a new language, but something an LLM could reason about and that could round-trip back to a valid VI.
• NI exploring deeper integration with existing foundation models, rather than going it alone in a space where the big players are moving incredibly fast. And which raises a broader question: does a proprietary model even make sense here? Or is the smarter bet a thin LabVIEW-specific layer on top of an existing one?

But honestly, I'm not here to propose solutions. I'm here to ask: does this concern you too? Do you think the AI gap is a real threat to LabVIEW adoption, especially among younger engineers who've grown up with these tools?

I'd genuinely like to hear where the community stands.

[pawhan11]

My opinion after trying Nigel AI is that NI is behind 4 years or more. In Claude Code i can simply point it to device ip address, documentation and interface that i want implemented. 30 minutes later i have working code with tests on real hardware that pass. I can not imagine doing that in LV Nigel. I have to spend hours/days wiring those VI's manually moving all files on disk etc.

For Teststand i had more luck when converting sequence to xml and feeding that to Claude, and after some modifications converting it back and it worked.

Not to be bad prophet but i think LV will be marginal in the future unfortunately... Shame because i spent last 15 years using it

[MichaelS78]

I have started making extensive use of the python integration node for this reason however that has extra dependencies for deployed applications and of course security issues as python is interpreted. 

My next endeavour will be to start using AI to produce rust functions and compile them as DLLs that labview can call. I really like this approach for now because it lets labview have the application architecture but I can spend my time with architecture not worrying about the detail of functions which are easily AI coded. I was finding developing  Labview was really getting me down because my colleagues using text  code could easily and instantly make a function that I would have to spend hours writing and debugging for something that should be really simple.

I am very interested to see what  NI Nigel generative AI updates will bring which has been announced: a webinar launch event in July.

The big glaring problem I have of course with the AI route I have described above is that debugging is no longer easy! And the application update involves either including python scripts or building DLLs. I really hope Nigel generative AI catches up!  

Today I wrote a python function to call from LabVIEW to recurse over folders and tell me lots of details about the files in there. It took two prompts in chatGPT to get exactly what I wanted and yes I could have coded it in LabVIEW but modern software engineering is moving to the point where the software engineers should not have to deal with this kind of function rather they look after the application architecture and we need to keep ahead or we will lose LabVIEW to generative AI and text-based languages.  I feel very strongly about this and I would love to hear other people's thoughts and experiences.

[andcadev]

---

@pawhan11  ha scritto:

Not to be bad prophet but i think LV will be marginal in the future unfortunately... Shame because i spent last 15 years using it

---

It's sadly reassuring to know we're aligned on this.

[andcadev]

---

@MichaelS78  ha scritto:

I have started making extensive use of the python integration node for this reason however that has extra dependencies for deployed applications and of course security issues as python is interpreted. 

My next endeavour will be to start using AI to produce rust functions and compile them as DLLs that labview can call. I really like this approach for now because it lets labview have the application architecture but I can spend my time with architecture not worrying about the detail of functions which are easily AI coded. I was finding developing  Labview was really getting me down because my colleagues using text  code could easily and instantly make a function that I would have to spend hours writing and debugging for something that should be really simple.

I am very interested to see what  NI Nigel generative AI updates will bring which has been announced: a webinar launch event in July

The big glaring problem I have of course with the AI route I have described above is that debugging is no longer easy! And the application update involves either including python scripts or building DLLs. I really hope Nigel generative AI catches up!  

Today I wrote a python function to call from LabVIEW to recurse over folders and tell me lots of details about the files in there. It took two prompts in chatGPT to get exactly what I wanted and yes I could have coded it in LabVIEW but modern software engineering is moving to the point where the software engineers should not have to deal with this kind of function rather they look after the application architecture and we need to keep ahead or we will lose LabVIEW to generative AI and text-based languages.  I feel very strongly about this and I would love to hear other people's thoughts and experiences.

---

Your approach is probably the only viable path right now to actually leverage these technologies. But, as you said, debugging becomes the real pain point. it's a workaround.

And the fact that we have to reach for other languages just to work around LabVIEW's limitations with AI coding says a lot about where things stand.

Hopefully we'll get more comments on this

[alexderjuengere]

I use ai as a tool in the context of problem solving, and for recreation,

eg I coded an  fractal to be displayed in an intensity graph including a zoom-functionality, based on python code which was generated via google's gemini.

my conlusion so far:

ai is good for solving obvious problems that have been solved before.

likewise it fails miserably at solving new problems, with no a priori knowledge,  or corner case problems, which occur sporadically.

Communicating with an AI can sometimes feel like talking to a stubborn child who refuses to admit they don't know the answer

Twenty years from now, we will refer to this era as the troubled infancy of artificial intelligence

As a non-native speaker, I actually used AI to help me phrase those last three sentences, lol... ^^

[rolfk]

It may be a good thing that LabVIEW can't yet be used with AI to create entire software architectures. It limits the amount of AI slop that will need to be cleaned up a few years from now.

If you have been in technology as long as me, you would have experienced at least 2 prior AI hypes that amounted to just a bit of hot air, an internet .com bubble, Fuzzy logic hysteria, Metaverse (not the Meta/Facebook joke a few years ago but the original Linden Lab SecondLife phenomena about 20 years ago, where every technology company who did not want to appear from yesteryear had a virtual office where people could apply for real jobs at that company).

The .com crash was an economic disaster, the rest had limited economic influence once people woke up from their fever dreams.

The current AI hype is in so far different that the amount of money that got pumped into it is so huge, that a crash will be extremely painful. So it may not be allowed to fail even if it turns out as a total disaster.

As far as AI programming goes, it's like what Alex already explained, if it is about a problem that has been umpteen times solved already, it will happily offer a solution albeit quite often not really optimal or even outright convoluted. And if you continue with AI on that code it tends to make it more and more messy. The really hard work that has not been solved before already, it often can't really solve.

[pawhan11]

My perspective after 15years in LV and now 5 years in .net is that with AI I can skip almost all boilerplate code like data translation, code for simple hardware communication. This code is almost always good and there is nothing I have to change. It saves ton of time so I can  focus more on architecture/complex design/logic problems that I do not trust AI able to solve now. 

In LV now we can not skip boring boilerplate wiring part once we know what has to be made. Not to mention easy code refactor or automatic code reviews.

If we can do the same faster and cheaper in .net or python compared to LV with the same quality why choose LV? Decision makers count $$ at the end...

[Elijah_K]

Hey andcadev,

I think the concern you’re raising is legitimate. Generic AI coding tools do not currently understand or operate on LabVIEW projects in the same way they can navigate a textual codebase, and we recognize that closing that gap is important to LabVIEW’s future.

I would encourage you to watch the NI Connect keynote from last month, where we demonstrated the prompt-based code-generation capabilities coming to LabVIEW in July:

https://www.youtube.com/watch?v=4ZemwqC-n5Q

The demonstration begins at approximately 11 minutes.

In short, Nigel is moving from being primarily an advisor to being able to author LabVIEW code. The demonstration showed it creating a complete project from a prompt, including project structure and class-based architecture—not simply suggesting an individual function or generating a textual description of what the code should do.

The July release is the next significant step, but it is not intended to be the end state. Our broader goal is for Nigel to assist throughout the test-development workflow: understanding and reviewing existing code, creating and modifying applications, configuring systems, producing documentation, analyzing data, and helping users diagnose problems.

It is also worth clarifying that NI is not attempting to develop a proprietary foundation model in isolation. Nigel currently uses OpenAI models, with NI providing the LabVIEW- and test-specific context, integrations, safeguards, and capabilities needed for those models to work meaningfully with graphical code and engineering workflows.

We know there is still significant work ahead, and feedback from experienced developers like you is important in determining where we focus next. After you have watched the demonstration—and especially once the July capabilities are available—I would be very interested in hearing where you still see the largest gaps.

[andcadev]

Elijah, good to get a direct response on this. I didn't know NIGEL was already using OpenAI models — useful to have that confirmed directly.

I'll watch the keynote and follow the July release closely. Moving from advisor to actually authoring projects, including class-based architecture, would be a real step change if it holds up in practice.

I'll come back with concrete feedback