React or the Current Stack?
Should this public AI chat service keep its Python-rendered HTML and vanilla JavaScript frontend, or rewrite it in React?
Council verdict
Do not rewrite in React now. React would improve frontend organization, but it would not solve the service’s urgent production concerns: public identity, abuse and cost controls, durable jobs, subprocess isolation, persistence, or operational reliability.
Keep the current frontend, define a clean JSON/SSE API, and modernize the backend. Add React later when the product has at least two genuinely state-heavy needs such as streaming advisor panels, branching chats, dashboards, or several interconnected screens.
Advisor alignment
Keep current UI
Backend first
React later
User outcomes first
Modernize backend
Where the council agrees
The current UI is simple enough. React does not fix throughput, reliability, authentication, persistence, or AI execution cost. A stable API boundary preserves the option to add it later.
Where the council clashes
The only real disagreement is timing: proactively prepare for a rich interaction roadmap, or wait for observed complexity. The council favors waiting while keeping the architecture React-ready.
Blind spots caught in peer review
A browser-held shared bearer token is not genuine public-user authentication. Public launch also requires abuse controls, quotas, moderation, privacy rules, cost ceilings, observability, and a stronger execution boundary around the AI CLI.
The first move
Choose and implement the public-access model: real user sessions with per-user quotas, or controlled anonymous access with strict server-side abuse and spending limits.