AWS Blocks Explained: The Open-Source TypeScript Framework for AI Agents to Build Backends

On 16 June 2026, AWS pushed a new open-source framework called Blocks into public preview, and the framing is what makes it worth paying attention to. AWS is not pitching this as another Amplify, another SST, or another CDK abstraction layer. They are pitching it as a framework designed from the ground up for AI coding agents to write correct backend code.

That premise is worth pulling apart, because every implementation choice flows from it.

What Blocks actually is

Blocks is an open-source TypeScript framework where each "Block" is an npm package that bundles three things: application code, a local development implementation, and the AWS infrastructure to run it in production. You import the Blocks you want, compose them in TypeScript, and run npm run dev. You get a working full-stack application with Postgres, authentication, and real-time messaging on your machine, with no AWS account required.

When you are ready to ship, the same code deploys to Lambda, DynamoDB, Aurora, API Gateway, Bedrock, Cognito, S3, and SES, with zero changes to your application code.

Roughly 20 Blocks are available covering databases (Postgres via Aurora, DynamoDB), authentication (Cognito), AI agents and knowledge bases (Bedrock), file storage (S3), real-time messaging, background jobs, scheduled tasks, and email (SES). The source is on GitHub under Apache 2.0, at aws-devtools-labs/aws-blocks.

The local-first trick is genuinely clever

Most infrastructure-from-code tools either force you to deploy to a cloud sandbox for every test, or hand you a half-working LocalStack approximation. Blocks does something different. It uses Node.js conditional exports to swap implementations based on context.

A line like new KVStore(scope, 'todos') resolves to an in-memory store during npm run dev, a DynamoDB table at deployment time, and an SDK call when the code runs in the Lambda runtime. Same import, same constructor, three different runtime behaviours determined by where the code is executing.

Hot reload kicks in on every save with sub-second feedback. DevelopersIO tested the full end-to-end flow from local startup through deployment to AWS sandbox and confirmed that writes to real Aurora and DynamoDB resources worked without code changes.

For anyone who has spent a Saturday debugging a CDK stack that only fails in us-east-1 at 2am, this is the bit of Blocks worth your time.

What "designed for AI agents" actually means

The marketing language here can read like vapour, so let me be specific about what AWS shipped.

Every Block ships with steering files embedded inside the npm package itself. These are instructions that coding agents (Claude, Cursor, Copilot, whatever you use) read when they pull the package into context. The files tell the agent the correct way to use the Block: which constructor signatures to use, which patterns to follow, which footguns to avoid.

The premise is straightforward. AI agents already write a lot of backend code. They get a lot of it wrong because their training data is full of outdated CDK patterns, half-broken Stack Overflow answers, and L1 construct usage that should be L3. Blocks tries to constrain the agent to the correct path by shipping the documentation directly in node_modules, where the agent will actually find it.

The InfoQ writeup describes the design intent as taking for granted that AI agents write code, and the framework itself carries the correct way to write from the start. The claimed payoff is a reduction in both human learning cost and the cost of agent mistakes.

I am sceptical of any framework that claims to make agent output reliable. I am more interested in this one than most, because the steering-file approach names the actual problem and tries to solve it at the package boundary rather than waiting for the next model to fix it.

It connects to what we wrote about the Model Context Protocol and agent-ready software. Blocks is the infrastructure-layer version of the same argument: if agents are going to build and modify your backend, the surface they compose against needs to be designed for that.

What a Block looks like in practice

The actual programming model is closer to high-level CDK constructs than to a config DSL. Here is a stripped-down example of what defining a backend looks like:

import { ApiNamespace, DistributedTable, AuthBasic, Realtime } from 'aws-blocks';
import { z } from 'zod';

const todos = new DistributedTable(scope, 'todos', {
  schema: z.object({
    id: z.string(),
    title: z.string(),
    completed: z.boolean(),
    priority: z.number(),
  }),
  indexes: ['byPriority', 'byTitle'],
});

