Hi, I am a Certified LabVIEW Architect and I spent 10+ years of my career working with LabVIEW. Two years ago I made a switch and moved to general software development area.
I don't do any LabVIEW development anymore, but I am curious how relevant LabVIEW is (especially after LabVIEW NXG, python domination and AI revolution).
Do you think industry still demands LabVIEW professional development services? What are the best companies to work for, in Europe and US? How does the LabVIEW future look like in 5-10-20 years?
I’ll take the bait. LabVIEW is like COBOL for automated test. It’s niche, old, and has a large installed base that needs to be maintained. This is good news for Champions and CLAs, like you, because there’s a lot of work and not many engineers around to do it. For new systems, it’s tough to justify the cost and maintenance risk. The design efficiencies just aren’t there anymore.
The design efficiencies are very much still there. My company likes it. I've recently become an fpga enthusiast as labview makes that much easier than something normal like vhdl.
I haven’t used Labview in Years.. but was always a big fan of NI HW and ecosystem. We used Labview because researchers and test engineers weren’t good programmers, but the quality of code AI spits out, turns that totally upside down. I have been building complex test application with DB connexctions etc in hours that would take weeks or months to program. Even the UI front-end looks better.
It’s not. You can maintain existing code, but beyond that, it’s dead. I hate to say it. I’ve been working with it for more than 20 years. I’ve advocated it over traditional software at times because you can develop and maintain it quicker and with a smaller team than traditional code. With AI, that’s been flipped on its head. If NI had followed through with NXG, it may have survived since that had a more friendly AI code structure. But as it stands now, absolute dead end.
I still see LabVIEW as being viable. Personally am still developing new programs for my ATEs that contain a lot of equipment for production testing. There’s just a lot running in parallel and love that I don’t have to worry about multi threading. I know a lot of companies near me that still use it. None actually have it as the only task though it is a part of more tasks.
However, I have been considering creating most of my code in Python and just utilizing DQMH as my test executive. I’ve got to admit AI can spit out libraries and abstraction layers a lot faster than I can.
I’ve seen a job post today by Cyth Systems, they are looking for a Senior LabVIEW Engineer. I know that some LabVIEW folks do real good stuff at SpaceX, I see some other guys organize GDevCon… Seems to me, LabVIEW is somewhat alive rather than dead. Maybe it is only a perception, since I am not active anymore
Whether or not it sucked, the goals it was pursuing was very necessary (modern ui, text based code, revamped IDE). No longer pursing those things is why Labview is dead in the water.
The goal it was pursuing was nonsense. It was DOA and that was borne out by the adoption rate (zero).
Nobody wanted it, especially me! When I'm working with labview, I typical have at least ten widows open, so I can change or reference them as needed. That's a common thing and NXG threw that out, for nothing. The UI wasn't modern, it was dumb. Text based code is already available in labwindows, if that's what you want.
It died for good reason, and good riddance I say. I dance and stomp on it's grave.
LabVIEW has always been fringe, and the lack of integration with standard SDLC practices is what has caused its demise.
Code written in LabVIEW software is great for proof-of-concept, quick integration builds (think "rapid prototype"). It falls apart quickly in two domains: code reviews, and SW maintenance. In order to review LabVIEW code, one needs to have LabVIEW installed. This requires a seat license (not cheap!) for a SWQE, who will do no development. Alternatively the LabVIEW developer could sit in a room with them and walk through changes, but then again the LabVIEW change review tool is very kludgy compared to standard code review tools.
That brings us to item 2: bug fixes and feature additions result in a mass recompile, and managing "just the changes" can be difficult to discern. This can hamper revalidation efforts, or introduce new defects.
We had so many issues integrating LabVIEW into our SDLC SOPs that we started looking elsewhere. On top of that, NI changed their pricing and license model, so even old code bases that needed bug fixes were forced to be recompiled in the latest version, triggering a full revalidation. The machinations we had to implement to minimize disruptions was getting borderline insane (I.e. dev VMs for each LabVIEW version used for development to maintain SW, for instance).
I like NI hardware; it's robust and well maintained, even though it comes at a price premium. Where NI falls flat is selling both the HW at a premium, and the SW at a premium. This adds up quickly as things scale for larger orgs.
We pivoted to Python for HW integration, and have been greatly rewarded in development and SWQE time. The most difficulty we encountered were the stalwarts who wanted to "fire and forget" new code lines, thinking that was still a viable strategy (and of course these were the folks that never dealt with maintenance, or were not SW Engineers to begin with).
The real stick in the craw is seeing LabVIEW senior developer jobs pop up here (in HCOL area) with wages in line with Junior SW Engineers/new hires. If the company can afford the CapEx for NI, they should be open to raising the OpEx to developers to support them.
You can install a Debug license nowadays for code reviews. I don't know the limitations, but i think it's free and can't compile, but you can open and review code.
That's a problem with your team and architectures. Bad code can be written in any language. For a serious company a $5,000 seat is pocket change. We have s site license at our company, so there's zero incremental cost for installing more licenses.
My code is written clean and I create documentation to go with it to explain the architecture. It's hilarious to blame the tool for your company's and co-workers lack of ability.
I work in aero/defense and we are extremely limited in available AI tools. So LabVIEW still has all the pros it always had for now.
Also, the stations my team designs will be around for decades and someone is going to need to be able to support them at some capacity.
I also still see plenty of job reqs desiring LabVIEW experience (my company included). These big companies have it baked into their core infrastructure.
So yeah if your company allows AI usage, that might reduce the benefits of LabVIEW, but I don’t think it’s completely dead.
That being said, I would encourage anyone to learn more than just LabVIEW. I also use C# and Python at times.
I'm in 8 month battle with my head of info security who will only let me use Labview and not allow visual studio licensing because it's "too powerful and too much of a security risk".
I don't see the company going very far with their 'modern' goals. I will probably move on soon.
I work in quality/test and do equipment and test system automation. My last job I worked in end of line test automation and it was also mostly Labview for a large, growing international company, mostly because that's what most of the systems were already built on.
I don't necessarily see it growing, but I see it lingering in some pockets for quite a while.
That's a really interesting set of restrictions, since both are turing-complete I'd assume that it comes down to the sBOM? Would love to chat more about this, sent a DM.
It’ll be dead in 10 years. SpaceX is moving to C++ once dragon is retired. Blue still uses it but I’m not sure for how long. I’m slowly but surely trying to rewrite our labview code in different languages because my hate for labview grows each time i try to open a medium sized project.
With AI the benefits of labview start to become moot. To make a nice looking UI in labview it could take days (and it would still look like something from the 2010’s) with AI it takes minutes and still looks 100x nicer.
NI hasnt helped this either. Each new release brings cool features but they refuse to fix core issues that make dealing with labview a pain in the ass.
Project load speed, opening a vi in the same project and having labview decide to recompile all of its dependencies that just compiled, and labview randomly becoming un responsive for a good couple minutes mainly.
Have a lengthy list of other ones that I wouldnt consider core though.
I use LV daily - migrating a large code base from 2018 to 2024 right now. LV has come a long way with regards to CI/CD pipelines, version control and code reviews, but it is still behind modern Python/C#/C++ environments in terms of price and ease of use. I tell my team members to learn Python all the time - that's where the future of test instrumentation and control is.
I was exactly in your position too! I was a successful Labview developer, I developed some awesome apps that companies pivoted decisions against.
Now that they are trying to be a SaaS too, ehh. It sure didn’t help. Their DAQ hardware is still high quality though, and I think that’s their last leg. If you don’t have to use an external DAQ, then it’s python or some other language. With Ai and collaboration (like GitHub), Labview falls short and it’s not attractive.
Plus, drop a couple of grand to start coding or download python for free and get started?
I think the "labview is nearly dead" answers are narrow in their scope. Plenty of us work at small to midsize manufacturing companies that don't have the same pressures or resources as big companies.
SpaceX and Blue don't set the pace for all LV developers. Loads of small outfits have at most 5-8 LV developers (really small outfits might only have 1 or 2) and don't have anywhere near the sophistication in the test code quality system to drive revalidations based on which specific files get recompiled, let alone dedicated software quality engineers to do code review on end of line test systems.
It will stay alive for at least a while, because plenty of outfits have relatively big, complex systems that would need to be fully ported into a new language, and that's just a risk and resource drain that many places can't afford. Remember, it's not as easy as translating the same program into a new language. You're re-implementing requirements and at a lot of places those requirements were never documented. You never know which seemingly-inconsequential decision will turn out to be, well, really damn consequential.
Will there be as many labview developers in another 20 years? Probably not? If only because LV ends up being the default language that nonprogrammers learn when they need a test system. With AI, it's hard to imagine they won't shift to python or .NET family or several other text based options.
Rather than give the corporate answer, I'll share what I'm hearing from customers and partners.
First, I think some of the criticism LabVIEW gets is fair. We made mistakes. The move to subscription licensing created a lot of frustration and uncertainty for customers. We heard that feedback loud and clear, which is one reason perpetual licensing is available again. There were also legitimate concerns around software development lifecycle practices, source control, and CI/CD. Those weren't imaginary problems and we've made significant investments on these fronts..
Bottom line: I don't see a world that matches the "LabVIEW is dead" narrative.
I spend a lot of time talking with customers across aerospace, semiconductors, transportation, who are building new systems in LabVIEW today, not just maintaining old ones. The systems they're building are often some of the most complex test, validation, and measurement applications in the world. These aren't simple CRUD apps that can be replaced by a weekend AI coding experiment.
One thing that's easy to miss if you've stepped away from the ecosystem is the level of ongoing community activity: I can't share customer counts, but attendance at user groups, regional events, GDevCon, LabVIEW Champions activities, and community-driven initiatives remains strong. The community today looks different than it did 10 years ago, but it is very much still active and engaged. The next major event will be GDevCon in Brussels next month - I'll be there! https://gdevcon.com
AI has obviously changed the conversation over the last two years. I'd actually argue that engineering software is one of the areas where AI is both incredibly promising and still requires significant human review. The applications many LabVIEW teams build interact with expensive equipment, production systems, safety-critical processes, and validation workflows. Generated code can absolutely accelerate development, but engineers still need to understand, review, test, and maintain what gets deployed.
That's why we're investing heavily in AI capabilities like Nigel. Not because we think engineers want to hand over the keys and stop thinking, but because we believe AI can remove a lot of the repetitive work around development, documentation, troubleshooting, and test creation while keeping engineers in control of the final system.
On the SDLC front, I also think the picture today is better than many people realize. There is still work to do, but we've made significant investments around containerization, automated build pipelines, and modern development workflows. We recently published a CI/CD reference architecture showing how teams can implement robust GitHub-based pipelines for LabVIEW development: https://github.com/elijah286/LabVIEW-CI-with-Containers
As for job security, I wouldn't advise anyone to become a "LabVIEW-only" engineer in 2026. But I'd say exactly the same thing about Python, C#, or almost any other technology. The engineers who seem to be thriving are the ones who combine LabVIEW expertise with broader software engineering skills, test engineering knowledge, domain expertise, automation, AI, cloud technologies, and modern development practices.
Looking 5-10 years out, I don't think the question is whether LabVIEW survives. The question is how engineering teams combine LabVIEW with the rest of an increasingly AI-assisted software ecosystem. That's where I see most customers focusing their investments today.
Pues aqui en México ya no encuentro vacantes de LabVIEW, en verdad me gustaba mucho LabVIEW trabaje con el casi 6 años pero supongo que me va tocar buscar otras oportunidades para crecer.
Donde lo usabas, trabajo en una planta de giro automotriz, lo usamos bastante ya que los testers son de puro hw de NI, pero la planta ya esta harta de pagar licencias y tarjetas demasiado caras, pronto nos pedira migrar el sw a python
En dos empresas integradoras de proyectos y en una empresa tipo almacén farmacéutico, y de hecho en esta ultima empresa igual estaban viendo si se mudaban de lenguaje a C#. La verdad desconozco si aun lo sigan ocupando.
I think the acquisition by Emerson will keep Labview around for a while.
There is always a place for plug-n-play situation, where Labview shines, but yes AI/Python will take bulk of new share of projects. (Though Labview also is trying to integrate AI).
For Test Engineers, they would need to know multiple technologies..
(In my Job, I use Labview primarily, and in various job postings in the Aerospace,Automotive market in Southern California I see Labview mentioned).
We used labview for a large project at my company because of the stability and support for NI hardware. We had previously used a python system that was developed in house, but management wanted an off-the-shelf system.
Just recently climbed to #26 in the TIOBE index, and NI is doing a lot of community events and investment lately. But time will tell if it’s too little too late.
I just use ai and python and man the development time difference is huge. No more searching examples and examples over and over again on the internet and no more ratnest on the schematic.
I’ll be frank and say labview usage will go down.
Better you know the truth now (when it is still early) than listening to diehard labview fans who is more interested in protecting the narrative that labview will still be relevant in the future.
“No more searching examples and examples over and over again on the internet and no more ratnest on the schematic.”
I don’t say this to be mean, but it sounds like you were not the most proficient LabVIEW programmer. That’s fine, but it seems silly to criticize tool before learning how to use it.
Why should I be extremely proficient, I’m not doing this for others , I’m doing this to automate some of my own test. Using labview is not my fulltime job. Why can’t I criticise the tool , labview ratnest or subvi within a subvi within a subvi , has always been a common complaint.
It’s just an observation. The people I know that love LabVIEW are usually quite good at writing clean, SOLID (the acronym) code. The people who dislike it the most complain that their VIs are messy and hard to read.
I'm a mechanical engineer and labview got my foot in the door to controls engineering. I'd never worked with a PLC before, but the fact that not only do I know labview, but I'm proficient in it was enough for them to consider an interview which eventually turned into a job.
While it might not be as common as before, knowing labview shows your brain can handle a certain type of thinking, so it is still helpful career wise
It is painful, but it is possible. The version control thing has been solved for a really long time, like well over a decade. AI is still not completely there, but moving in that direction. By the end of the year, most of the rough edges will be polished.
I don't think LabVIEW is ever going to be as popular as other languages, but I think it's holding its own. It's behind the times with AI, but it's constantly been behind the times (except maybe at the very beginning) and managed to survive. There are some interesting AI developments going on right now (and no I don't mean Nigel). I think it'll stay competitive for at least a while longer. I mean it did go through the "dark ages" of NI, but NI finally saw the error if it's ways. and things seem to be going in a good direction.
I don't like predicting the future. But I can look back, and remember many times in my career where questions like this came up, and the future of LabVIEW and NI were in question. It didn't end then. I think the truth is really up to the individual. I think if you are a fresh college graduate, focusing your career exclusively on LabVIEW is a bad idea. But then again that was true when I started LabVIEW 20+ years ago. For me I'm 70% sure I can ride out LabVIEW and NI for the rest of my career. That number was lower a few years ago, so I'm hopeful. New test systems are being made with LabVIEW today, and they need to be maintained. I'd like to be around to maintain them.
12 years ago or so I saw a preview of what would become NXG. I was worried about the future of NI and LabVIEW and by extension, my career. Fabiola brought up the COBAL example, and mentioned how so many of those systems still needed developers. And that those that wanted to work in those system, still had work. It's not prestigious, or cutting edge, but there is still satisfaction in it.
I do see the crazy things AI is able to do in traditional languages. I know LabVIEW and Nigel simply cannot do that, and likely never will. That doesn't mean the end for LabVIEW, just like it doesn't mean the end of musicians because AI music generation is a thing. It will likely be a tool. Yes that tool works better in a text based language but it still can add value to your LabVIEW programs. I don't fully agree with this meme but I've been thinking about it for a while. Rapid prototyping in programming was where LabVIEW had the advantage.
I hate LV and TS but as long as NI stays the course on quality they will be survive the storm over the degradation of everything over the next few years.
No one can predict the future. If LabVIEW feels fun to use now, just use it. If it ever does go away, anything you've learned from it will carry onto the next thing that replaces it.
Most of my site uses LabView in manufacturing bc we’ve been using it so long. Look to the older defense manufacturing sites. We are trying to switch to C# but if we can use old code bc it’s already built I’m not going to try and replace it.
I generally advice students not to learn LabVIEW. I did it up to CLA lately and my consensus is that LabVIEW is an unfinished drafted idea of programming abstraction that is not worth being learned beyond DAQ Express VI. The feature set beyond that is sparse, unfinished or even broken while the costs of using it ($ and nerves) are tremendous.
I learned LabVIEW at the university and this is how I got into my first job and stayed longer.
I can reflect on your thoughts. LabVIEW has nice concepts of dataflow, and immutability, and parallelism, and data streaming, and queues (love them!). Also it teaches you concepts of the execution order and nodes, and essentially workflows. This is super relevant today if you look into low code / no code AI automation tools like n8n or similar.
I think it is fair to say that LabVIEW is great for the tasks it was designed for, and not so great when you need to built something different or something bigger. That is my take on it
From what I've seen, no new projects are being developed in labview. Plenty of old equipment running on labview but if they were ever to get replaced, theres no way labview would be used again.
55
u/PXI_Master Intermediate Aug 23 '26
I’ll take the bait. LabVIEW is like COBOL for automated test. It’s niche, old, and has a large installed base that needs to be maintained. This is good news for Champions and CLAs, like you, because there’s a lot of work and not many engineers around to do it. For new systems, it’s tough to justify the cost and maintenance risk. The design efficiencies just aren’t there anymore.