Coffee: an in-IDE agent that brews React components from a JSX prompt

The gap Coffee is trying to fill

Most AI UI generators live in a browser. You describe a component, you get a preview, you copy the code out, and then you paste it into your repository and fix the imports. Coffee inverts that. The prompt lives inside your React tree as a JSX element, and the generated output lands in your working directory. The README frames the motivation directly: the authors say they wanted a developer experience "more natively integrated into a frontend developer's existing workflow" than what a hosted playground offers, and that the project is meant to be "more than just a nice demo" but an ergonomic tool that writes production-quality code. That is the claim to hold it to. The intended user is a frontend engineer already inside a React codebase, on Next.js, Remix, or anything else that compiles JSX and TypeScript, who wants a first draft of a component without leaving the editor.

How the watch-and-brew loop actually works

The mechanism is a file watcher plus an LLM call. Coffee runs as a process alongside your dev server. It listens for changes to js, jsx, ts, and tsx files in your source directory. On each save it scans for <Coffee> elements that are new, or whose props or prompt text have changed since the last pass. For every match it assembles a payload: the parent component's code, any existing child component code, your prompt, and any custom configuration, and sends that to the OpenAI chat completions API. The response is written back into the tree as the brewed component. The README describes the agent itself as "relatively simple", and the Python implementation is a detail users are told they never have to touch. Isolation is handled by Docker, which the README says exists so that "any agentic code it runs is fully isolated". That is the architectural shape: a container holding the agent, a bind mount holding your repository, and an API key passed in as an environment variable. The README also warns that your app may throw an error immediately after the first save, because the Coffee element has not yet been replaced by generated code. That is expected, not a bug.

Getting it running: one docker run, or a local build

The README advertises "No dependencies, no setup" beyond Docker and an OpenAI key. The primary command runs the published image against the current directory, mounting it at /mount and forwarding the key from your shell:

docker run --pull=always -it -e OPENAI_API_KEY=${OPENAI_API_KEY} -v $(pwd):/mount coframe/coffee:latest

Start your React app normally in one shell and run that in another, from the same directory. If you would rather build the image yourself, the README points at a /react directory in the repository and a dev script:

./dev.sh build OPENAI_API_KEY=your_api_key ./dev.sh ../path/to/any/frontend/repo/on/machine

Once running, the workflow has three moves. To create a component, write a <Coffee> element with a prompt as its children and pass any props you want forwarded. To iterate, edit the prompt text in place, for example asking to make a button background darker. To finalize, add a pour prop naming an output file, such as pour="MyButton.tsx", and save. The README shows the result: the <Coffee> block is replaced with an import and a call to the new component, with the original props carried across. Editing an existing component uses a different entry point, a coffee prop on the component itself, for instance coffee="make the button color blue". Remove that prop when you are done. A coffee.config.json file is referenced in the TODO list as something to expand, so treat its current surface as thin.

What the project does not yet do

The TODO list is the most honest part of the README, and it should shape your expectations. Running prettier on generated code is unchecked, which means formatting is whatever the model produced. Support for custom prompts and custom agents is unchecked, so you are working with the built-in agent and its built-in prompt construction. A variety of agents described as faster, smarter, or cheaper is also unchecked, and the README states plainly that "the brewing process is currently a little slow". Native integration with Next.js, webpack, Remix, prettier, and ESLint is unchecked. Support for Vue and Svelte is unchecked. The stated prop support is limited to "most simple prop types (data, callbacks, etc)", which leaves the harder cases, such as generic components, render props, and heavily typed context consumers, unaddressed by the documentation. On reliability the README says Coffee is "reliable enough for most standard UI components", a hedged phrase that is doing real work. There is also no release history in the retrieved metadata, so there is no versioning signal to reason about.

The wrong shape for the job: v0 and screenshot-to-code

The README names v0, Vercel's generative React playground, as the closest comparable, and the difference is not just hosting. v0 is a browser surface where you iterate on a preview and then take the code; Coffee never leaves your repository and never renders anything, so it has no visual feedback loop at all. The TODO list confirms this is a known gap: visuals and a data feedback loop from component to agent via GPT-4V are unchecked. The README also links Screenshot to Code and Draw a UI, both of which start from an image rather than a text prompt. Coffee starts from a prompt embedded in JSX and from the surrounding parent code, which is the part that makes editing existing components feel like the same operation as creating new ones. If your input is a design mockup, those image-first tools map to your problem and Coffee does not. If your input is "this component exists, change its behavior", Coffee's coffee prop is the more direct route.

Licence, maintenance, and what upgrading costs you

Coffee is Apache-2.0, which permits commercial use and modification and includes a patent grant. The README links a LICENSE file and shows the Apache 2.0 badge; nothing in the supplied material describes additional terms, contributor licence agreements, or a hosted service component. Note that the agent calls OpenAI using your key, so your usage costs and data handling sit with that provider rather than with the Apache licence. On maintenance: the repository is not archived, and the last push recorded is 2026-06-28. No releases were retrieved, so there is no tagged version to pin to and no changelog to read before upgrading. The docker run command uses --pull=always, which means every invocation fetches the current latest image. That is convenient and also the main upgrade risk: your toolchain can change between two runs on the same day with no version boundary in between. If you need reproducibility, building from a pinned commit via ./dev.sh is the only path the README offers. This is a description of the licence and the release situation, not legal advice; check the LICENSE file and your organization's policy yourself.

Who should pick this up, and what to check first

Adopt Coffee if you are a React developer who wants prompt-driven component generation inside the editor, you already run Docker, and you accept that the agent sees your parent component code. Do not adopt it if your components rely on prop types beyond the simple ones the README lists, if your build pipeline requires formatted output on arrival (prettier is still on the TODO list), or if a browser preview is how you evaluate UI work, since Coffee produces no rendering step. Three things to verify before you commit: run the image against a scratch branch first and confirm which files it touches, since the container gets a bind mount of your working directory; confirm how your team wants the OPENAI_API_KEY passed, because the documented command exports it from your shell into the container; and test the pour prop on one throwaway component to see whether the generated import path matches your project's convention. The coffee.config.json file is the natural place to look for tuning, but the README treats it as an area still to be expanded, so do not expect much there yet.

Editorial conclusion

Coffee is worth trying if you already work in a React or Next.js codebase, you are comfortable sending parent component code and prompts to OpenAI, and you want component generation to happen inside your existing editor rather than in a browser playground. It is not the right tool if you need deterministic output, if you cannot use Docker, or if your components depend on complex prop types beyond the simple ones the README says are supported. Before adopting it, verify three things yourself: that the Docker image runs against your repository without writing outside the files you expect, that your OpenAI key handling matches your organization's policy, and that the generated output survives your own lint and formatting rules, since running prettier on generated code is still an unchecked item on the project's TODO list.

Official sources

1. Coframe/coffee on GitHub
2. Issues
3. License: Apache-2.0
4. Project website
5. README