Simantic gives AI firmware review something to run

An AI assistant changes a register write and says the LED should now turn off. The code compiles. The explanation sounds plausible. Whether the output pin actually changes is still a runtime question.

Simantic is building a simulation layer for that gap. Its tools run compiled firmware against modeled microcontrollers, allowing an engineer or an agent to inspect behavior before a physical board is available. The founders introduced the company in an October 29, 2026 Launch HN post; its current documentation also describes an on-demand GitHub reviewer that builds firmware and tests scenarios derived from a pull request. Founder introduction, reviewer documentation.

The useful promise is a shorter evidence loop between a code change and a hardware test. This guide explains how that loop works, three illustrative uses, the difference between local simulation and cloud review, and the questions a simulated result cannot answer for a real board.

An STM32 Nucleo F401 development board at Embedded World 2016; physical firmware-target context, not a Simantic validation result. Image: Ordercrazy, CC0; resized with margins. Image source · License and image notes. Official product reference.

Compiled firmware gives a review another kind of evidence

Source review asks whether a change appears correct. A build asks whether the toolchain can produce an executable artifact. Simulation asks how that artifact behaves under a specified set of modeled conditions. Each step can expose problems the previous step misses.

Simantic's CLI documentation, checked November 2, describes a sim binary that runs an ELF against a named MCU or a scenario. It uses a deterministic virtual clock, so repeatability can be tied to the same firmware and inputs. That makes a failing scenario something a developer can return to after changing the code.

Think of this as a rehearsal bench. It gives the firmware a place to respond to inputs, emit output, and reveal mistakes without waiting for every physical part. A rehearsal still depends on the accuracy and completeness of its setting.

For an agent, the change is significant. Instead of ending with “this should work,” it can receive observations and revise a hypothesis. For a reviewer, the value is the connection between a claim and an inspectable run: the firmware version, stimulus, expected result, and actual result.

The practical goal is not to accumulate logs indiscriminately. It is to make an important claim reproducible. “The button press produces one event after debouncing” is useful when the stimulus and observation are explicit; a large transcript saying the firmware looks healthy is much harder to assess.

Original explanatory diagram based on Simantic's CLI and PR reviewer documentation, checked November 2. Real-board validation remains a separate step.

A register mistake is easier to discuss when the output disagrees

Simantic's public homepage shows a small firmware example involving an LED output register. The example's message stream says the LED turns off, while the observed pin remains high; the proposed correction changes the reset-bit offset. This is an official demonstration, not a result from running our own board or firmware. Simantic homepage, checked November 2, 2026.

The example captures a general review problem. Application logging can describe intent rather than the actual hardware state. A message printed after a write does not prove the write affected the intended register bit. Observing the relevant modeled signal creates a second source of evidence.

In an illustrative team workflow, a reviewer starts with the expected pin transitions and checks them against the trace. The code explanation becomes a hypothesis about why a transition did or did not occur. That is a firmer conversation than debating two plausible interpretations of the source alone.

The same discipline applies to test design. If the expected result checks only the log message, the test may reproduce the developer's assumption. A stronger scenario checks an observable effect that corresponds to the intended behavior, within the simulator's supported model.

Keep the artifact and configuration together. A trace from one build cannot establish the behavior of a later commit, and a result for one MCU does not automatically transfer to another. The review should name what actually ran.

A button and timer make a practical first scenario

For a first illustrative use case, consider firmware that handles a button press and toggles an output after a delay. A source change adjusts the interrupt handler or debounce logic. The important question is whether one intended press produces the intended action at the right point in the modeled sequence.

Define the scenario before asking for a judgment. Specify the initial input state, the time of the transition, the observation window, and the expected output. Then add a second case with repeated transitions to represent contact bounce at the level your model supports.

This does not require a grand claim about a complete device. It is a bounded check of input handling and resulting firmware behavior. If the model lacks a peripheral or a relevant interaction, the result should name that gap instead of converting absence of evidence into a pass.

The review's next step can then be precise. A simulated failure suggests a code or configuration issue to investigate. A simulated pass advances the change to board testing for electrical behavior, real switch characteristics, timing margins, and the rest of the system.

For a team adopting the tool, a deliberately small scenario is valuable. It lets engineers compare what the simulator observes with behavior they already understand on a board. Confidence should grow from those concrete comparisons, not from the sophistication of the generated review prose.

UART changes need expectations beyond a boot banner

A second illustrative scenario concerns serial communication. A firmware update changes initialization or message formatting. A build succeeds, but the application may transmit at the wrong stage, omit a message, or react incorrectly to incoming data.

A useful scenario gives the firmware a known input sequence and checks the corresponding output. Include an ordinary command, an incomplete command, and an unexpected value. A boot banner proves that some execution reached a print path; it does not prove the command parser handles its contract.

Separate the protocol behavior from the physical link. The simulated run can help evaluate supported UART and firmware behavior. A physical board still needs testing for the actual electrical interface, connected equipment, line conditions, and any unmodeled behavior relevant to the product.

For agent-assisted development, ask the assistant to explain each assertion in terms of the scenario. Which bytes were supplied? What output was expected? What was actually observed? That structure makes a suggested fix easier to review and a regression easier to preserve.

The CLI reference, checked November 2, documents UART output, timed inputs, expectations, and recorded evidence. Choose the relevant observation channel for the question rather than treating every emitted message as equivalent proof.

An unavailable board changes the order of work, not the acceptance standard

A third scenario is a team waiting for a prototype. Firmware work can proceed against a supported MCU model while the physical board is being manufactured or shipped. Engineers can exercise boot paths, basic peripheral interactions, and selected error handling before hardware arrives.

