Articles
How to vibe code a reinforcement learning environment
23 October 2026
Reinforcement learning in recent years has become immensely important to not only engineers in AI, but the broader economy, as it continues to drive further performance of LLM models as the seemingly last scaling step to AGI.
The bottleneck for a lot of that work is not the training loop. It is inventing the environment: the world the model acts in, the moves it can take, what it is allowed to see, and what counts as success. Vibe coding that environment means you describe those pieces in ordinary language, a coding agent drafts them, and you judge the draft by playing it. Same idea as vibe coding an app. Different finish line. You are not shipping a UI feature. You are checking whether the game you described is the game that actually runs.
The formula for an RL environment
Handwritten Python, a game engine, or a prompt to a coding agent: the environment is still this contract:
- Observation: what the agent may see each turn. Mines, hole cards, diagnoses stay off this until the episode ends.
- Action: legal moves right now. Reject anything else.
- Reward: a number for how the last move went. Wrong payout, wrong game.
- Reset and done: how a round starts and when it finishes. Same start should be repeatable.
That loop (action in, observation and reward and done out) is the environment. Vibe coding works when you can name those four pieces in a prompt, get a draft you can play, and keep editing until the picture, controls, and score match what you meant.
What to put in the prompt
Ordinary language is enough. The agent only encodes what you say. “Make blackjack” or “make minesweeper” skips the awkward parts: hole cards, speed readouts, start-state pickers, what must stay hidden. Spell those out.
- The world: objects a person would recognise. Hole card, puck speed, suture bite, ECG paper, board cells.
- Legal moves: clicks, keys, or tool calls that count as one action.
- What stays hidden: mines, diagnoses, mate lines, true curves. Off the observation until the round ends.
- Reward: what earns a point, and what must never pay.
- Start and end: how a round begins, and when it is finished.
A one-line game name produces a sketch. A short description of a finished activity (what you see, what you can do, when you win) produces something you can judge. Broader tool comparison: How can I make a reinforcement learning environment?.
A practical workflow
Describe the environment the way you would explain the game to a friend who has never played it. Let a coding agent draft the loop and whatever surface a person needs to play. Then play it yourself. Check the picture, the controls, the hidden answer, and the score.
Follow up when something is off. First drafts miss readouts, leak answers early, or reward the wrong event. That is normal. Keep going until the activity matches what you meant. Only then decide whether you need a Gymnasium class, a Hub package, or a training run. Early on, the scarce thing is a game definition you trust.
How this compares
Vibe coding is one path. Nearby options trade setup cost for how much you own yourself.
| Approach | How you make the environment | Use it when | Skip it when |
|---|---|---|---|
| Empty-repo coding agent | Ask Claude, Codex, or Cursor to emit a Gymnasium Env from a prompt in a blank project. | You already want that API and you will own the viewer, tests, and reward review. | You need a playable page and MCP tools on day one. First drafts often leak the answer into the observation. |
| Prime Intellect Verifiers + Hub | Package a dataset, harness, and rubric as a load_environment module and publish it for eval and prime-rl. | You are shipping a train/eval package into that stack. | You want a browser picture first, before the training package exists. |
| Hand-written Gymnasium | Subclass Env, implement reset and step, register the id, plug into Stable-Baselines3 or RLlib. | The environment is clear and the next consumer is training code. | You are still inventing what the agent should see and how a person judges a rollout. |
What still goes wrong
A vibe-coded first draft is a playable sketch, not a finished benchmark. Speed readouts, start-state pickers, domain objects, honest controls: those get missed. Play it. Reject a picture that shows the answer early. Reject a reward that pays for the wrong event. The editing loop is the work.
Making the environment and training a policy are separate jobs. Play the game (or let another program act in it) long before learning code exists. If you later need Gymnasium or a shareable training package, keep the definition you proved: observation, legal moves, done, reward.
Where Viscerl fits
If you want that workflow in a browser, Viscerl is built for it. Describe the activity on the home page, pick an agent, and the write lands in a fixed starter. workspace/core.py owns the rules. workspace/view.js draws the observation and sends only legal moves. MCP exposes observe, reset, and act. A host check rejects a view that does not parse, geometry that paints NaN, and an observation that leaks the answer before the episode ends.
Viscerl does not train a policy. The starter refuses MuJoCo, Godot, pygame, Gym, and torch on purpose. Use it when you can describe a custom activity and need it playable and callable before packaging for training. Skip it when you need Gymnasium today, calibrated physics, or a published benchmark suite.
Questions
What does it mean to vibe code an RL environment?
You describe the interactive world in ordinary language. A coding agent drafts the environment. You review by playing: check observation, legal moves, reward, and when the episode ends, instead of starting from a blank Gymnasium class.
Is vibe coding the same as writing a Gymnasium environment?
No. Gymnasium is a Python training API you implement by hand or generate into an empty repo. Vibe coding gets you a playable environment definition first. You can later port a proven observation, action, reward, and done contract into Gymnasium if you need that API.
What should I put in the prompt?
Name the objects a person would see, the moves they can take, what stays hidden until the round ends, and what counts as success. Short prompts that only name the game idea often omit hole cards, speed readouts, and start states. Those gaps show up when you play.
How do I vibe code a reinforcement learning environment on Viscerl?
Open the home page, describe the world, the legal moves, what the picture should show, and what earns reward. Pick an agent and send the prompt. Play the result. Follow up if the reward, controls, or hidden answer are wrong. An agent client can call the same environment over MCP with observe, reset, and act.
What does Viscerl check after the agent writes?
A host check rejects a view.js that does not parse, SVG geometry that is NaN, and status text that can resize the picture. The picture may only send legal moves. The answer must stay off the observation until the episode is done. That is a parse and contract gate, not a full proof that the environment is fair.