You're on Tabnine: private AI coding for data engineering, with Data Workers running every data change inside your environment

You chose Tabnine because your code can't leave your control. It runs as a private installation on Kubernetes in your VPC, on your own servers or fully air-gapped. Your admins picked the models in the Admin Console, some of them self-managed endpoints on Amazon Bedrock or Azure AI Foundry. The Context Engine has indexed your Git repositories and Perforce depots, and your engineers work with Tabnine Agent and Tabnine Chat in IntelliJ, PyCharm, VS Code or Visual Studio, or in the terminal with Tabnine CLI. Security signed off because of Tabnine's no-train-no-retain policy. Tabnine is now part of Tricentis, which announced the acquisition on July 30, 2026. Then the data team starts using Tabnine Agent on dbt models and pipeline code, and a new question arrives: "The agent wrote the change. What does it do to the warehouse, does it touch PII, and does anything leave our environment?"

That question is about your data estate, and it needs the same privacy posture you demanded from Tabnine. Tabnine is the private coding agent. Data Workers is the agentic data platform underneath: it runs in your environment too, knows what every change touches across your warehouses, pipelines and dashboards, and carries the change into production behind approvals, with a receipt. Tabnine stays exactly as you configured it, and Data Workers connects over MCP.

Key takeaways

• •The role swap. Your engineers already work in Tabnine. Connected to Data Workers over MCP, Tabnine Agent answers from governed data context, and every data change goes through Data Workers' approvals and receipts.
• •The same privacy posture, on the data side. Data Workers runs in your VPC, your cloud or on-premises. It stores metadata and scrubbed facts about your data, not copies of your tables, and you bring your own model, including a local one.
• •Setup is one file. Add Data Workers to .tabnine/mcp_servers.json in the project. Each agent is a standard MCP stdio server started by start-agent.sh, and your admins can allow-list exactly that command in MCP Governance.
• •Two locks on every write. Tabnine's per-server approval and MCP Governance decide whether Tabnine may call Data Workers. Data Workers' per-domain guardrail, from L0 manual to L4 autonomous, decides whether a change may run.
• •The whole lifecycle, one audit trail. Tabnine goes deepest on writing pipeline code. Data Workers covers all ten lifecycle stages with one context, one approval flow and one audit trail.

Tabnine is the private coding agent. Data Workers is the agentic data platform underneath.

Here is a morning regulated data teams will recognize. It's an illustration, not a customer case.

Tabnine wrote the change and the tests and checked in with the engineer before applying. Data Workers saw that a harmless-looking column was PII, that an export would carry it outside and that a dashboard read it too, then ran the approved change with rollback and left a receipt your privacy team can read.

Why doesn't Tabnine just do this itself?

Because Tabnine built an excellent private coding agent, and that focus is the reason you bought it.

Tabnine's design centers on code. The Context Engine builds structured context from your repositories and depots: summaries, services, dependencies and code elements. Tabnine Agent reads and edits project files and runs commands, checking in under the tool permissions you set. Admins govern which models, tools and MCP servers engineers may use. That is a clear, sensible focus for a coding company.

A data change lives somewhere else. The column is in Snowflake, the model in dbt, the reader in an Airflow DAG, the chart in Tableau, and the classification in your governance tool. Changing those safely is a different product category: blast-radius checks across systems, approvals that differ by domain, rollback, verification against the source, PII handling, a receipt an auditor can read, and liability for changes inside systems Tabnine doesn't run. Tabnine is right to leave that to a dedicated platform and give it a clean MCP door. Data Workers is built for exactly that job.

Every tool owns a slice. Data Workers covers the whole lifecycle

A data team's work runs across ten stages, from context and quality to access, cost and models. Each point tool adds another console, another contract and another handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.

Tabnine leads on Pipelines & Ingestion, its home stage, because writing, refactoring and testing pipeline code is the core product, and its privacy design earns real credit on Security & Privacy for the code path. Data Workers covers all ten.

How Tabnine and Data Workers work together

Tabnine stays where engineers ask and review diffs. Spellbook Data Catalog (in preview) is where your data team reviews proposals, rolls changes back and reads the audit trail. Underneath, Data Context Wizard builds one governed graph across your warehouses, dbt, orchestration and BI. The Data-Agents Swarm does the work, and the Autonomous Data-Conductor runs each fix end to end: detect, diagnose, fix, review, verify, remember.

