"Authentication works. However, the password hashing implementation is close to plain text, and token revocation hasn't been implemented." This is the kind of report that surfaces during reviews of backends left to agents. There is certainly a working demo. Look under the hood, however, and table designs, error handling, and authentication have all been pieced together haphazardly depending on the prompt at that specific moment; deploying it to production will inevitably break somewhere. Anyone who has started having AI agents write backends in custom development has likely experienced this "works, but terrifying" state at least once.
The problem isn't that agents lack skill. It is that because agents aren't given "the architecture considered correct for this project," they re-select whatever seems best on the fly each time. In other words, the root of the problem lies in failing to prepare a "framework for the correct way to write code" before having them write it.
As one answer to this, AWS released a framework called "AWS Blocks." In this article, we reframe this not as a "tool to accelerate generation," but as a "foundation to enforce correct backends on AI," and analyze from the perspective of an enterprise systems architect whether it is practically viable for custom development and where the line should be drawn.
The problem AWS Blocks aims to solve
AWS Blocks is an open-source TypeScript framework that entered public preview on June 16, 2026 (InfoQ's commentary summarizes AWS's introductory article well). At its core is a unit called a "Block," an npm package that packages a single backend feature—such as database tables, user authentication, AI agents, file uploads, background jobs, scheduled tasks, real-time notifications, or email sending—together with application code, local mocks, and AWS infrastructure definitions.
Developers import and combine the Blocks they need. Behind the scenes, AWS infrastructure aligned with best practices is generated (Cognito for authentication, via Aurora for Postgres, Bedrock for AI, S3 for storage, and so forth). Around 20 types of Blocks are available at the preview stage. Its selling point is that it runs locally without an AWS account, and the exact same code can be deployed to Lambda, DynamoDB, Aurora, Bedrock, and other services with zero modifications. There are no additional charges for Blocks itself; billing is incurred only for the AWS services actually used.
Up to this point, it might sound like an "AWS-style handy starter kit." However, what truly deserves attention is its design philosophy.
Designed on the premise that "AI agents write it"
What sets AWS Blocks apart from conventional scaffolding tools is that it is built from the ground up on the premise that "AI agents, not humans, write the code." Each Block incorporates guidance definitions called "steering files," which direct coding agents toward the correct architecture without custom configuration.
This is quietly something practitioners in custom development have wanted. As touched upon in our article organizing the division of roles across AGENTS.md, SKILL.md, and DESIGN.md regarding mechanisms for instructing AI, externalizing "what to write and how to write it" into files and instilling the project's conventions into agents is becoming standard practice. Blocks comes standard with that steering component packaged in the form of AWS best practices. Rather than making architectural decisions from scratch each time, agents write code along the rails laid down by Blocks. As a result, architectural variance in generated output is structurally suppressed.
AWS already has Amplify and App Studio, but Blocks occupies a slightly different position. While Amplify leans toward hosting and full-stack integration, and App Studio aims for a low-code creation experience, Blocks strongly emphasizes being local-first, composable (built around combination), and agent-first. Rather than providing managed turnkey products, its approach is to hand agents the parts and steering necessary to assemble things correctly.
What to look at in custom development is not "generation speed"
This is the core argument of this article. When evaluating Blocks for custom development, centering its value on "backends getting up and running quickly" leads to poor decisions. Speed is merely a byproduct. Its true value for custom development lies in gaining a foundation capable of enforcing the correct architecture on AI—in other words, raising the quality floor.
Until now, the quality of agent-written backends depended on prompt proficiency and the luck of the day. On good days it was clean, but on bad days authentication was full of holes. When components are predefined as in Blocks—"authentication uses this Block, DB uses this Block"—even worst-case scenarios don't fall below a certain standard. What is terrifying in custom development is not the average, but the worst-case value. The most flawed part of a deliverable directly causes incidents and client complaints. That is why a tool that raises the floor is inherently valuable for custom development.
However, there is something that must not be mistaken here. Even when adopting Blocks, architectural responsibility still rests with humans (ourselves on the custom development side). The rails laid down by a Block are merely generic best practices, not architectural judgments tailored to the business requirements in front of you. Deciding which Blocks to choose, how to combine them, and where to place business logic is up to humans. Blocks is a "tool to guarantee a floor," not a "tool to take over architecture." The moment this boundary blurs, you fall into the pitfalls discussed later.
Scenarios suited and unsuited for custom development
Speaking from my experience working on vending machine management systems, equipment control, and core enterprise and business backends, whether Blocks is suitable varies considerably depending on the project's phase and constraints.
It is well-suited for new small-to-medium-scale backends and PoC/validation phases. It saves the trouble of building scaffolding from scratch, allowing agents to reliably write parts that "end up similarly implemented every time," such as authentication, jobs, and storage. It shines where both rapid startup and a solid quality floor are effective, especially in projects where the decision to adopt AWS is already established. Our database selection on AWS is also organized in our article on using Aurora Serverless v4 for database modernization in custom development, which should help in understanding behind the scenes of the infrastructure generated by Blocks.
Conversely, there are weaknesses that should be stated candidly.
| Discussion point | Considerations for custom development |
|---|---|
| AWS lock-in | Generated setups assume AWS. Projects with multi-cloud or future migration requirements can easily run into a dead end. |
| Preview stage | It is in public preview, meaning specification and breaking changes are possible. Exercise caution for production adoption. |
| Retrofitting to existing projects | Splicing Blocks into running systems is difficult. Greenfields are the standard baseline. |
Lock-in, in particular, is an issue to confirm during contract negotiations. If a client mentions "we might switch clouds in the future" yet you lock things down with AWS assumptions, significant rework will follow later. The scope of enterprise AI utilization on AWS is also covered in our article on using Claude Platform on AWS in custom development, but in any case, the proper approach is to adopt it only after aligning with the client on "why we are centering on AWS."
Extending steering files to match your company's conventions
To truly master Blocks in custom development, one should go as far as operationalizing it by extending the bundled steering files with your company's conventions, rather than using them as-is. This is because the guidance prepared by AWS is "generally correct," but not necessarily "correct for your company."
Specifically, add rules upheld by your company in custom development to the steering side, such as naming conventions, layering (where to put domain logic and where to put I/O), testing policies, and unified error handling patterns. Doing so allows code written by agents to simultaneously follow both AWS best practices and internal conventions, reducing the friction of repeating the same feedback during every review.
// 例: 自社の steering に「ドメイン層を薄いI/Oから分離する」方針を足すイメージ
// Block が生成する auth() / db() は I/O 境界として扱い、
// 業務ルールは domain/ 配下のピュアな関数に閉じ込める、と誘導する。
import { auth } from "@aws/blocks-auth";
import { table } from "@aws/blocks-dynamodb";
import { approveInvoice } from "../domain/invoice"; // 副作用を持たない業務ロジック
export const handler = async (req: Request) => {
const user = await auth.requireUser(req); // I/O境界(Block)
const invoice = await invoices.get(req.invoiceId); // I/O境界(Block)
const next = approveInvoice(invoice, user); // 純粋な業務判断(自社流儀)
await invoices.put(next); // I/O境界(Block)
return Response.json(next);
};The key is connecting the rails provided by Blocks (authentication and database access) with the architectural decisions your company wants to preserve (business logic placement and testability) at the steering layer. Areas where framework defaults clash with internal rules are precisely where technical managers should establish policies in advance.
"It was written by an agent, so it must be right" is the biggest pitfall
Finally, let us highlight the most dangerous patterns when using Blocks in custom development.
First is skipping verification under the assumption that "it was written by an agent following Block guidance, so it must be right." Even if steering files raise the floor, they do not guarantee a ceiling. Alignment with business requirements and edge-case behaviors must still be reviewed by humans and verified through tests. How to receive and review agent-mass-produced code was covered in detail in our article on reviewing and managing code mass-produced by AI agents, but beware that a stronger foundation actually increases the temptation to skimp on verification.
Second is forcing Blocks into requirements that deviate from composable assumptions. Blocks is optimized for "combining typical backend features." If you force Blocks onto requirements that cannot be captured by combining components—such as complex state transitions unique to enterprise systems or tight integration with existing core systems—you end up with a distorted architecture. Such domains should honestly be built outside Blocks.
Third is underestimating lock-in and getting trapped by multi-cloud requirements. As mentioned earlier, this must always be aligned with the client during the adoption decision phase.
None of these issues stem from Blocks being inherently flawed; they occur as a result of mispositioning the tool. Blocks is a foundation that raises the quality floor, not an entity that relieves you of architectural and verification responsibilities—as long as you keep this single point in mind, it serves as a dependable option for custom development.
Where to begin
If you are currently having AI agents write backends and output quality fluctuates across projects, start by questioning whether you are in a state of "giving the agent no architectural direction whatsoever." Testing a framework with built-in steering like Blocks on a small PoC to see with your own eyes how well the floor of generated artifacts aligns is a realistic first step.
Once that is done, clarifying two points—whether the project is suitable for centering on AWS (tolerating lock-in) and how to incorporate internal conventions into steering—should make the decision on how to integrate Blocks into custom development considerably clearer.
Whether you want to redesign a new backend around AI agent assumptions, consult on how to integrate Blocks into custom development workflows, or rebuild a "working but terrifying" backend into a structure with predictable quality, please reach out through the GleamHub contact form. After reviewing your requirements and constraints, we will work alongside you from establishing the boundary between what to entrust to AI and what humans should govern.