This can expose assumptions earlier. A code path that never reaches initialization, a register sequence that produces an unexpected modeled state, or a missing response to an injected condition can be investigated without occupying a shared lab board. The later hardware session can focus on the questions that genuinely require the physical system.

It also creates a planning obligation. Keep a list of requirements covered by simulation and requirements deferred to hardware. A simulated pass on one subset should not silently close a broader acceptance item.

For example, a motor-controller application may contain ordinary protocol logic as well as power-stage behavior. A test of the command parser says nothing by itself about switching performance, sensor fidelity, electromagnetic interference, or safe operation. Those require suitable models, equipment, and engineering procedures.

Our take is that the strongest use of early simulation is to sharpen the eventual hardware test. It can reduce avoidable software surprises while making the remaining physical questions more explicit.

The PR bot runs when requested; it is not automatically your CI gate

Simantic's reviewer documentation, checked November 2, says the GitHub assistant runs when someone mentions @simantic-bot on a pull request. It builds the changed firmware, creates scenarios from the diff, and posts a review. New commits require another request. A simantic.json file can provide project information.

That interface suits targeted review. A maintainer can ask about UART changes rather than commissioning an unbounded repository inspection. It also gives the team a clear invocation point for access, spending, and review expectations.

The company's homepage separately advertises Cloud Sim and CI/CD integration. That broader offering should not be confused with the bot's documented trigger. An on-demand review does not become a required test on every push simply because both features involve simulation.

A team that wants a merge gate needs to establish its actual automation separately: trigger, supported build environment, expected scenarios, timeout behavior, and the result that blocks or permits merging. The existence of an informative review comment does not define those policies.

The bot's fallback behavior matters too. Its documentation says unsupported MCUs receive static review without simulation, and failed or incomplete execution is identified. Read the status before relying on the conclusion. “Reviewed” describes an activity; “the changed behavior was simulated successfully” describes a narrower result.

Local execution and cloud review have different data paths

Running firmware on a local machine and connecting a GitHub repository to a hosted reviewer are different choices. The CLI documentation says each run checks account credentials with the backend. Local simulation therefore should not be described as a completely offline workflow. CLI requirements, checked November 2.

The cloud reviewer clones the repository into a temporary container. Its privacy description says the diff, build output, and simulator output are sent to Anthropic under Simantic's agreement, while review information is retained by Simantic. It also describes controls for stored firmware. Establish those settings before submitting sensitive code.

The reader-facing question is straightforward: which artifacts leave your environment, which services receive them, and what remains afterward? Logs can include project details even when the firmware file itself seems harmless. Treat build scripts and diagnostic output as part of the data review.

Original interpretation guide. Simulation evidence, inconclusive coverage, and real-device results answer different questions; no device performance is measured in this diagram.

Begin with a known artifact and one expected observation

The CLI requirements, checked November 2, list Apple Silicon macOS and x86-64 Linux, with Windows using the Linux build under WSL2. They also require Python 3.12 or newer and an account. Native Windows support should not be inferred from the WSL path.

1. Check the supported MCU list. Use sim models and confirm the exact target and its support status before designing a test around it.
2. Install through the official instructions. Use the platform-specific path in Simantic's documentation and complete its account authentication flow. Keep credentials out of source files and logs.
3. Build known firmware. Start with a small project whose expected behavior you understand. Preserve the commit, build command, and ELF path.
4. Run a bounded observation. The documented command shape is sim <MCU> run --elf <firmware>. Set the run duration and relevant output options from the CLI reference.
5. Add a stimulus and an expectation. Choose one supported input event and one observable result. Keep the configuration beside the test so another engineer can repeat it.
6. Inspect failures and gaps. Distinguish a build failure, simulator limitation, inconclusive scenario, and observed firmware failure. Each calls for a different next action.
7. Compare with hardware when available. Run the corresponding board test and investigate meaningful differences before expanding reliance on the model.

For GitHub review, begin in the Simantic dashboard, connect the intended repositories, and request a narrowly scoped review. Check the current plan allowance and overage settings first. The documentation describes usage-based review work, so included access should not be interpreted as unlimited free execution.

Preserve a failing scenario before asking an agent to fix it

When simulation reveals a problem, keep the original failure available. Record the firmware revision, build inputs, scenario, and observation that established the mismatch. Then ask the agent to propose the smallest change that addresses that behavior.

The next run should do more than stop showing the original error. Check that the intended output appears and that nearby behavior still follows its contract. A fix that disables the relevant code path can make a warning disappear without restoring the feature. Positive expectations help prevent that false success.

Review the scenario too. Because a generated test is another artifact produced by an agent, it can contain mistaken assumptions. An engineer should verify that the stimulus represents the intended condition and that the observed signal actually answers the question. A reproducible test is valuable, but reproducibility alone does not establish relevance.

Over time, this creates a small regression library organized around real firmware behavior. Some scenarios will remain fully simulated; others will have matching board procedures. Keeping their scopes explicit helps future maintainers understand why a test exists and which requirement it supports. The result is useful even when a later hardware discovery forces the model or scenario to change, because the original reasoning and evidence remain visible.

Runtime evidence makes the next hardware question better

Simantic's useful contribution is a place where firmware claims can meet observable behavior earlier. That can help both engineers and AI assistants move from plausible source changes to reproducible questions.

A strong review says what ran, what was stimulated, what happened, and what remains outside the model. The physical board still has the final word on the physical product. Simulation earns its place by making that conversation more informed.

Sources

• Simantic founders' Launch HN introduction, October 29, 2026.
• Simantic official product page and demonstration, checked November 2, 2026.
• Simantic CLI documentation, checked November 2, 2026.
• Simantic PR reviewer documentation, checked November 2, 2026.

Keep your review connected to its source

Telli.sh is one option for retaining authorized source material and the notes behind a technical decision. Create a note workspace.