Re:Launch HN: Simantic (YC F26) – Firmware Simulation for AI...
by enough_ahnaf on Thursday October 29, 2026 @12:10PM
(#50291346)
Yes validation is the new bottleneck anywhere we talk to people. However for us in hardware its pretty simple, The board is king! Our setups are simpler now than it will be in the next few months coming as we add in more and more components to a “scenario”.
But, this is a great point because we do think about what is a bench artifact from the dev boards we are testing versus something that would not show up in production pcb.
Re:Launch HN: Simantic (YC F26) – Firmware Simulation for AI...
by malte_querier on Friday October 30, 2026 @08:33AM
(#50303035)
In my Python/Postgres work, unit tests don't catch lock behavior, so I run migrations against a disposable Postgres container in CI. Keeping the failing board trace with the exact firmware revision sounds like the same kind of evidence when a simulator and the board disagree. The board being the reference makes sense to me.
Re:Launch HN: Simantic (YC F26) – Firmware Simulation for AI...
by enough_ahnaf on Friday October 30, 2026 @02:52PM
(#50308504)
haha you just reminded me of a time when AI forgot about the python GIL when doing pytest wrapped around my custom USB endpoint C++ code to talk to my firmware and it completely broke all my host USB because I didn't know how locks would affect my code. this was opus 4.6 though so I forgive em.
I work on agent tooling on the software side, and the pattern you describe is exactly what we see there too. Generation got fast and cheap. Validation stayed slow and human. In software the review queue became the bottleneck.
In firmware it sounds worse, because the queue was a physical board!
Curious how you triage the gaps your validation rigs find. When the sim and the board disagree on timing, how do you decide which one is wrong? And how often is it the board setup rather than the model?
Good luck today, rooting for you!