AI coding assistance is surprisingly changing the way developers and integrators work, and it raises some interesting questions about what will happen in the coming years — maybe over the next 2–5 years.
AI can already help with a lot of the development work involved in Ignition: scripting, Perspective, SQL, React/TypeScript, custom components, and even more complex development tasks.
As these tools continue to improve, how will this affect the role of an Ignition developer or integrator?
Will development skills become less important, while things like domain knowledge, system architecture, OT/IT integration, commissioning, troubleshooting, cybersecurity, and understanding the customer's process become more important?
And what happens to the traditional business model of an integrator when development work can be done much faster with AI assistance?
I'm curious how other developers and integrators see this.
Has AI already changed the way you work, and what do you think will become more important for an Ignition developer or integrator in the coming years?
The AI tools will speed up development on some things and people who crutch on it too much will probably have terrible and embarrassing experiences periodically.
AI will probably let you faceroll your way through a greenfield project for large systems that have a lot of similar equipment built on the same standard with modern technology (like a data center and things like that) because scale isn't a problem for AI.
I don't think it will do well in a lot of SCADA migrations. It will get better over time but I think there will be a gap for a while.
Some of the systems I migrate predate the internet. AI won't have access to good information on how to migrate those. I'm sure some people's solution to that will be to just rebuild the whole system. Those systems didn't get that old because the customer operates like that.
I haven't seen AI do a good job of building P&ID type screens either. I've seen examples where P&IDs were built automatically and they were not impressive to me and certainly wouldn't be impressive to most of my customers. I've heard a sentiment that you don't need P&ID screens and that is probably true in some industries but I don't believe that is generally true which is why I keep making resources for building them for other people to use. Also, having auto-generated P&IDs that look worse than the original screens is not perceived as an improvement to a lot of customers. I believe the solution to migrating old systems into Ignition involves doing the work.
My experience is that customers usually want P&IDs if they already have them and they want them to look at least as good as the old ones and function similarly to the existing screens because they don't want to have to retrain all their operators.
The integrated AI tools to streamline writing expressions and stuff like that will probably be significant time savers. The AI tool on the help site is fantastic.
Ultimately, I think it's important to be able to do the work and it's really important to validate any work you automated. The AI empowered search tools will allow people to do great development and troubleshooting with less tribal knowledge in much the same way that internet search has allowed people to build better things.
I don't believe there is a substitute for knowing what you're doing.
Last year I released a Markdown+ Editor on the Exchange. Shortly thereafter I discovered Claude's ability to code HTML/JavaScript/CSS, and with his help, realized that I would be able to turn it into a true WYSIWYG editor like the one I'm typing in right now. I was excited about that, but soon became distracted by an obsession with using AI for my own personal projects, and it sat on the back burner until last night.
I was just finishing up work using Claude to fast-track a design overhaul at work that I'd been wanting to do for quite some time, and then before I left work I decided to resurrect what I had started a year ago, and crafted this prompt:
I definitely have mixed feelings about AI. But as a software engineer, the coding has always been just one part of my job, and frankly, not the most important part. The iterative design and testing still requires my expertise, and even the coding part can go astray if the person writing the prompts doesn't understand what it is they are asking for.
Claude went above and beyond, even giving me new features to test out...
From personal experience, current LLMs are very good at coding, and really terrible at engineering. Maybe I'm just holding them wrong, but in my experience by far the most important part is to get your data model/data structures right in your head first. Which really isn't a change from how (good) engineering happened before, it's just that now there's nothing stopping someone who doesn't care from churning out tens of thousands of lines of code every few minutes.
That said, the models are only getting better (though a lot less quickly than before). Maybe that will change
As for other, broader things, I like this old chestnut:
The only things ive used AI for are more complicated SQL queries. AI has been shockingly good at writing these queries for me, i had one case where it managed to do what i wanted but it didnt run that fast, i just asked it to improve performance and it did no issues at all.
While i was happy with the result i do know that i learned absolutely nothing where if i had bothered to do the task myself i would know more about this type of sql operation and what goes into making a query more efficient.
I see AI as like a toddler that sometimes has cosmic intelligence. sometimes you see it do something and you're like I'm insanely impressed that it was able to do that. then the next time you look at it its sticking a fork in an outlet
The skill gap between queries and more complex queries is such that it feels like I spend just as much time reading and researching the AI output query as I might have if I wrote it myself.
To answer the broader question, I wrote about my own experience recently in a similar post, but I am on the Luddite end of the AI implementation spectrum. While it might save me time, I just can't justify forgoing the opportunity for learning, understanding, and skills development. I'll be the one supporting it, I want to intimately understand it.
If you're using it to do your homework for you, then yes, obviously it will hinder your ability to understand the thing you're supposed to be learning. But if you're using it to help cure Alzheimer's, then you're likely to start understanding stuff you've been struggling to understand for some time.
Google and GPS have already been effecting our inclination to figure things out on our own. AI is just the latest in a long line of technologies that have made our lives less challenging. The calculator, the wheel...
Will it make us lazier? I don't think so. Those inclined toward laziness will get even lazier, but those of us with a drive to create will find it empowering.
The #1 goal is to not let AI be smarter than you, it is a tool. You have to know what it's doing 100% of the time. I've been in system integration for 25 years, so I've seen a lot. AI is making me more efficient, and it isn't doing anything I haven't built a guardrail for. You can't tell a script I wrote 5 years ago from one it writes today, because I have skills that tell it exactly how I program.
90% of the work I have AI do is the stuff I don't want to do: documentation. I have it documenting the full Gateways - scripts, transaction groups, named queries, and Vision and Perspective screens, how it interacts with Databases - tables, stored procedures, and triggers. It outputs everything as .md files, and Obsidian shows the knowledge graph. We have large gateways, and when a customer calls with an issue, it helps me remember quicker how it flows through the system. An agent can also be asked questions about it.
I feel I grew up in this field at the right time. I see it in my office, younger guys don’t struggle and learn through mistakes the way I had to, if they default to asking an agent to do their work. So they must learn the hard way before diving into having AI do the work for them.
Admittedly, it’s been a while since I’ve done much experimenting with this, but I tried it for the same reason you mentioned. What I found was that it would make mistakes and occasionally invent some pretty embarrassing falsehoods. Most of the time, I spent more effort cleaning it up than I would have spent just writing it myself.
I suppose a fair argument could be made that nobody actually reads that stuff anyway, but ya never really know.
Nowadays, I’ll feed it a paragraph at a time for proofreading and polish, but never more than I can reasonably reread and verify myself, and I never give it free rein to invent its own explanations for my products.
To clarify, I'm not talking about having it write operator documentation, like having it write paragraphs explaining what a screen does. I mean system genealogy for a programmer who has to troubleshoot.
a tag change fires a gateway script, the script calls a named query, the named query executes a stored procedure, the stored procedure inserts into a table and does some other calcs, and an insert trigger on that table fans out to several other relational tables. This is spread across the Designer, the gateway, and SQL Server, and none of it is visible from any single place and catch myself having to reverse engineer this every time and be like oh yeah I remember - well now it is documented in a knowledge graph and I can ask questions on how it works.
It gets this right because it can build the knowledge graph and knows how to trace it through the system.
Is there any equivalence between having it do your homework and writing scripts / doing work for you? If you think there's any overlap at all, then it should concern you that skills you no longer directly do become a candidate for nueral pruning.
Google and GPS have already been effecting our inclination to figure things out on our own. AI is just the latest in a long line of technologies that have made our lives less challenging. The calculator, the wheel...
London taxi drivers who don't use GPS had significanlty larger posterior hippocampus's than non-professional tax drivers. Funny enough this has a relation to your mention of Alzheimers - Why Taxi Drivers Don’t Die of Alzheimer’s | Harvard Magazine . Always offload to GPS and you will never get any of the benefit.
Physically we have been getting weaker for decades now and for what I imagine is similar reasons, offloading of things that we used to need to do physically to something else combined with inreased sedentary lifestyles encouraged by screens.
I personally have a strong distaste for the point of view that all friction in life is just some technical problem to be solved. The overcoming of problems is one of the great joys in life. It feels good to do things on your own and to be self sufficient even if it just driving to a place by memory or doing some mental math. I do think this is a big split for people though and other people would say the exact opposite or think its foolish to walk to the store when you have a car.
I haven't tried using AI to write SQL queries but I tend to tune my queries to make sure they are performant and I am hesitant to trust AI to tune queries. Also, as you said, a lot of SQL queries don't really take that much time to write in the first place.
I think it is going to be great for automating some of the more annoying tasks in SCADA migrations like tag imports.
One of my projects involves upgrading 2 SLC PLCs to new CLX PLCs. One of the old systems that was collecting data from the old PLCs died before we got to the startup. So now they want to grab that data in Ignition using SLC tags and then update them to CLX tagpaths after the PLC upgrade. I fed the spreadsheet the controls engineer provided me and asked it to make a text file with JSON for Ignition tags. It looks like it worked.
I'm ok with it if I never have to write or modify another tag import script.
