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 and Sign-in and Models.

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 for the built-in servers, and Coaching Guidelines 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.

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.

Watch the migration (3:27)

Further reading: Migrating from Tabnine CLI for the written procedure, including what is deliberately left behind.