I like using non-standard approaches to introduce new features in ServiceNow. I believe this is one of the most effective methods because people can connect the feature to an unusual concept, making it much easier to remember later.
In this post, I am going to write about my experience of using Now-SDK and AIUX. The topic I chose for this metaphor is cooking. 🙂
This project has been sitting in my backlog for a while, but I have finally finished it, and I think it works quite well.
Storytelling
Let me start with a short explanation. I bought an electric smoker some years ago. This one:
The electric smoker
It is very simple and doesn't have any temperature control options. You just plug it in, and it converts 1 kW of electricity directly into heat energy. This is great, but not necessarily for cooking. 🙂
To make great BBQ food, temperature control is one of the most crucial things. So, I decided to make my electric smoker smart.
Making the smoker smart
The plan was to set up a hardware system that can measure both the chamber and meat temperatures, and switch the smoker on and off using a relay.
I don't have deep knowledge of DIY electronics, so I used AI to design the architecture for the solution. The diagram below shows the planned setup.
High-level architecture drawing
I bought all the components and assembled them, then wrote the software for the microcontroller.
Here is an image of the hardware (including all components) before connecting the high voltage:
The prototype
It looks like a great prototype, doesn't it? 😊
The software itself is very straightforward. It provides an endpoint where the following actions can be executed:
- Get the temperature of the chamber sensor
- Get the temperature of the meat core sensor
- Switch the relay on or off
- Get the status of the relay
A pinch of safety
It is worth mentioning, I built two important safety features into the software:
The software implements X-API-Key header authentication on all REST endpoints to block unauthorized HTTP requests from controlling the smoker or reading sensor data.
Additionally, there is a 30-minute safety timeout mechanism that automatically shuts off the heating relay if no valid client request is received within the specified interval.
I know there are several other security improvements that could be made, but this was enough for the first version.
Testing
Now comes my favorite part... 🙂
Once the software was done, I could start testing it. The initial tests were executed without using the smoker itself. I used a hair dryer 😅 to heat the sensors or as you can see in the image below, a cup of water to test and calibrate the meat core temperature sensor. Of course, using brand-loyal tools! 😄
Temperature calibration
Finally, the first version of the hardware was complete and ready for cooking:
Ready to cook
There are two boxes, because I isolated the high-voltage section from the microcontroller. I think it is safer.
Smoker controller software
The hardware was ready but the controller software was not. I started by planning it out and setting the following requirements:
- Use the Now-SDK
- Build the front-end based on AIUX
- Vibe code the solution completely (I wanted to gather experience whether this level of complexity could be implemented this way)
During the implementation, I used VS Code with the GitHub Copilot extension.
As a first step, I had to install and / or set up all the prerequisites:
- VS Code extensions:
- ServiceNow Fluent Language
- ServiceNow Lux Lab for VS Code
- Node.js
- Now-SDK
I had tried vibe coding several times before, but this time I tweaked my approach. Instead of writing a whole "novel" about what I wanted, I had a continuous dialogue with the AI. We planned the solution step-by-step and built up the concept together. In parallel, the AI saved all relevant information into Markdown (.md) files to make it easier to reload the context later.
Once the plan was complete, I didn't ask the AI to implement everything at once. I stuck to the step-by-step approach during the implementation phase as well.
Implementation
Combining Now-SDK with Fluent enabled me to keep app metadata, server-side code, and the front-end all in one local repository. AIUX provided the essential UI components for a full control dashboard: gauges, forms, lists, dialogs, and alerts.
In general, lists and forms are used for the device and session management.
List view in AIUX
The dashboard brings together everything in one place:
- Live chamber and meat temperatures
- Relay status
- Connection and polling indicators
- Session setup and target parameters
- AI cooking phases and manual checkpoints
- Historical temperature data and action logs
The dashboard, alias Smoker Control room
A temperature gauge gives you a snapshot of the present, but the activity log tells you the backstory, which was very useful, especially during the problem analysis.
In fact, the idea to create a history table was suggested by the AI itself. It proved to be a fantastic recommendation because the AI could use this log to analyze recorded data and fix issues. This was much faster than any manual debugging I could have done.
I relied on this feature during the first 2-3 real cooking sessions as well. Whenever I ran into an issue (for example, inaccurate temperature control), I simply asked the AI to analyze the data, identify the problem, and apply the fix.
Important architectural decision
There was an important architectural decision during the project: the AI model does not directly operate the relay.
Instead, an LLM (I used OpenAI to access an external model) is asked to generate a structured cooking plan. The plan describes phases, temperatures, timing, instructions, and manual actions. The application validates and saves it as a draft for review.
After approval, deterministic server-side code interprets the plan and makes control decisions.
The division of responsibility is clear:
- AI: Proposes a cooking workflow.
- Application code: Validates and executes it.
- User: Performs physical actions and confirms the result.
A recipe can include preheating, smoking, wrapping, finishing, and resting. Manual steps pause heating and ask the user to take action before continuing.
This is where the project became much more interesting than a simple remote thermostat: it combined physical measurements with a human-in-the-loop workflow.
Developing with an AI assistant
I have already shared some thoughts about AI-based implementation, and there are certainly several advantages. It is much faster than traditional "handwriting" code. The context used by the AI provides enough headroom to investigate issues or implement new features in a complex solution, and this context can be built up very quickly. I can read code, but the task becomes much harder when asynchronous actions or complex algorithms are involved. AI handles these with ease.
An AI coding assistant helped me implement the application, investigate logs, trace control decisions, and add regression tests. While that accelerated development, it also demonstrated a key limitation: plausible code and confident explanations can still contain incorrect assumptions.
Some defects only became obvious when the application actually interacted with the physical smoker.
The most effective development cycle was:
Implement -> Observe -> Inspect evidence -> Correct assumptions -> Test
The project now has 36 regression tests covering controller behavior, safety boundaries, recovery mechanisms, plan validation, and the new quality workflow. None of them were written by me. 😅
These tests use mocked platform records and relay calls. They help prevent software regressions, but they cannot verify physical sensors, thermal behavior, or the taste of the food! 😋
However, I can see a big danger in this direction, and I felt it myself. AIUX is based on Lit, which builds on standard web components, but the paradigm is not quite the same as AngularJS or React.
AI provides a comfort zone that allows you to implement things without truly understanding what is happening "under the hood." You can get used to this convenience very quickly. Is it good or bad? I don't know yet, but for now, I can say that I don't particularly like it.
What I learned
The most important lessons were not about rendering a gauge or calling an API.
- An operating limit is not an emergency limit. (I mean temperature limit of course.)
- Turning off a heater does not immediately stop the temperature from rising. (Inertia... yes, I studied physics, but that was a long time ago. 🙂)
- A cooking plan is a workflow, not just a sequence of target temperatures.
- Physical actions require explicit acknowledgment.
- A technically completed process can still produce an unsuccessful result.
- AI-generated instructions require deterministic constraints and human judgment.
- Good recovery behavior matters just as much as the happy path.
I also learned a new word: hysteresis. To be honest, I didn't even know this term in Hungarian (my native language) either! 😄
AIUX in a nutshell
I really enjoyed working with the Now-SDK and AIUX. Copilot (using the SDK skill) is aware of the AIUX components, and can use them smoothly. I didn't face any unmanageable issues during implementation, and I never had to change my approach or look for workarounds just because a component was unusable.
I really like this new way of working. From a design standpoint, I think this approach is modern and easy to use. While there are plenty of predefined components, you can also create custom ones, much like directives in AngularJS or custom components in Next Experience (using UX Framework component builder or UIB Component builder). In fact, the available AIUX components are quite similar to the UIB ones.
So, long story short: I have had a very positive experience using AIUX.
If you would like to read more about it, check out the official documentation HERE.
This is more than a smart controller
For a personal side project, occasional debugging is part of the fun. However, connecting software to a real heating element gives those experiments real-world consequences, making clear explanations and independent safety mechanisms essential.
For me, the true value of this project is not that ServiceNow is the obvious platform for a barbecue controller. And I know that similar solutions are available on the market and you don't need to build your own.
Rather, it is that the experiment makes several abstract concepts tangible: structured AI output, connected hardware, application workflows, live visualization, deterministic automation, and human decisions.
And the fact that I was able to do this...
It provides a memorable acceptance test:
The dashboard can be green, the workflow can be complete, and yet the pork can still be tough.
That is a valuable lesson that goes far beyond barbecue.
Bon appétit.
#now-sdk #aiux #development #ai
