Shipping a React client I have not read¶
The honest version of this post is not "a Python developer learns React by shipping a product." I am a Python and C++ developer with no prior web-UI experience, and this project's React client was built by AI agents. I have not read the client code closely enough to claim that I learned React from it. I cannot turn that into a field diary without making up the diary.
That matters because first-person technical writing has a special failure mode: it can sound more credible when it is less true. A neat month-by-month story about hooks, effects, dev tools, and the moment React finally clicked would be easy to publish. It would also be a false source of authority. The real lesson here is different: I shipped a React client by designing the work around what I could honestly know, and by refusing to pretend that reading an AI-written frontend had happened when it had not.
What I can say¶
The product is a multi-device board game platform. The backend is Python and FastAPI. The frontend is React via Vite. Phones and tablets are private player controllers; the TV is a shared table display; the server owns the state and filters each role's view before the client renders it.
Those are not memories from learning React. They are project contracts. They live in the repo rules, the overview docs, and the tests. When a ticket changes the frontend, the work is supposed to preserve those contracts: phones are not small mirrors of the TV, table screens are room-distance displays, role-filtered views must not leak private data, and layout changes need device coverage. That is the part I can reason about as the product owner and backend developer.
The React implementation is the other side of the boundary. I can read small pieces when a ticket forces the issue. I can understand enough context to write or review the product requirement. I cannot honestly claim that I know the client architecture from the inside, or that I personally learned the framework by building it.
The workflow replaces fluency with contracts¶
The reason this project can still move is that it does not rely on my private React fluency as the main safety mechanism. It relies on tickets, rules, gates, review, and run records.
A ticket says what behavior should change, what files are in scope, what is out of scope, and how the result will be verified. The agent gets that bounded context instead of a vague request to "make the UI better." The project rules then carry the durable constraints I would otherwise have to remember: use the project wrapper to run the app, do not hand-start a Vite server, keep phone players as controllers, use layout-fit guards for changed stage or shell screens, and explain frontend framework reasoning because the owner does not come from that stack.
The gates are the mechanical half. They can check doc tags, mirrored DevBlog titles, layout coverage, forbidden state shapes, direct randomness, fixture drift, and many other rules that would be easy for an agent to forget. The run record is the audit half: after a ticket runs, it leaves a sibling file saying what changed, what failed first, what judgment calls were made, and what prevention was considered.
None of that means the code is automatically good. It means the project is not depending on a false claim that I personally understand every React decision. The process makes the output reviewable from the outside.
What remains my job¶
The workflow removes typing I cannot do well. It does not remove responsibility.
My job is to know the product shape: what the TV should show, what a phone player should be able to do, what private information must stay private, what a family playing in a room should experience, and what tradeoffs are acceptable. That work cannot be outsourced to a lint rule. A gate can tell me whether a screen fits a viewport. It cannot tell me whether the screen is pleasant to use. A test can prove that a role does not receive another player's private data. It cannot decide whether a turn feels clear.
This is the part of the loop that still needs a human. I can drive the product without pretending to be the frontend engineer because I can run the app, form a judgment about the result, and turn that judgment into the next ticket. The AI can build from a precise ticket. It cannot decide, on its own, what kind of game I am trying to make.
The advice I can actually give¶
If you are a backend developer looking at an AI-built frontend, the honest advice is not "you will learn React by osmosis." Maybe you will, if you read the code and study the framework on purpose. I did not. Do not launder an AI's output into your own learning story unless the learning actually happened.
What you can do is design the collaboration so your real expertise still matters. Write product behavior in concrete terms. Keep the architecture rules visible. Make the agent read the files that define the surface before it edits the surface. Put the conventions that matter behind gates. Run the real app on the devices the product is built for. Treat "I do not know" as a useful boundary instead of a weakness to hide.
That boundary is what makes the work possible. I do not need to claim I learned React to say this project shipped a React client. I need to say something more precise: an AI-built frontend can be driven by someone who cannot honestly write or source-review that frontend, if the surrounding process is explicit enough about what the product must do, what the agent may change, and how reality gets checked afterward.
That is less romantic than a learning diary. It is also true.
Or: subscribe to the newsletter for more posts on building this stuff.