When I started the AI traffic-light project, I thought the hard part would be the model. It turned out the hard part was deciding what counted as state — and what could safely be ignored.
State is a design decision
In Q-learning, the agent only learns from the state you give it. Too little information and the policy is blind. Too much and the space explodes. That trade-off feels familiar in frontend work: local UI state, server state, and derived state all compete for attention.
Reward shapes behavior
A poorly designed reward made the agent optimize the wrong thing — clearing one lane while starving another. The same thing happens in product UI when success metrics reward clicks instead of clarity. Good systems make the desired outcome easy to measure and hard to game.
What I carry into product work
I now ask three questions earlier: What is the true state of this system? What should update immediately vs. eventually? And which signals actually matter to the user? Those questions came from a simulation, but they apply just as well to forms, dashboards, and async workflows.