You assemble the device in the builder, or simply describe the task in plain words — the agent writes the code, compiles it, fixes the errors and flashes your board. Below is everything worth knowing on day one. Five minutes of reading saves you a few dollars and a couple of hours.
The 🧩 button in the header. Instead of describing the hardware in words, assemble it from the catalogue: what is connected, to which pins, what it does. The agent gets an exact schematic and guesses nothing — and guesses about hardware are what cause most of the rework.
🖊 Every tile has a “what it does” field — one line about the role of that part: “the relay switches the heater on”, “the button resets the counter”, “this DS18B20 measures the water in the tank, the other one measures room air”. Do not skip it. From the hardware list the agent sees WHAT is connected and to which pins, but not WHY: two identical sensors with no explanation are just two sensors, and which one is where it will pick at random. The line travels into the brief right behind the part.
A pin can be left on “auto”: the agent picks a safe one and tells you in its reply where to solder. If the board is already assembled, set the pins yourself, otherwise the agent picks its own.
The builder also catches what you would otherwise notice with a soldering iron in hand: two parts on the same pin, a display that will not fit the chip's memory, a pin without PWM where PWM is needed, a servo or motor powered from 3.3 V. Conflicts and “auto” pins are flagged right in the window.
A set is a device. You can save the hardware list under a name (💾 in the window header) and build new devices from it later. When you send it, the project gets the same name as the set — unless you named the project yourself; your own name is never overwritten, and a duplicate becomes “433 2”.
⚠ Change the board and the pins reset to “auto”, with a line saying so right in the window. That is deliberate: the same pin number means DIFFERENT physical legs on different chips (“2” on an ESP32 is GPIO2, on an ATtiny13 it is leg 7), so the old choice does not apply. Pick the pins again for the new hardware. If the board differs but its pin map is identical (Uno and Nano), nothing is reset.
The 🎨 button. Place labels, numbers and bars exactly as they should look on the display and the agent reproduces that in code. No need to explain “temperature top-left, large” — it receives the coordinates, the sizes and the colours.
The alignment buttons matter more than the coordinates. Pressing “centre” passes your intent
to the agent, so it computes the position as width/2 instead of hard-coding a number
from the mock-up. Otherwise everything shifts on a different resolution.
Character LCDs (1602, 2004 and similar) are supported too: there the grid is in character cells rather than pixels, coordinates reach the agent as “row 2, position 5”, and fonts and colours are hidden — such a display simply does not have them.
🖱 Right-click an element → “Description” — this is where a mock-up becomes a brief. The agent sees a picture: a large number at the top left. That it is a TEMPERATURE it does not know. In the “what it shows” field write the meaning: “temperature from BME280”, “time from the RTC”, “minutes left until watering”. If the hardware list is already assembled in the builder, a dropdown “— pick from the device layout —” appears above the field: take the source from there in one click, with no typos and no naming mismatches. It reaches the brief as a “meaning: …” note right behind the element — that is what ties a label on the screen to a part in the hardware list.
The same menu has “Go to screen…”: with several screens, state which one opens when this item is selected, and the agent builds the navigation you described instead of inventing its own. The screen itself has a note field — “when it is shown / what switches it”: a button, a timer, an event.
The three tools above are three separate pieces of one brief. Here is how they add up. Example: a thermostat that holds the temperature in a greenhouse.
Step 1. The hardware. Button 🧩, board ESP32, four parts from the catalogue: DS18B20, a relay, an ST7789 display, a rotary encoder with a button. Leave the pins on “auto” — if the board is not soldered yet, let the agent pick safe ones and tell you where to solder.
Step 2. What each part does. In the “what it does” field of every tile: DS18B20 — “measures the greenhouse temperature”; the relay — “switches the heater”; the encoder — “turn to change the target, press to save”. This is the step people skip most often, and it is exactly the one that turns a list of hardware into a device.
Step 3. The screen. Button 🎨: a large number in the middle, a smaller one below it, a “HEATING” label in the corner. Right-click to give each one its meaning: the large one — “current temperature from the DS18B20” (pick it from the hardware list with the dropdown), the small one — “the target setpoint”, the label — “lit while the relay is on”.
Step 4. The overall logic. The field at the bottom of the builder carries what is visible neither from the hardware list nor from the mock-up: “hold the setpoint with 0.5 °C hysteresis so the relay does not chatter; keep the setpoint in memory across power cycles; if the sensor fails, switch the heater off and show an error on the screen”.
Step 5. Check and send. The “👁 Preview” button shows exactly the text the agent will receive — read it before sending. Then “📎 Send to agent”: it writes the code, compiles it, fixes its own errors and offers to flash.
⚠ The difference between “make me a thermostat” and these five steps is not the amount of text — it is the number of guesses. Everything left unsaid the agent will invent: which sensor is where, what the number on the screen means, whether hysteresis is needed. Guesses about hardware cause most of the rework — and that is where the money and the time go.
The “+ WEB” button in the builder adds a page that opens in a browser at the board address. You don't draw it — describe in words what it should contain (“temperature readings, a watering button, network setup”) and the agent picks the layout.
Once the board joins the network, the 🌐 button lights up in the app header — that is the live page. Press “✎ Edit” and change things right on it: text, text and background colour, size, order (drag with the mouse or use ↑↓), remove what you don't need. Right-click an element for a menu with a “Note” item — say in words what to do with it. “📤 To agent” sends the list of edits and a screenshot; the agent changes the code.
If “Wi-Fi for debugging” in the settings is empty, the agent asks with buttons: set the network (quick for debugging) or build an access point with a network selection form — that is how a finished device should work, and your home password never reaches the firmware.
The builder is optional: you can describe the same thing in plain text. You can mix both — the parts list from the builder, the details in words in the same message.
The main rule: the agent does exactly what you asked for. It doesn't guess what you meant — it picks the most likely option. The more detail in the brief, the fewer fixes later.
Worth specifying: the pin, timings and speeds, whether you need Serial and at what baud rate, how many files, which library to use (if you have a favourite), and what to do on failure (e.g. "if the sensor doesn't respond, blink the LED").
If the agent asks a question in the chat, just answer with your next message. It asks on purpose instead of guessing when the choice really matters.
The model does not read minds and cannot see your desk. It picks the most likely reading of what you wrote. So the rule is simple: describe the outcome and the setup, not the way the code should be written.
Say what the result should be, not how to code it. “Average over 10 samples” already dictates the implementation. “The readings must not jump around” states the outcome, and the agent picks a filter that suits your sensor.
Give the setup — hardware and power. Which module exactly, how it is wired, what powers it. “The display does not work” and “ST7789 over SPI, backlight straight to 3.3 V, screen is white” are two different requests, and the second one gets solved immediately.
Describe the symptom, not your diagnosis. Say “fix the display init” and the agent will fix the init even if the real problem is power. Say what you see: “garbage in the right third of the screen”, “fine for two seconds, then it goes dark”.
State the boundaries. What already works and must not be touched, what is off limits, how much memory is left. Without that the agent may rewrite a working part “while it is there”.
One task at a time. Five requirements in one message are five chances for one of them to get lost. Get the skeleton working on the board first, then add.
If the agent still got it wrong, do not rewrite the request from scratch in a new chat. Correct it in the same conversation (“make it 200 ms, not 500”): it remembers the context, which is faster and cheaper than explaining everything again.
This is not a bug, and the agent is not having a bad day. It is how AI models work: they pick words by probability, so two identical answers are impossible in principle. A few more things add to it:
Modern models have no "always do it the same way" knob (temperature).
Hence the practical takeaway: refine as you go, in the same chat ("make it 200 ms", "drop the Serial") instead of "rewrite it". In the same chat the agent already sees the finished sketch and changes a couple of lines — that is faster and noticeably cheaper than writing everything from scratch.
The first version is almost never the final one, and that is not a sign that something went wrong. The agent cannot see your board and your wiring: some things only show up on real hardware — a different display batch, a sagging power supply, a bouncing button, a library built for another core version. Refining it turn by turn is how this tool is meant to be used, not a fight with it.
Saying nothing is the worst option: if you don't say what's wrong, the agent will assume it all works. Tell it, and it will finish the job.
The chat is tidy again, but the agent still remembers everything and your files are untouched. It is just housekeeping.
The agent forgets the conversation and the old sketch moves to the "_архив" folder. It starts from scratch — and does it its own way again. Use it when the task has changed.
A separate board, chat and folder. Handy when you run several devices in parallel.
Uploads the existing sketch without the AI — so it costs you nothing. When the code is already written and you just need to reflash the board, don't ask the agent — press this button.
Power lost, app closed halfway, or the reply hit its ceiling — the app starts a new conversation itself and tells you so in the chat.
Your files and sketches are safe. Just write "continue, the code is in the project" — the agent will read the sketch and finish the job. Nothing is lost and nothing needs rewriting.
Every model has a reply ceiling — how much it can write in a single turn. That is not the same as how much it can read: reading capacity is huge.
The Start model's reply ceiling is several times lower, and it silently truncates long code — the turn breaks mid-sentence. Pro has plenty of headroom, so it finishes large sketches.
Premium is the top model: the strongest reasoning for the hardest projects, with a higher burn rate than Pro.
This is an honest difference between the plans, not a setting — no limit can fix it. Simple tasks: Start. Complex projects: Pro. The most demanding work: Premium.
You pay for the model's work, and its reply costs several times more than your question. Everything else follows from that:
Your balance is visible right in the app, in the status bar.
ESP32 has two versions of its core (the low-level software the code builds on): the new 3.x (default) and the old 2.0.17. Both are installed side by side and don't interfere; there's a 3.x / 2.x button in the header for classic ESP32 boards.
As it works, the agent remembers what actually worked for that project — the pinout, a library version, display timings, a fix for a specific error. Next time it won't figure the same thing out from scratch, so it's faster and cheaper.
The memory is a hint, not a rule. Your command always wins: if something it remembered no longer fits, just say so — the agent follows you and corrects its note.
The knowledge lives inside the project, so it travels with your backups.