Building Perspective with an LLM

[nminchin]

@jpreese246

AI is absolutely ducks guts on working with the JSON files. It makes very stupid mistakes and you often have to “start over”

I would suggest you don't get Claude to process your json files, but create tools in scripts (eg python) that will do what you want, and enable deterministic repetition at the same time

[Nol]

IMO Gemini is surprisingly good at working with Json files but you also have to approach it appropriately. I use a lengthy detailed GEMs instruction (~10 pages). Then also feed it in an example structure and it's quite good at making edits. I've also used it to create a few thousand line tag structure and one shot it. But as with everything, need to always verify the results.

[carles.centeno]

@bkarabinchak.psi

Genuine question, what is the value add of a lot of these commands? Any of the list_resource style command you are now introducing the non-determinism of a LLM where you can see it directly either in designer, in the gateway, or you could code up a very simple deterministic API endpoint to serve you the values. Same with any read_resource thing. Feels like you're just injecting a LLM into a spot where there's already a very simple and deterministic way to do something, and now introducing the odd hallucination.

I can see write_style being very helpful espeically as someone who is not well versed with CSS but that also is typically the least important of the HMI at least in terms of the damage it can do, and in terms of verifying it, I can just look at the project view and see if it looks right and if a component is being hidden it shouldn't be etc.

All these others. Are you really shipping products where a LLM wrote the code and queries and did the bindings on a view and configured the tags etc? I know you'll probably say you review it all but I also know the research shows that after a few good responses or after sufficient fatigue developers stop checking responses, so it may be true now but if you start getting on the pace of oh we can ship a project a week, your hand reviewing will start to dwindle. Not to also mention if you're reviewing every single line of code and every single component binding and every single tag config after the LLM did it, then it feels like now you actually doubled your work then if you just did it yourself the first time correctly?

I don't know maybe im turning into a crank about LLM's but even if you do the best of things, and I am not saying you don't, the possiblity that someone out there is shipping projects with code, tag configs, queries, etc etc, that they are completely trust claude or w/e did correctly after one cursory glance, is scary to me in this field specifically where physical harm is a potential outcome.

Sorry I know this is a pro LLM forum post here but I am not saying that LLMs are completely useless but I still think a lot of your commands here seem like a solution looking for a problem and maybe there is a better use case for it in iginiton in general for the mcp module?

What the MCP allows me to do is enable a code AI to handle a project that the AI ​​didn't start—for example, a project started by a vendor who has stopped working with my client.

The AI ​​summarizes technical aspects of the "how" in just a few minutes, aspects that would take me several days to figure out.

Furthermore, it allows me to learn much faster, as it has ideas and applies quite sophisticated solutions to problems I'm unable to solve.

It's clear that it's not a direct relation between LLM->Ignition->a lot of money.... by the moment, that much is obvious, but when used correctly and with a clear understanding of what it's doing and how it's doing it, it allows me to develop screens much faster than before.

And regarding the generated code, it's not obfuscated at all; quite the opposite, it's commented, structured, well-organized, and above all, highly reusable across different projects.

But I understand your opinions, and it's true that you can't use LLM for everything, because in the end we'll become stupid and won't know how to do anything ourselves.

Thanks a lot

Carlos

[Rudy.Ind.Automation]

I’ve had pretty good results with this by using SKILL.md files instead of trying to solve everything with one giant prompt.

Fo those that dont know a skill.md is a small context file that teaches the agent how a specific thing works.

For my setup, I built a Web Dev API in Ignition 8.1+ so the agent could interact with the gateway instead of guessing. Then I had a loop where one agent would write tests, another would improve the skill, and another would add API routes when the agent needed a new way to inspect or validate something.

So this created a feedback loop.

The agent would try something, run it against the gateway, check logs/screenshots/API responses, figure out which assumption was wrong, update the skill, and try again.

That helped a lot with things like:

• not inventing fake system.* functions
• not writing Python 3 when the gateway needs Jython
• learning what valid Perspective JSON actually looks like
• learning module-provided scripting functions instead of guessing them
• testing assumptions before treating them as rules

I used the same approach for Perspective pages, Jython scripts, SQL helpers, UDT import/export, creating importable perspective zip files, MQTT module scripting functions, expression language, alarms, logs, and a few other areas.

it won’t solve everything. But for 80% use cases it works and as of now i have not had a halluciantion.

For Ignition 8.1+, I had to build the API myself with the Web Dev module. For Ignition 8.3, the built-in API looks like a good starting point, though you may still need extra routes depending on what you want the agent to inspect or validate.

I made a YouTube walkthrough called “Building Perspective Pages in Ignition 8.1 with AI Agents” if you want to see the setup and demo. No link here because I don’t want to trip any filters, but it should come up if you search that title.