brew-ai Code Copilot
For Python, SQL, R, and JavaScript code functionals, brew-ai can act as a code copilot: it reads what’s actually in the editor, folds in language diagnostics and the functional’s typed inputs/outputs, and proposes changes as a reviewable diff instead of just describing them in prose.
What the Code Copilot Sees
Section titled “What the Code Copilot Sees”Opening the copilot from a code editor hands brew-ai a live snapshot of that editing session, not a saved copy:
- Live code — the current contents of the editor buffer, including anything you’ve typed but haven’t saved yet.
- Diagnostics — whatever markers are currently registered on the editor. For Python this is real-time output from the Pyright language server (see below); other languages carry whatever their editor already surfaces.
- Typed inputs/outputs — the functional’s own input and output definitions (names and CV types), so proposed code lines up with what the functional is actually supposed to consume and produce.
- Upstream table columns — when a table-typed input is wired to an upstream node, the copilot also sees that table’s column names, so it can reference columns you haven’t typed into the script yet.
Proposing Edits
Section titled “Proposing Edits”Open a code functional’s editor and click Ask brew-ai in the editor’s footer. The chat panel switches into code mode — its header badge reads “<Language> agent” and a chip below shows “Editing: <name>” for the rest of the session.
In code mode, the intent chips (and their matching slash commands) are scoped to the code in front of you rather than the whole model: Explain this code (/explain), Find & fix bugs (/bugs), Refactor (/refactor), and Add docstrings (/doc) for Python/R/JS editors; SQL editors get Explain this query (/explain), Fix errors (/fix), Optimize this query (/optimize), and Write a query from my tables (/write).
When the assistant proposes a change, it opens a “✏️ Proposed code change” card in the thread with a short summary and the change rendered as colored +/- lines against your current code.
Apply swaps the live editor’s contents with the proposed code immediately; Reject closes the card and leaves your code untouched. Applying only updates the open editor session — it doesn’t save the functional, so you still need to click the editor’s own Save button to keep the change. If the assistant answers in plain chat with a code block instead of a formal proposal, an Apply to editor button appears under that message and routes the block through the same diff card.
Flavor-Aware Diagnostics
Section titled “Flavor-Aware Diagnostics”Python editors carry a live language-server connection: Monaco talks to Pyright over a WebSocket proxy, and a status badge above the editor shows whether that connection is connecting, connected, disconnected, or erroring.
That connection is flavor-aware — it’s keyed off the functional’s own Runtime input selection (Generic Python, Data Analytics, Machine Learning, and so on), so the LSP runs against the same package set as the flavor the functional will actually execute in, not a generic Python environment. Diagnostics reflect what’s really importable at runtime rather than a lowest-common-denominator install.