Data Coding Agents on AWS: Claude Code, Kiro and Q Developer With Real Data Context

A data coding agent on AWS is a coding agent such as Claude Code, Kiro, Amazon Q Developer, Codex or Cursor, pointed at data work: Glue scripts, Redshift SQL, dbt models, Airflow DAGs and Iceberg table changes. Data Workers makes them safe on production data.

These agents write data code well. What they cannot see from the repo is the live estate: which tables a change really feeds, who owns them and what broke last time. Data Workers fills that gap. Connected over MCP, it gives any coding agent governed context across AWS and the tools around it, and routes every production data change through approvals, verification and a receipt.

Key Takeaways

• •Any modern coding agent can write a Glue job or a Redshift migration. The risk is not the code, it is what the code touches downstream.
• •AWS gives coding agents access through the AWS MCP Server and the awslabs MCP servers for Redshift, Glue, EMR, Athena and S3 Tables, mostly read-only by default.
• •Access is not context. An agent with API access still does not know which Quick dashboard reads a column or which Glue export ships it to finance.
• •Data Workers supplies that context and carries the change into production: blast radius before the change, approval by the right owner, verification after it.
• •You keep the coding agent your engineers already like. Data Workers works the same way from Claude Code, Kiro, Q Developer, Codex or Cursor.

The coding agents AWS data teams use

Four coding agents show up most often on AWS data teams, and each is good at its own job.

All of them speak MCP, so all of them can call AWS and Data Workers tools. That is why the agent choice matters less than what you connect to it. Our guides for Kiro, Amazon Q Developer and Claude Code, Cursor and Codex cover the setup for each.

What a coding agent sees on AWS, and what it misses

With the AWS MCP Server, a coding agent can call any AWS API under the engineer's IAM role, and every call lands in CloudTrail. The awslabs servers add data-specific tools: the Redshift server runs read-only queries, the Data Processing server covers Glue, EMR and Athena and blocks writes unless --allow-write is set, and the S3 Tables server does the same for managed Iceberg tables. AWS also released Redshift skills for the Agent Toolkit in August 2026, so an agent can build, query, troubleshoot and migrate Redshift from Claude Code, Kiro or Cursor.

That is real access. Here is what it still leaves out:

• •Downstream impact. The API tells the agent a table's schema. It does not tell it that orders.amount feeds two finance marts, a nightly Glue export and the CFO's Quick dashboard.
• •Ownership. Who approves a change to this table? The repo rarely says, and IAM only says who can, not who should.
• •History. The last three incidents on this pipeline, and what fixed them, live in tickets and Slack threads.
• •Systems AWS doesn't host. Your dbt project, your Airflow DAGs, a Snowflake account or Tableau sit outside AWS's view.
• •A shared approval flow. Each session runs under one engineer's role. There is no single place where production data changes are reviewed, approved and recorded.

So the agent writes a clean change, the tests pass, the pull request merges, and the first nightly run breaks a report nobody knew was downstream.

How Data Workers turns a coding agent into a data coding agent

Data Workers runs as a set of MCP servers your coding agent calls. Nothing about the agent changes.

• •Context before the change. Data Context Wizard keeps one governed graph across the Glue Data Catalog, Lake Formation, Redshift and DMS, your dbt project and orchestrator, and your BI. When the agent plans a change, it asks Data Workers for the blast radius and gets every reader and owner back.
• •Specialist agents behind it. The Data Agents Swarm includes the Schema Evolution agent, the Data Change Review agent and the Pipeline Building agent, which do the data side of the work the coding agent starts.
• •Two locks on every write. The coding agent's own permission rules gate the tool call on the engineer's machine. Data Workers' per-domain guardrail gates the change to the warehouse. No agent approves its own work.
• •Verification after it. Data Workers checks row counts, values and downstream tests after the change lands and records a receipt.

One change, end to end

Here is a typical flow. It is an illustration, not a customer case.

1. 1.A ticket asks to split orders.amount into net_amount and tax_amount for VAT reporting.
2. 2.An engineer asks Claude Code, or starts a Kiro spec, to make the change in models/orders.sql.
3. 3.The agent calls Data Workers for impact. Data Workers reports two finance marts on Redshift, the finance_export Glue job and the Revenue dataset behind a Quick dashboard.
4. 4.The agent's plan now fixes all four readers before the column changes, and the pull request carries the blast radius and the rollback plan.
5. 5.The platform owner approves the Redshift migration. The approved change is applied, the affected models rerun, and Data Workers confirms revenue totals match the baseline and the next export succeeds.

Without the context step, the same request produces a passing pull request and a broken finance export. With it, one engineer and one owner each approve once.

Getting started

Add the Data Workers MCP servers next to the AWS MCP Server in your team's client configuration (.mcp.json for Claude Code, .kiro/settings/mcp.json for Kiro, .amazonq/mcp.json for Q Developer), connect Data Workers read-only to your dbt project and orchestrator, and start in observe mode. Every change your engineers make then comes with an impact report. When that has earned trust, move a domain to propose and let Data Workers carry approved changes into production. The Redshift MCP server setup guide and Claude Code and Redshift integration cover the warehouse side, and agentic data engineering on AWS covers the full picture.

Frequently Asked Questions

Which coding agent is best for data engineering on AWS?

The one your engineers already use well. Claude Code, Kiro, Amazon Q Developer, Codex and Cursor all support MCP, so they all reach AWS and Data Workers the same way. The context and approvals behind the agent matter more than the agent.

Is the AWS MCP Server enough for a data coding agent?

It gives the agent access to AWS APIs under IAM, which is the right foundation. It does not give it lineage across dbt and BI, ownership, incident history or a shared approval flow for production data changes. Data Workers adds those.

Can a coding agent change production data safely?

Yes, when the change goes through a second lock outside the agent's session. Data Workers scopes every write to its blast radius, routes it to the domain owner, keeps a rollback point and verifies the result downstream.

Do we have to switch from Q Developer or Kiro?

No. Data Workers works from Kiro, Amazon Q Developer, Claude Code, Codex and Cursor. Your engineers keep their tools and configuration.

Sources

• •AWS MCP Server general availability (May 6, 2026)
• •awslabs MCP servers
• •Redshift with Agent Toolkit for AWS (Aug 27, 2026)