2026-06-03
Finite State Machines Changed How I Read Code
Finite State Machines (FSMs) are one of the most useful concepts I have learned for understanding software architecture.
At first glance, FSMs seem like an academic concept:
- A system has a set of states.
- Events trigger transitions between states.
- The system behaves differently depending on its current state.
Simple enough.
But over time, I started to see that many software systems can be understood through the same lens.
State and State Change
When reading a codebase, I often ask two questions:
- Where does the state live?
- How does the state change?
That is it.
In programming terms:
- State: variables, database records, application stores, files
- State transitions: functions, methods, actions, API calls, user interactions
Almost every piece of code exists to either store state or change state.
A user clicks a button.
State changes.
An API request arrives.
State changes.
A robot arm reaches a position.
State changes.
A database record is updated.
State changes.
The details may differ, but the pattern remains surprisingly consistent.
Understanding Architecture Through State
When I encounter an unfamiliar codebase, I no longer start by reading every file.
Instead, I look for the state.
Where is the source of truth?
Is it stored in React state?
Redux?
A database?
A PLC?
A robot controller?
Once I know where the state lives, I trace how it changes.
Who can modify it?
Which actions trigger those changes?
What side effects happen afterward?
By following the flow of state, the architecture begins to reveal itself.
The AI Coding Era
I think this becomes even more important in the era of AI-assisted programming.
Writing code is becoming cheaper.
Reading code is becoming more valuable.
An AI can generate hundreds of lines of code in seconds.
But someone still needs to understand:
- Where should this code go?
- Which state does it affect?
- What action should trigger it?
- What existing architecture does it belong to?
The bottleneck is no longer typing code.
The bottleneck is understanding systems.
A Practical Rule
Whenever I open a new codebase, I start with a simple exercise:
Find the state.
Find what changes the state.
Everything else is usually easier to understand afterward.
It is not a complete model of software architecture.
But it is often the fastest path to understanding one.