Where it runs. Data Workers runs in your infrastructure: your VPC, your cloud or on-premises. Every agent is a local MCP server over stdio, launched next to Tabnine, with no inbound port to open. Data Workers stores metadata and scrubbed facts about your data (schemas, owners, lineage, classifications, quality results), not copies of your tables, and PII middleware runs before results reach the coding agent. Agents call the model provider you configure, with your key: Anthropic, OpenAI, Azure OpenAI, Bedrock, Vertex, or a local model through Ollama. The security and deployment guide and Data Workers in your VPC or air-gapped cover the details.

Setup in the IDE. Clone the open-source Data Workers repository and run npm install; start-agent.sh <agent> starts any agent, per the client setup guide. In the Tabnine plugin, open Settings, then Tools and MCPs, then MCP servers, and choose Add MCP server. Tabnine opens .tabnine/mcp_servers.json in the project (or use ~/.tabnine/mcp_servers.json for every project); keep a project folder open so the MCP list loads. Tabnine resolves ${VAR} references in env values at connection time, so keys stay in the OS environment, out of the committed file.

Example .tabnine/mcp_servers.json, with the repository cloned to /opt/dataworkers-claw-community:

{
  "mcpServers": {
    "dw-context-catalog": {
      "command": "/opt/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-context-catalog"]
    },
    "dw-schema": {
      "command": "/opt/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-schema"],
      "env": {
        "OLLAMA_HOST": "${OLLAMA_HOST}"
      }
    },
    "dw-governance": {
      "command": "/opt/dataworkers-claw-community/start-agent.sh",
      "args": ["dw-governance"]
    }
  }
}

Once the servers connect, set each one to Auto-approve, Ask first or Disable in the same panel; we recommend Ask first for dw-schema. Read tools such as search_across_platforms, trace_cross_platform_lineage, explain_table and assess_impact do the work in the incident above. Tools that change the warehouse, such as apply_migration and rollback_migration, run through Data Workers after a person approves in Spellbook. Add a Markdown file under .tabnine/guidelines/ with a rule such as "call explain_table and assess_impact before changing any dbt model", so the agent checks first.

In the terminal. Tabnine CLI, powered by OpenCode and available to all customers since v6.6.0, reads your existing OpenCode configuration and applies your organization's Tabnine governance on top. Add the Data Workers agents to opencode.json as the client setup guide shows (an mcp key, with start-agent.sh and the agent name in the command array), and the same agents appear in the CLI.

For your Tabnine admin. In the Admin Console, MCP Governance offers Allow all, Allow only remote, Allow-list only and Block all. Choose Allow-list only and add each Data Workers agent as a local server: a command regex that matches start-agent.sh and the agent name in args, with Exact match on if you want the arguments pinned. Engineers can then run Data Workers and nothing you haven't approved.

One request, L0 to L4. Take the ticket above: "Add customer email to churn_features." Here is how the same request runs at each autonomy level, set per domain.

• •L0 manual. The engineer checks classification and downstream readers by hand; Tabnine writes the code.
• •L1 observe. Tabnine Agent answers from Data Workers: the column is PII, the mart feeds an export and a workbook, here are the owners. Nothing changes.
• •L2 propose. Data Workers drafts the safe change, a hashed key with tests and the impact report. The owner and privacy lead approve in Spellbook.
• •L3 act reversibly. For this domain, Data Workers drafts changes it can undo, verifies the export and the workbook, and records the receipt.
• •L4 autonomous. For a trusted, scoped class, such as additive non-PII columns in one domain, the owner's pipeline applies the drafted migration and Data Workers verifies on its own and records the receipt. PII changes can stay at propose as long as you like.

The two locks hold at every level, and no agent approves its own work. For the wider pattern across coding agents, read Data Workers with Claude Code, Cursor and Codex.

What changes for your team

Your engineers keep their habits: they still ask Tabnine Agent, review each diff and open merge requests in GitLab or GitHub. What changes is what a data change carries. With Data Workers behind Tabnine, an agent-written dbt change arrives with its blast radius, its privacy check, the downstream fixes and a plan to apply and roll back, so reviewers stop chasing classification and lineage by hand. Your privacy team gets receipts instead of spreadsheets, and your data team spends its time modeling the business and deciding which domains move up the ladder.

Keep Tabnine, or consolidate?

Keep Tabnine if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.

