Tabnine's agent returns changes ready for review when the rules are in place before anyone starts. Publish guidelines and connect the repositories the agent needs, run sessions under the tool and MCP policy your admins set, and check provenance and tests before anything merges.
When you need this
- Engineers have moved from completions to the agent and the CLI, and results vary by person.
- The agent proposes changes that ignore your conventions or reach into the wrong part of the codebase.
- You want one standard for what the agent may run and what a human checks before merge.
Steps
Before work: guidelines
Where do your coding standards live for the agent?
What good looks likePublish organization-wide agent guidelines, which also apply in the CLI. Cover naming, error handling, test style, and the modules the agent must not touch. If you have closed-beta access, put review standards in Coaching Guidelines.
Before work: repository context
Can the agent see the code it needs beyond the open workspace?
What good looks likeConnect and index the repositories the agent needs in the Context Engine. Turn on agentic pre-processing for priority repositories and Context Engine tools for users. Basic context is ready within a few hours of connection.
During work: tools and MCP
What may the agent run without asking?
What good looks likeGive each native tool a rule of allow, ask before, or block, and limit MCP servers to an allow list. The OpenCode-based CLI enforces those policies and blocks local overrides.
During work: model and session
Which model handles which task?
What good looks likeSet default chat and agent models and approve the alternatives developers can pick. Limit each session to one change. Read every diff, because users of some plugin versions have reported edits that failed to apply and an edit written to the wrong directory.
Before merge: provenance
Did the change copy restricted public code?
What good looks likeTurn on Provenance and Attribution so output that matches public GitHub code shows its source and license. Turn on censorship and check_provenance so the agent rewrites matched non-permissive code before applying it.
Before merge: tests and review
Who confirms the change works?
What good looks likeGenerate tests with /test or write them yourself, and run them locally or in CI before a human reviews the change. In 2025, users reported chat edits that changed lines they had not asked about and ignored their indentation rules.
Questions for your team
- Which repositories are connected to the Context Engine, and who decides which get agentic pre-processing?
- Which tools may the agent run without asking, and who maintains the MCP allow list?
- Is censorship on for every team, or only for code that ships to customers?
- Who reviews agent changes, and what must pass before merge?
Red flags
- Agent edits applied without a diff review because the session looked routine.
- Provenance never switched on because it requires a request to Tabnine.
- Teams still building on the original Tabnine CLI, which loses all support after December 31, 2026.
- Guidelines written once and never compared with what reviewers keep correcting.
Products in this piece
Sources
- Official documentation
- 10
- Public source
- 5
- Tabnine docs: Tabnine Agent
- Tabnine docs: Agent guidelines
- Tabnine docs: Coaching Guidelines
- Tabnine docs: Context Engine
- Tabnine docs: Native Tools
- Tabnine docs: MCP Governance
- Tabnine docs: Tabnine Plugin for OpenCode
- Tabnine docs: Tabnine CLI
- Tabnine docs: Provenance and Attribution
- Tabnine docs: Models (admin settings)
- mitfik on GitHub: chat edits change unrelated lines and can only be accepted whole (Oct 26, 2025)
- rmplbv on GitHub: chat responses ignore indentation and .editorconfig (Apr 2, 2025)
- ergo on GitHub: an applied chat change written to the wrong directory (Jan 15, 2025)
- the-isz on GitHub: Tabnine Agent stuck loading on Tabnine Enterprise (Apr 22, 2026)
- Ollymid on GitHub: shared team commands on Tabnine Enterprise (Jun 11, 2026)