> For the complete documentation index, see [llms.txt](https://docs.tabnine.com/main/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.tabnine.com/main/getting-started/tabnine-plugin-for-opencode/tabnine-in-action.md). # Tabnine in Action Three walkthroughs of the tabnine command at work: a tour of the agent itself, a full cycle of reviewing real code against your organization's coding standards and having the fixes implemented and tested, and a migration from the earlier Tabnine CLI. Each one runs end to end in a working repository, so you can see what a session actually looks like before you start your own. ## A tour of the agent The `tabnine` command starts an agent in your terminal with no flags and no project setup: it takes the repository you are standing in as its working context. This tour opens the `/tabnine` dialog, which enumerates precisely what the plugin contributes to an otherwise standard OpenCode session, then browses the model catalogue and closes on a complete prompt-to-code exchange. Note that the catalogue contains only Tabnine-served models your organization has enabled, and that the provider is locked, so no other provider appears however your local OpenCode is configured.

Launch, the /tabnine dialog, the model picker, and a first prompt

Further reading: [Tabnine Plugin for OpenCode](/main/getting-started/tabnine-plugin-for-opencode.md) and [Sign-in and Models](/main/getting-started/tabnine-plugin-for-opencode/sign-in-and-models.md). ## A complete review, plan, and build cycle The most substantial of the three, and the one to watch if you only watch one. It begins with a small order service whose test suite passes, which is precisely why it is interesting: the defects it contains are invisible to the tests. The session holds two files against the organization's own coaching guidelines, served automatically through the `tabnine-coaching` MCP server, and two genuine errors surface. Neither file guards against an unknown region or discount tier, so both silently produce `NaN` rather than failing. The session then switches to Plan mode, which cannot modify a file whatever it concludes, and asks for a remediation sequence. The resulting plan orders the work by dependency, specifies a guard that throws rather than returning `NaN`, maps five new tests to the cases that need them, and asks where those tests belong before anything is written. Switching back to Build implements that plan. Watch the final minute in particular: the agent runs the suite itself, catches a rounding defect the plan never anticipated, fixes it consistently with how the existing code already rounds, and finishes with eleven tests passing.
Watch the full cycle (3:33)
Plan mode is worth isolating, since it is the mechanism that makes an exploratory request safe to make:

Plan mode reads the repository and returns an ordered plan with a test matrix, then asks where the new tests belong before altering anything

The closing state: every planned item complete, eleven tests passing, and one defect corrected that the plan had not anticipated

Further reading: [MCP Servers](/main/getting-started/tabnine-plugin-for-opencode/mcp-servers.md) for the built-in servers, and [Coaching Guidelines](/main/administering-tabnine/managing-your-team/context-engine/coaching-guidelines-v.md) for how administrators author the standards being applied here. ## Migrating from the earlier CLI If you accumulated MCP servers, skills, subagents, and slash commands in the earlier Tabnine CLI, the migration helper brings them across. It inventories what you have, prints everything it intends to write, and waits for your approval before touching anything. Two moments in this recording deserve attention. The first concerns credentials. One of the fixture servers has a token written directly into its configuration. The helper reports finding it, then writes an environment-variable reference into the new configuration rather than transcribing the value, and names the variable you need to export. The second concerns a default that would otherwise cause confusion. Neither fixture server declares an MCP timeout. The two CLIs disagree sharply on what that means, at ten minutes against five seconds, so the helper writes the longer value out explicitly instead of letting a slow server appear broken after migration. {% hint style="info" %} The MCP status indicator turns red after the restart near the end of this recording. The fixture servers point deliberately at endpoints that do not exist, so this is expected here and is not a sign of a failed migration. {% endhint %}
Watch the migration (3:27)
Further reading: [Migrating from Tabnine CLI](/main/getting-started/tabnine-plugin-for-opencode/migrating-from-tabnine-cli.md) for the written procedure, including what is deliberately left behind. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.tabnine.com/main/getting-started/tabnine-plugin-for-opencode/tabnine-in-action.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.