The core shift: coding agents need data context, not just code generation

An InfoQ technical practice article argues that the usefulness of coding agents in enterprise data work increasingly depends on how much they understand about a company’s actual data environment. The article uses Snowflake’s platform-native agent CoCo as an example to explain why generic coding agents often fall short when they are asked to work inside a governed data stack.

Coding agents are AI tools that can generate, modify, or explain code from natural-language instructions. In data engineering, they can already reduce repetitive work such as pipeline scaffolding, incremental transformation logic, common SQL joins, and migration scripts. These are predictable tasks with familiar patterns, which makes them natural targets for automation.

Why “correct-looking” SQL may still be unusable

The article highlights a problem that is subtler than hallucination. A generic agent may produce SQL that is syntactically valid and stylistically reasonable, but still unsuitable for a real production environment. It may not know which tables are production tables, which schemas are governed, or how role-based access control is organized.

In data work, context is concrete. It includes SQL dialects, schema conventions, platform-specific objects such as Dynamic Tables, Snowflake Tasks, and Snowpark stored procedures, as well as access rules and masking policies. Users can paste schema descriptions, sample queries, and constraints into prompts, but that turns agent usage into ongoing integration work. Every schema update, new table, or new platform feature requires the context layer to be refreshed.

Governance and platform behavior are the harder gaps

The deeper issue is governance. Masking policies, row access policies, and RBAC role hierarchies are often invisible to agents running outside the data platform. As a result, an agent can generate a query that compiles, passes review, and reaches production, only for the team to later discover that it accessed data the current role should not see or bypassed a policy meant to protect sensitive fields.

RBAC means role-based access control: permissions are granted according to roles rather than individual ad hoc decisions. Row access policies restrict which rows a user can see at query time, while masking policies hide or transform sensitive values. These mechanisms are central to production safety, but they are difficult to represent completely through prompts.

The article also points to platform-specific operational knowledge. When querying ACCOUNT_USAGE, users need to know which views to use, how to join them, and where latency may exist. SYSTEM$CLASSIFY has a specific output format and intended use cases. GET_LINEAGE requires parameters in a particular order and its results must be interpreted according to Snowflake’s semantics. This is not merely general SQL knowledge; it is platform knowledge.

The platform-native approach

According to the article, stronger models alone will not remove these gaps, because the problem is not only reasoning quality. It is whether the agent runs inside the right execution context. Snowflake’s CoCo is presented as an agent designed around that idea. It operates using the user’s actual Snowflake role, so masking and row access policies become part of the environment rather than instructions the model must infer.

CoCo can query the catalog, inspect schemas, and run SQL inside the user’s account, reducing the need to paste table structures into prompts. It also includes workflows for data-team tasks such as querying ACCOUNT_USAGE, tracing lineage through GET_LINEAGE, using SYSTEM$CLASSIFY for personally identifiable information classification, analyzing cost, and diagnosing workloads.

The article describes these as structured workflows built for Snowflake APIs and query patterns, not simple prompt templates. The intended benefit is to let data engineers spend more time designing pipelines, writing transformations, and auditing governance policies instead of repeatedly building context for a generic agent.

Industry view: data agents are becoming platform products

The broader takeaway is that enterprise coding agents are moving beyond raw code generation. In the data stack, their value depends on whether they can work with permissions, governance, metadata, lineage, and cost signals. Generic agents can still improve productivity, but teams must invest in context engineering and governance checks. Platform-native agents trade openness for deeper integration within a specific ecosystem.

The likely direction is that data agents will become operational interfaces for data platforms, not just chat-based helpers. Their reliability will depend less on prompt tricks alone and more on whether they act under the right role, with the right permissions, and against the right metadata. For enterprises, the key evaluation question is no longer only whether an agent can write SQL, but whether it understands how the organization’s data system should be used safely.