const auth = new AuthBasic(scope, 'auth');
const realtime = new Realtime(scope, 'realtime');

export const api = new ApiNamespace(scope, 'api', {
  createTodo: async (ctx, input) => {
    await auth.requireUser(ctx);
    const todo = await todos.put({ ...input, id: crypto.randomUUID() });
    await realtime.broadcast('todo:created', todo);
    return todo;
  },
});

A few things worth noting. Schemas are defined with Zod, which simultaneously serves as runtime validation, TypeScript types, and the DynamoDB table shape. Indexes declared on the table become DynamoDB secondary indexes when deployed. The frontend imports api directly with full type inference, no codegen step, no OpenAPI spec to maintain.

The requireUser, put, and broadcast calls all run against in-memory mocks locally, then against Cognito, DynamoDB, and API Gateway WebSockets in production. The application code does not change between them.

The Amplify question

If you have been around AWS long enough, you are probably already asking it. How is this different from Amplify Gen 2?

Both define backends code-first in TypeScript on top of CDK. Both are "write your backend in TypeScript" experiences. AWS positions them as complementary: Amplify provides hosting, CI/CD, and a managed backend experience, while Blocks focuses on type-safe infrastructure-from-code with local-first development. There is no shared roadmap, no migration path, and no obvious story about which to choose if you are greenfield.

My read is that Amplify owns the "I want a managed full-stack platform" use case, and Blocks owns the "I want CDK with better ergonomics and proper local-first dev" use case. The AI agent steering is the part that genuinely differentiates Blocks from everything else AWS has shipped in this space.

There is also a CDK escape hatch. When you need deeper customisation, drop one layer into AWS CDK and configure the underlying resources directly. Blocks applications are CDK applications, and any CDK construct works alongside Blocks. You are not locked into an abstraction that cannot express what you need.

What I would not get excited about yet

This is a public preview. A few caveats worth pinning down before you build anything production-grade on it.

Block constructor signatures may change between preview releases. DevelopersIO already flagged this. If you start a project, pin your versions and assume you will rewrite a few things at GA.

Local data persistence runs against mock implementations. The mocks are good enough for testing application logic, but they will not catch every behavioural difference between DynamoDB and an in-memory KV store. Eventually consistent reads, transaction limits, throttling behaviour: none of that shows up locally. You still need real AWS sandbox testing before you ship.

Node.js 22 or later is required, according to the package.json engines field DevelopersIO surfaced during testing. If your CI runs on Node 20, that is a small but real upgrade cost.

GovCloud availability has not been confirmed at preview. Verify before you put regulated workloads anywhere near it.

The "AI agents produce correct architecture" claim is unproven at scale. Steering files are a sensible idea, but no public benchmark exists yet for how much they actually reduce agent error rates. Treat that part of the pitch as a hypothesis, not a guarantee.

Where this fits in the broader picture

There is a bet underneath all of this. AWS is betting that infrastructure code will increasingly be written by agents working alongside humans, and that the constraint surface of the framework matters more than the cleverness of the abstraction. You are not just designing for human readability anymore. You are designing for what an agent can compose without supervision.

I think that bet is correct, even if Blocks itself does not turn out to be the framework that wins. The interesting question is which other vendors copy the steering-file pattern. Vercel, Cloudflare, Supabase, Neon all have similar surface areas and similar incentives. Expect "agent-ready" to become a standard checkbox on framework documentation by the end of the year.

For now, Blocks is worth half a Saturday if you have any TypeScript backend work coming up. Spin up the default Todo template, ship it to a sandbox, see how the local dev loop feels. If you do not like it, you have lost an afternoon. If you do, you have a head start on what AWS clearly thinks is the future of how their customers build.

OrionX is an Adelaide-based software development and AI automation consultancy. If you are weighing an AWS-native stack for a new product and want a second opinion on the architecture, get in touch. We cover AWS cloud architecture in more depth on our cloud consulting page.