A colleague recently told me they no longer need tools like UMTSM because they use AI to generate their code. I have heard this more than once. It is a fair challenge, and it deserves an honest answer — not a defensive one.
So let me try to give one.
What AI Is Actually Good At
I will not pretend otherwise. If you ask Claude or GPT-4 to implement a simple state machine in C++, you will get something reasonable within seconds. No installation, no learning curve, no license cost. For a 5-state traffic light controller or a quick prototype, this works.
The developer describes the behaviour in plain language, the model produces code, the developer adjusts it. Fast, flexible, zero friction.
For small, self-contained, non-critical systems, this is genuinely sufficient. Denying it would be dishonest.
Where the Comparison Breaks Down
The moment the system grows beyond a prototype, the picture changes.
Correctness Is Not Guaranteed
AI-generated state machine code looks correct. It often is correct. But "often" is not the same as "always", and in embedded systems — especially in defence, automotive, and industrial control — "often correct" is not an acceptable specification.
UMTSM generates code from a formal model. The same .umt file, run through the same generator, produces byte-for-byte identical output every time. The behaviour is defined by the DSL semantics, not by the model's confidence on that particular day. There is no hallucination in a deterministic code generator.
Maintenance Is Where AI Quietly Fails
Ask AI to generate a state machine today. Come back in six months when a requirement changes. Now ask it to update the code.
The model does not remember the previous conversation. It does not know which design decisions were intentional and which were incidental. It will regenerate something new. You will need to diff two AI-generated outputs and decide what to keep. This is not software engineering — this is archaeology.
With UMTSM, the design lives in the .umt file. Change the model, regenerate the code. The diff is deterministic and meaningful. What changed in the model is exactly what changed in the output. Version control, code review, and traceability all work as intended.
AI workflow after a requirement change:
Describe the change in natural language
→ AI generates new code
→ Diff against previous AI output
→ Manually reconcile intentional vs accidental differences
→ Re-test everything
→ Hope nothing subtle broke
UMTSM workflow after a requirement change:
Edit the .umt file
→ Run the generator
→ Diff is clean and semantically meaningful
→ Re-test the affected paths
Teams Do Not Scale on AI-Generated Code
One developer using AI can be productive. Five developers independently prompting AI to generate related state machines will produce five different coding styles, five different assumptions about concurrency, five different error handling strategies.
UMTSM enforces a uniform structure across the entire codebase. Every state machine has the same generated skeleton, the same lifecycle API, the same thread model. A developer joining the project on day one can read any state machine in the system and understand its structure immediately, because the structure is always the same.
Certification Does Not Accept "AI Wrote It"
For systems developed under IEC 61508, ISO 26262, DO-178C, or equivalent safety standards, the development tool chain must be qualified. Every transformation from requirement to code must be traceable and auditable.
"We used an AI assistant" is not a qualified tool. It cannot produce a tool qualification report. It cannot demonstrate that a given input always produces a given output. It cannot be submitted as evidence in a safety case.
UMTSM is designed from the beginning with qualification in mind. The generator is deterministic. The DSL semantics are formally defined. The transformation from model to code is auditable. This is not a feature AI can replicate — it is a fundamentally different category of tool.
The Actual Comparison
| Concern | AI Code Generation | UMTSM |
|---|---|---|
| Initial speed | Very fast | Fast after learning curve |
| Correctness guarantee | None | Deterministic by construction |
| Reproducibility | Not guaranteed | Byte-for-byte identical |
| Maintenance after 6 months | Difficult | Edit model, regenerate |
| Team consistency | None enforced | Uniform by design |
| Traceability | None | Model → code, fully traceable |
| Certification suitability | Not applicable | Designed for it |
| Parallel orthogonal regions | Poorly handled | First-class language feature |
| History states | Rarely correct | Deep, shallow, persistent |
| Test scaffolding | Manual | Auto-generated |
| Works offline / air-gapped | Yes | Yes |
| Cost | Subscription | Tool license |
They Are Not Actually Competing
Here is the part that surprised me when I thought it through carefully.
AI and UMTSM do not have to be opponents. The developer still needs to think about the behaviour of the system. They still need to decide what states exist, what events trigger transitions, what the guard conditions are, what actions to execute on entry.
AI can help with that thinking. It can help a developer draft a .umt model, suggest missing transitions, identify unreachable states, or explain why a particular design does not handle a specific scenario correctly.
Without UMTSM:
Developer → AI → C++ code (unstructured, no guarantees)
With UMTSM:
Developer → (AI assists) → .umt model → UMTSM → guaranteed C++ code
The AI becomes an assistant for the modelling task. UMTSM handles the transformation from model to code. The result is faster than doing it alone, and safer than letting AI produce the final code directly.
A Note on Junior Developers
One objection I hear is that UMTSM has a learning curve. This is true. But consider the alternative.
A junior developer using AI to generate a state machine for a concurrent embedded system will produce code that looks like it works. It will pass basic tests. It will fail in the field under a race condition that only occurs every few thousand hours of operation.
A junior developer using UMTSM will write a .umt file describing the behaviour, run the generator, and receive correct concurrent infrastructure automatically. The learning curve is in understanding state machine concepts — which is the actual skill that needs to be developed — not in getting mutex and thread management right by hand.
UMTSM does not remove the need to think. It removes the need to re-implement the same boilerplate correctly every time.
Conclusion
AI code generation is a genuinely useful tool. I use it. Most engineers do. But "useful for prototyping and exploration" is not the same as "suitable for production embedded software development at scale."
The colleague who told me they no longer need tools like UMTSM is probably right — for what they are building today. If their systems stay small and never require certification, AI may be sufficient indefinitely.
But for teams building complex, concurrent, safety-relevant embedded systems that must be maintained over years and certified against international standards, the comparison is not close. Determinism, traceability, team consistency, and qualification are not optional features. They are the job.
UMTSM was built precisely because those constraints are real, and because the existing tools that take them seriously are either prohibitively expensive, poorly designed, or both.
*Fehmi Demiralp is the creator of UMTSM, a state machine DSL and code generation framework for embedded C++ development.*