For Tabnine, keeping it is the natural answer: it's your engineers' private coding agent, approved by security and installed where your code lives. What teams consolidate is the tool sprawl around it: the separate catalog, privacy review, quality tool, incident runbooks and access queue, each with its own server, contract and review. Data Workers covers that lifecycle with one set of MCP agents on one context graph. If some engineers use other assistants, the same agents sit behind each of them; see the sibling guides for GitHub Copilot, JetBrains AI Assistant and Junie and Cursor, and the section overview, Your company just rolled out AI assistants. Now what?

The case for your CFO

The outcome. You already pay for Tabnine so engineers can use AI without code leaving your control. More AI-written code means more changes to the tables and exports the business runs on. With Data Workers underneath, every data change arrives with its impact and PII checked, its approval recorded and its rollback ready, so numbers stay right and regulated data stays put while engineering moves faster.

The risk story. Data Workers starts at observe. At propose, every change is a draft a person approves. At act reversibly, it runs only changes it can undo, and only in domains you've moved up. Autonomous is a per-domain choice, never a default. Every receipt records who or what acted, why, what it touched and how to undo it. Data Workers runs in your environment with the model you choose. Zero migration: your data stays where it is. The safety guide goes deeper.

Why now. Tabnine ships the controls today: per-server approvals, MCP Governance allow-lists and admin-chosen models. The choice is between engineers wiring their own database servers into the agent one by one, and one governed set of Data Workers agents across the org.

The first win. An impact and PII report on every data change Tabnine Agent writes, at observe, then reversible changes in one domain at act reversibly.

What stays the same. Tabnine, its deployment, its models and policies, your Git host, your warehouse permissions, dbt, Airflow and Tableau.

The path. Start with a pilot. See pricing; the pilot is credited in full against the first year. The ROI guide sizes it, and build it ourselves with Claude Code and MCP servers? covers build-vs-buy.

The sentence to repeat upstairs: "We chose Tabnine to keep our code private; Data Workers keeps every data change it writes checked, approved and recorded inside our own environment."

Getting started

Start with a pilot. Add Data Workers to one dbt project's .tabnine/mcp_servers.json, allow-list it in MCP Governance, set the servers to Ask first and start every domain at observe, so your team first sees an impact and PII report on each change Tabnine Agent writes. Then move one domain, often finance or customer data, to propose. See pricing; the pilot is credited in full against the first year.

FAQ

Can Data Workers run in the same private environment as our Tabnine installation? Yes. Data Workers runs in your VPC, your cloud or on-premises, its agents run as local MCP servers next to Tabnine, and they call the model provider you configure, including a local model through Ollama.

Does our data leave our environment? Data Workers stores metadata and scrubbed facts about your data, not copies of your tables, and applies PII middleware before results reach Tabnine. The security and deployment guide covers what is stored and where.

Does Tabnine Agent ask before it calls Data Workers? That's your choice per server: Auto-approve, Ask first or Disable, in the Tabnine plugin's MCP settings. Changes to your warehouse still run through Data Workers' approvals, whatever the Tabnine setting.

We use self-managed models in Tabnine. Can Data Workers use our endpoint too? Data Workers agents call whichever provider you configure with your key, including Bedrock, Azure OpenAI, Vertex or a local model. There's no markup on model spend.

Does it work in the Tabnine CLI? Yes. Tabnine CLI is powered by OpenCode and reads your OpenCode configuration, so Data Workers agents added to opencode.json appear there, with your Tabnine governance on top.

Sources

Tabnine capabilities, names and settings are current as of October 2, 2026, from Tabnine's own documentation, all checked October 2, 2026: Deployment Options, Privacy, AI Models, Self-Managed Models, Tabnine Agent, In-IDE Agent Settings, Agent Guidelines, Understanding MCP Servers, MCP Server Config, MCP Governance, Context Engine and its Data Sources page, Tabnine Plugin for OpenCode and the Release Notes (v6.6.0, September 15, 2026). The acquisition is from Tricentis' announcement, Tricentis Acquires Tabnine to Further Scale Agentic Quality Engineering for the Enterprise (July 30, 2026), checked October 2, 2026. Data Workers setup, model providers and tool names are from the client setup guide, the configuration guide and the open-source dataworkers-claw-community repository (start-agent.sh and each agent's registered tools), and deployment options from pricing, all checked October 2, 2026. Product names and settings change quickly; if we've got something wrong, tell us and we'll fix it.