Yeah, ok, maybe off topic. But the story could be of some benefit to new people out there who are thinking of using it.
I see there's a thread ChatGPT - end of an era but it's in the lounge and I can't get there.
I had a small project to back files up with rsync and hot GPT to help me.
An exec node to get the list of files/directories, a function node to format the desired ones, another exec node again to rsync.
It wasn't working and things were getting annoying as I was asking it to filter which files were used as there were a lot of them and I thought to only get recent ones.
The debug node was constantly spitting out al the names, despite all the stuff to filter them.
It wrote the code/flow. All itself.
After a LOT of back and forth with GPT sending me down another rabbit hole I noticed a subtle mention of msg.rsynccmds and checked the second exec node.
It was set to msg.payload. (I'll come back to here later but for now)
So I changed that and informed it of the discovery and it (GPT) kinda just said Ooops.
Still didn't work.
The append msg wasn't set either.
Set it, and all worked.
Conclusion:
CHECK THE CODE!
But I can't understand how it happened.
(Kind of)
IT wrote the code.
So msg.rsynccmds was known.
And the exec was set to payload and not rsynccmds.
And the include message box wasn't ticked.
Because chatgpt has no idea, it is just a 'best next word predictor' based on a number scoring system, it needs a lot of guidance and guardrails, that is what you need to provide. If you don't provide this, it will come up with its own ideas based on the best next word prediction. AI/LLM's are not easy if you don't know how to deal with them.
if you give it a prompt:
i want an rsync flow
ok whatever, i will do something
vs
Create an importable Node-RED flow using the exec node to run an rsync backup. The flow should use msg.source and msg.destination for the backup source and target directories, respectively. Include an inject node that lets users manually input these properties. The exec node command should dynamically use these msg properties as placeholders in the rsync command. The flow should capture and log stdout and stderr of the exec node, and handle errors by notifying if the backup fails. Add comments throughout the flow explaining the use of msg properties and placeholders.
Just a some example, but you will get vastly different results.
msg.payload has a higher scrore in the system unless you tell it: make sure that the properties are correctly set through the flow and you verify your work blabla etc.
This is very true. I've already done quite a bit with AI's now both at work and play. I am always checking out and learning from people's AL instruction guidance files. My GitHub copilot-instructions.md file that guides AL support when working on UIBUILDER is already nearly 100 lines long. Shared below in case it inspires others.
Even then, if you ask an AI about something that does not have a lot of public published information, all of them are designed to please, that's how they are designed and that is what causes them to hallucinate answers.
My copilot-instructions:
Copilot Instructions
This repository is a set of nodes to be used with the Node-RED platform along with some front-end libraries and web components that complement them. This makes up a web application development framework focused on low-code solutions. It allows users of Node-RED to create web applications with minimal coding effort.
When contributing to this repository, please adhere to the following guidelines to ensure code quality, maintainability, and consistency across the project.
Repository Structure
nodes/: Contains Node-RED node definitions and related code. The libs/ subdirectory holds shared libraries used by multiple nodes.
frontend/: Contains the live, built front-end libraries and web components that complement the Node-RED nodes.
src/: Contains the source code that must be built for live use.
front-end-module/: Contains source code for front-end components and libraries before they are built.
components/: Contains reusable UI components used across the front-end modules. These are mostly built into the front-end library.
editor/: Contains source code for the Node-RED editor UI components that have not yet been converted to use the resources/ folder.
doc-bundle/: Contains source code that is built to enable the Docsify based documentation to work offline.
resources/: Contains static resources used by Node-RED nodes in the editor UI.
templates/: Contains folders that are either copied to the deployed Node-RED instance or used as templates for front-end instances.
docs/: Contains documentation related to the project, including usage guides and API references
Core Requirements
Follow project ESLINT configurations
Ensure WCAG 2.2 Level AA compliance
Apply Shift-Left security practices
Adherence to Best Practices: All suggestions, architectural patterns, and solutions must align with widely accepted industry best practices and established design principles. Avoid experimental, obscure, or overly "creative" approaches. Stick to what is proven and reliable.
Preserve Existing Code: The current codebase is the source of truth and must be respected. Prefer preservation of existing structure, style, and logic, however, present good alternatives where they exist.
Code Style
JavaScript/TypeScript
For node.js, use features available to the latest LTS version but warn if using features not available to v18
For browsers, use features available to 90%+ browsers/users
No trailing semicolons
Single quotes for strings
Use trailing commas
Indent code blocks with 4 spaces
Use const by default, let when needed
Prefer arrow functions
Use optional chaining
Add JSDoc if missing
Add TypeScript types/interfaces even for JavaScript files
Assume the use of ESLINT v9
Documentation
Include JSDoc for functions and classes
Place the first line of JSDoc description on the same line as the /**
Add @param and @returns tags
Document thrown errors
Include usage examples for complex functions
HTML/CSS
Use semantic HTML elements
Only use features available to 90%+ browsers/users
You can also add/specify the commands it needs to execute to perform the tests, playwright is used a lot nowadays as mcp server to actually verify things like accessibility where it can test the projects and read the console.
There is a thing called 'speckit' from github, which is completely based on spec driven development where it sets up all kinds of task lists (like jira tickets) and signs them off once testing is successful etc. This is where people get into those massive monthly AI bills because everything is automated
