标签：#aws

El AWS Summit Bogotá 2026 mostró que la infraestructura en la nube es cada vez más un entorno dominado por agentes autónomos, esquemas de seguridad multi-capa y modelos de resiliencia avanzada. En este post entregó un resumen de los temas que pude observar y que comparto con ustedes. Ecosistema agéntico y optimización en la nube La presentación principal destacó la evolución hacia sistemas autónomos apoyados por herramientas como Amazon Quick Desktop que es un agente de IA local, el cual llamo mi atención al ser capaz de construir un grafo de conocimiento a partir del contexto profesional. También fue relevante la optimización continua en arquitecturas DevSecOps, apoyados por la transición hacia el paradigma agéntico . Estas aproximaciones exigen marcos como AWS Bedrock AgentCore , en el cual se aplica el concepto de Harness , estructurando así la orquestación, observabilidad y límites de control de los agentes. En el ámbito financiero, Itaú presentó el uso de AWS Kiro en sus procesos de migración, mientras que Nequi expuso la evolución de sus sistemas bancarios digitales. Para gobernar estos desarrollos, la seguridad se reconfigura hacia modelos como AWS Continuum , integrando modelado de amenazas, revisión de código y análisis de vulnerabilidades asistido por inteligencia artificial en el ciclo de desarrollo. Arquitecturas para cargas de misión crítica y resiliencia El diseño de sistemas tolerantes a fallos se analizó bajo la premisa de que la alta disponibilidad debe evaluarse mediante métricas de observabilidad avanzadas y presupuestos de error, más allá de comparaciones binarias de operatividad. Casos prácticos y mecanismos de failover Yuno detalló su arquitectura para mantener un SLA de 99.95% mediante despliegues Canary y pruebas de ingeniería de caos con AWS Fault Injection Service (FIS) . En entornos de alta demanda, el aislamiento regional apoyado por Zonal Shifts permiten desplazar el tráfico ante la degradación de una zona de disponibilidad. Se debe dest

August 3, 2026Lockhead Taking feedback - so essential for AWS every other tech company or startups #culture #aws #devops #aws #building #oss #build-in-public Taking feedback - so essential for AWS every other tech company or startups There’s a reason for this post: Last week I gave feedback to a good friend. It was something around “this thing doesn’t work for me, can you fix this?” Within hours, Ran had taken my feedback and incorporated it into his website. This little story motivated me to write this blog as in our industry we start to forget the importance of human interactions and the power of feedback. Feedback: A gift and a curse Feedback is a gift. Every content creator and startup developer will agree: Any piece of feedback you can get helps to shape your future as a creator or builder. It’s a gift that too many of us have stopped giving in 2026 - either because we’re busy building our own SaaS or because we’re too distracted by AI in our day to day job. The gift of feedback has made AWS one of the biggest cloud vendors and has helped Google Cloud to quickly win shares of the cloud market: by making things simpler that AWS made too complicated in the past years. The gift of feedback can be a rant or a viral post where you expressed your problems or concerns that you faced when you were building something. Feedback is a gift if it is clear enough to help you change something. Feedback can be a curse if it is given in the wrong format or tone. It can be a curse if it becomes or is taken personal and when it negatively impacts the work. Feedback is a curse when it is given with wrong intentions. It is a curse when it is being ignored. Feedback makes a difference This week, a bunch of AWS Heroes meet and the whole week is about exactly this: giving feedback . It’s a week where we get to talk and discuss in person with the teams we work with (mainly behind the scenes) through the whole year. We share - and openly fight with each other - on current and future AWS

By Swetha Golla · 8 min read · Senior Application Architect 🔗 This post has a live interactive version with a clickable per-service verdict and the full comparison matrix: read it here TL;DR Need strict per-key ordering and replay? That's a log, not a queue — Kinesis or MSK. Pick MSK if you need real Kafka wire-protocol compatibility (existing clients, Kafka Streams, ksqlDB, Debezium); pick Kinesis if you'd rather AWS own shard mechanics and you're fine with its API. Need routing logic based on event content, not raw throughput? EventBridge — pattern-matching rules to many differently-interested targets, not identical delivery to everyone. Need a simple durable buffer between one producer and one consumer group? SQS. Need the same message fanned out to many independent subscribers? SNS — often paired with SQS underneath. Already running RabbitMQ, or need AMQP-specific routing? Amazon MQ for RabbitMQ is a lift-and-shift, not a rearchitecture. The expensive mistake isn't picking a slightly-suboptimal service — it's picking a queue when you needed a log, or the reverse. That's a rewrite, not a config change. The setup Scope note: this is a decision matrix for AWS's own catalog, not a survey of every messaging technology that exists. Self-hosted Kafka, Google Pub/Sub, Azure Service Bus, NATS, Pulsar, and plenty of others solve overlapping problems outside AWS's walls — worth knowing about, out of scope here. A platform team is replacing a single overloaded RabbitMQ broker that has become the answer to every "how do services talk to each other" question for three years running: order events, fraud signals, audit trails, third-party webhooks, and a slow-growing analytics pipeline all queue through it. It works, until it doesn't — a queue depth spike during a promotion in 2025 backed up every consumer behind it, including ones that had nothing to do with the promotion. The team's instinct is to "move it all to AWS-native," as one service. That instinct is the mistake. Thes

I'm a big fan of using Claude and Claude Code for development. Many organizations are currently using these tools to improve developer productivity and ultimately build better products. Our role and our tools have changed — we went from powerful autocomplete to autonomous agents that can refactor, review, and implement features, most of the time better than we can on our own. Authentication methods There are several authentication methods, each with different billing, cost tracking, and governance options. Depending on your organization, you will choose the one that fits best. Personal development — Anthropic API key I use this for experimenting with the Anthropic library for learning and prototyping. You set ANTHROPIC_API_KEY in your environment (or a .env file), and the SDK picks it up automatically. Pay-as-you-go per token, no infrastructure needed. from dotenv import load_dotenv load_dotenv () import json import anthropic client = anthropic . Anthropic () tools = [ { " name " : " get_weather " , " description " : ( " Returns current weather for a city. Use ONLY for weather queries. " " Input: city name (string). Output: temperature in Celsius and conditions. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, { " name " : " get_time " , " description " : ( " Returns the current local time for a city. Use ONLY for time/timezone queries. " " Input: city name (string). Output: local time string. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, ] def get_weather ( city : str ) -> dict : return { " city " : city , " temp_c " : 22 , " conditions " : " sunny " } def get_time ( city : str ) -> dict : return { " city " : city , " local_time " : " 14:35 " } TOOL_FUNCTIONS = { " get_weather " : get_weather , " get_time " : get_time , } def run_agent ( user_message : str ) -> str : messages =

AWS open-sourced a persistent workspace that coordinates AI coding agents across sessions, schedules, and repos. Here's what it actually does and why it matters.

AWS introduced Kiro Crew on Tuesday as a new open-source orchestration platform. This tool aims to help businesses shift from interactive AI coding assistants toward autonomous engineering workflows. The system manages tasks across various repositories and developer tools over multiple work sessions to increase overall efficiency. Orchestrating autonomous development cycles Kiro Crew goes beyond simple code generation by coordinating multiple AI agents simultaneously. It schedules recurring work and maintains project context even when a session ends. This allows the system to integrate with standard developer tools for investigating incidents or monitoring pull requests. It triages tickets and automates software engineering tasks while developers are away from their workstations. The platform functions as an application layer that turns AI coding agents into self-learning teammates. It features persistent memory and multi-agent orchestration tools to ensure continuity. Security remains a priority with features like sandboxing and signed audit logs. Users can monitor activity through a dedicated web and desktop dashboard designed for transparency. Before its public release, the project existed inside Amazon as an internal tool named MeshClaw. More than 39,000 Amazon builders adopted it in less than six months. This internal success paved the way for the current open-source offering. Companies can deploy the platform entirely within their own environments, such as on local laptops or virtual machines. Reference applications and practical use cases AWS launched several reference applications to show how the platform functions in real-world scenarios. DevFleets manages worktrees, while Issue Radar handles the triage of pull requests and tickets. Task Runner focuses on executing engineering tasks that require a long duration to complete. These apps use specific interfaces combined with the core orchestration engine. These tools are not standalone products but rather exam

Your AI bill tripled last quarter. Your CTO forwarded you an article about companies saving 70% by switching to open models. Now someone is asking you to figure out what that would actually look like. I spent the last few weeks digging into this. The numbers, the hardware, the real trade-offs. Here's what I found, with enough specifics that you can actually make a decision rather than just nodding along to another "open source is the future" think piece. What "Open Models" Actually Means When someone says "open model" they mean an AI model where the weights (the learned parameters that make the model work) are publicly downloadable. You grab the file, run it on your hardware, and you don't pay anyone per request. The big names right now: Meta's Llama 4, DeepSeek V4, Zhipu's GLM-5.2, Moonshot's Kimi K3, Alibaba's Qwen 3.5, and Google's Gemma 4. These aren't toys. Some of them genuinely compete with the frontier models on real benchmarks. Chinese open models now handle over 30% of enterprise traffic on OpenRouter, up from 4.5% in early 2025. That's a massive shift in barely a year. The Architecture: What You Actually Need You want your team to use an open model. Here's the stack, from bottom to top. Hardware (The Expensive Part) A model is a giant file. We're talking anywhere from 4 GB (a small 7B model, quantized) to 1.5 TB (Kimi K3, full weights). That entire file needs to sit in GPU memory to run fast. Why GPU memory specifically? Because generating each word in a response requires billions of multiply-and-add operations. GPUs do thousands of these in parallel. A CPU does them one at a time. The practical difference: a 7B model on a CPU generates 2-5 tokens per second (painfully slow for interactive use). The same model on a GPU generates 30-80 tokens per second (feels instant). For one person on a CPU, it might be tolerable. For a team of 10 all hitting the same endpoint? Unusable. Requests queue up and everyone waits 30-60 seconds for responses. Think of it like

Most companies we work with don't have a data inventory. When we ask "where's your data listed?" (where it lives, what it contains, who owns it), the answer is usually some version of "we don't have one." No comprehensive map of data locations. No business impact assessment for different data types. Unclear ownership and accountability. You can't protect what you haven't mapped. And you can't make good decisions about backup strategy when you don't know what you're backing up. Data Has a Half-Life Not all data ages the same way. Some data becomes stale quickly. If you're aggregating information from external sources like market data, business intelligence, or operational metrics, the value is often in the freshness. Yesterday's data might be useful for trends, but it's not the crown jewels. Source data and processed insights need different protection levels. The raw inputs you collect might be recreatable from upstream sources. The analysis and transformations you've built on top might take significant effort to reconstruct, or might be regenerated in hours if you have the pipeline intact. This changes the backup math. If your data pipeline gets destroyed but you can pull from upstream sources and recreate everything within an acceptable timeframe, maybe you don't need to back up the work product at all. Maybe you just need to protect the source data and the pipeline itself. Understanding your data's half-life helps you spend backup dollars where they actually matter. The Cost vs. Risk Conversation Backup costs can reach hundreds of thousands of dollars annually. Cross-region replication, long-term retention, disaster recovery infrastructure. It adds up fast. That's money not going to engineers or product development. A real tradeoff. The question is: what's the actual business impact if this data disappears? What's the downtime cost? What's your real risk tolerance? These are executive decisions, not just technical ones. They require someone to say "we're willing t

As a software engineer starting with AWS, you might feel overwhelmed by all the services. Let me break down the key components with real-world examples to help you get started. 1. DNS & How AWS Route 53 Works Problem: Users can't remember IP addresses like 54.210.167.101 for your app. Solution: AWS Route 53 (DNS service) maps yourdomain.com to your servers. Real example: Your startup has servers in Ohio and Frankfurt. Route 53 automatically sends European users to Frankfurt and routes US traffic to Ohio — faster load times for everyone. 2. Networking: VPC & Subnets VPC: Your private cloud network (like an office building). Public subnet: For web servers (needs internet access). Private subnet: For databases (blocked from direct internet access). Internet Gateway: Connects public subnets to the internet. NAT Gateway: Lets private subnets reach the internet (one-way). Real example: In your e-commerce app, the web server runs in a public subnet while the database sits in a private subnet. 3. Storing & Delivering Static Files (S3 + CloudFront) Amazon S3: Stores images, videos, and logs. CloudFront (CDN): Caches content globally for faster loading. Real example: Your blog hosts images in S3; CloudFront caches them in 450+ locations, so a reader in Tokyo gets images from Japan instead of Virginia — cutting load time by ~50%. Pro tip: Enable S3 Versioning to recover accidentally deleted files. 4. Running Backend Services AWS Lambda (Serverless) — best for event-driven tasks. Example: a photo app resizes images automatically on upload. EC2 (Virtual Servers) — best for full control (custom OS, legacy apps). Example: hosting a Java monolith with specific dependencies. ECS/EKS (Containers) — best for microservices (Docker/Kubernetes). Example: a food-delivery app with separate services for orders, payments, and tracking. 5. Databases: Picking the Right One Amazon RDS (SQL): Structured data with relationships — e.g. user accounts + orders. DynamoDB (NoSQL): High-speed, scalable

Amazon Nova Pro matched a 4GB open-weight model running on a laptop on German PII redaction: 94% exact-value recall against 93%. Nova Micro, the cheapest model in the family, tied Amazon Comprehend on the same test at roughly a twentieth of the cost per document. And the model that lost hardest was the one fine-tuned for German. Here is what we measured across six approaches, two languages, and four orders of magnitude of cost. The blocker is not the model You have data. It contains names, email addresses, phone numbers, IBANs, dates of birth, health codes, account numbers. You want a language model to summarize it, classify it, extract from it, or index it for search. The model is capable. The data is ready. The personally identifiable information in it is what stops you. GDPR, HIPAA, and data processing agreements restrict where PII can transit, and approval for your cloud provider is not approval for every service inside it. Internal access controls make it worse rather than better: legal can see contract party details and finance cannot, but those boundaries live in your systems of record and dissolve the moment raw data enters a shared RAG index or a prompt template three teams call. An analyst asking for revenue from client X can get an answer derived from a contract they have no clearance to read. Then there is the leak nobody plans for. Production data reaches development accounts constantly, through payloads copied while debugging and dumps used to build test fixtures. And when the compliant workflow takes three days and the non-compliant one takes three minutes, people take the three minutes: a support engineer pastes a complaint into a consumer chatbot, a recruiter runs a CV batch through a free tool. This is not a security failure. It's a workflow design failure. A redaction layer separates the concerns. Process the data before it reaches any model, replace identities with typed placeholders, let the model work on structure and meaning. Which scale are y

AWS now allows vibe coding tool Superblocks to be embedded into the private clouds of AWS customers. It's another step towards decoupling apps from models.

More than a year ago, which is practically ancient history in the AI years, I wrote a blog about using AI to build new self-service capabilities. It felt like the future. We built a self-service action that could create new self-service actions, helping us move faster, reduce bottlenecks, and scale a small Platform Engineering team supporting hundreds of developers. One of the most interesting parts was using Amazon Bedrock to generate Terraform code dynamically at runtime, allowing the system to determine how a new cloud resource should be provisioned using our existing Terraform modules. It worked. It was impressive. And… we removed it. Looking back, abandoning that approach turned out to be one of the best engineering decisions we made. At the time, it felt like an isolated technical decision. It wasn’t. Recently, we faced a much smaller problem. We wanted to automate the creation of DNS records in Cloudflare through our self-service platform. The first proposal was exactly what you’d expect today: “Let’s build a Claude Skill.” Immediately, I had a strong sense of deja vu. But my hesitation wasn’t about whether AI could do it — it was about whether it should. We were simply asking the wrong question. The Industry Shift A lot of engineers today feel like everything they learned over the last decade suddenly became less relevant. We are DevOps engineers. We are Platform Engineers. We used to spend time designing systems, defining standards, reviewing architectures, and planning before writing a single line of code. Every automation started with the same question: “How should we automate this?” Today, that question has quietly changed. Now we ask: “How can AI do this?” At first glance, that sounds like progress. And sometimes it is. Large Language Models have fundamentally changed the way we build software. Tasks that used to take hours now take minutes, and entire prototypes appear from a single prompt. The temptation is obvious. If AI can do it… why not let AI do

Yesterday I announced I'm blogging daily on AWS & DevOps. Here's Day 1 — the fundamentals everything else builds on. ## What is Cloud Computing? Instead of setting up and maintaining infrastructure on-premises, you now access computing resources remotely over the internet — this is Cloud Computing. "Cloud" refers to a network that provides resources over the internet, accessible whenever needed. It evolved from grid computing, virtualization, and distributed computing. All you need to use it is a web browser. As per NIST , cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort. Key characteristics: uses virtualization, enables on-demand access, and offers "pay-as-you-use" pricing. Traditional companies had to spend heavily on infrastructure, hardware, and operations. With cloud computing, providers manage all of this — handling troubleshooting, recording activity, and sending analytics data to users. Service Models — IaaS, PaaS, SaaS IaaS : Providers offer databases, servers, storage, and networking as a service, and you pay per use. Examples: AWS, Azure, GCP. PaaS : Gives you an on-demand environment for developing, testing, and delivering apps, with ready dev tools already set up. Examples: Heroku, Google App Engine. SaaS : Delivers ready-to-use software over the internet, usually via subscription, with the provider managing everything underneath. - Examples: Gmail, Microsoft 365, Google Drive. The layered view: moving from On-Premise to IaaS to PaaS to SaaS, each model hands you a bigger pre-managed slice. On-premise means you manage everything yourself. IaaS shifts virtualization, servers, storage, and networking to the vendor. PaaS additionally hands over OS, middleware, and runtime. SaaS means the vendor manages everything — you just use the app. The biryani a

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . The build was done. Themis Lex worked on my machine, and not in the "works if you squint" way. A court clerk enters their role, describes their workflow, picks a data sensitivity level, and gets back a PDF with two sections: where AI can safely support the work, and where it must never touch it. Claude via Bedrock generates the assessment. Server-side PDF render. No accounts, no storage, session ends when the download does. Three weeks solo, for the Women in AI Accelerator Spring 2026 Build Challenge. Initial commit went in at 7:06pm on May 9. I pushed to AWS Amplify . Build went green. I opened the live site, filled out the form, hit submit. Nothing. Twenty eight seconds later, "Request timed out." I told myself the bug was not in my code. Everything ran locally. This had to be a platform problem. That belief carried me all night. It mostly held up. The exception was the first thing I should have checked. Here is the commit log, because it tells the story better than I can: 19:06 Initial commit: Themis Lex MVP 20:31 refactor: migrate Bedrock auth to IAM compute role 22:29 diag: log credential env vars at runtime (booleans only, remove after fix) 22:40 fix: forward BEDROCK_MODEL_ID to SSR runtime via next.config.js env 22:50 fix: switch to InvokeModelWithResponseStreamCommand to beat 28s Lambda timeout ... 06:28 fix: remove unused type export that broke isolatedModules build 06:37 fix: end-to-end response streaming to beat Amplify 28s gateway timeout 06:48 fix: reduce max_tokens to 3000 to fit Amplify 30s timeout 06:52 fix: reduce max_tokens to 2000, 3000 still exceeded 30s timeout 07:00 fix: switch to Claude Haiku 4.5 to fit Amplify 30s timeout Ten and a half hours from first deploy to the fix that shipped it. That gap between 22:50 and 06:28 is me sleeping on it, which turned out to be the second most productive thing I did. The error message was the absence of an error message My f

Three bugs we found and fixed in our own pipeline this week Journeymen grades developer work against GitHub's server-side history. That only means something if the grading pipeline itself is reliable — so here's the honest engineering update, not the highlight reel. 1. Silent progress loss on connect-repo analysis runs A connect-repo analysis run could sit in processing status with no visibility into what stage it was actually at, or whether it had stalled. From a dev's dashboard, a slow run and a stuck run looked identical. We added explicit progress-stage tracking so a stuck run is visibly stuck, not silently pending. 2. A background worker timing out without a clear signal The Lambda-based worker handling asynchronous analysis jobs was hitting its timeout under certain repo sizes, and the failure mode wasn't obvious from the outside — a run would just never complete. We root-caused the timeout and fixed the underlying slow path. 3. Dead-letter queue with no observability Jobs that failed enough times to land in the SQS dead-letter queue were, until this week, invisible — no alerting, no in-product surfacing. We wired up observability so a DLQ arrival is now a visible signal instead of a silent dead end. Why post about our own bugs The entire pitch of Journeymen is "don't trust the self-reported version, trust the verified one." That standard has to apply to us too. All three issues: found, fixed, and shipped this week. journeymen.in

We've all done it. You spin up an RDS instance to test something on a Friday afternoon. You attach an EBS volume to a t3.micro that you kill three days later — but the volume just... stays. You allocate a static IP for a load test, and the load test ends, but the IP doesn't know that. None of this shows up as an error. Nothing crashes. There's no red banner in the console screaming at you. It just quietly sits there, accruing charges, until you open your AWS bill a month later and go "wait, why are we paying for that ?" I call these zombie resources — infrastructure that's technically alive (and billing you) but functionally dead. It's happened to me enough times on side projects and client work that I've started designing a small tool to stop it: CloudZombie . Heads up: this is early. There's no working product yet — I'm validating the idea and building in the open, starting with a waitlist. If that's not your thing, no hard feelings, but if you've felt this exact pain before, I'd love your take. The problem, more specifically Cloud waste isn't usually one big dramatic mistake. It's death by a thousand cuts: Orphaned EBS volumes — you terminate an EC2 instance, but the attached volume doesn't get deleted with it, so it just sits in an "available" state forever. Idle databases — that staging or QA RDS instance nobody remembers spinning up, quietly running at under 1.5% CPU for weeks. Abandoned static IPs and load balancers — cloud providers actually charge more for an Elastic IP that isn't attached to anything, which feels like a small act of cruelty. Individually, each one is a few dollars a month. Collectively, across a handful of side projects or a growing team's sprawl of staging environments, it adds up to real money leaking out of your runway — with zero warning. What CloudZombie is meant to do The plan is for CloudZombie to connect (read-only) to your AWS account and scan specifically for these patterns: Unattached EBS volumes sitting idle Databases with sust

AWS Builder Center now offers free, time-limited sandbox environments for workshops, so developers no longer need to use their own AWS account and credit card or worry about unexpected charges. This has been a long-standing request from the community and removes one of the biggest friction points for practitioners learning new AWS technologies. By Renato Losio

I was on a call last month with a startup CTO who had just gotten their AWS bill. They had built a beautiful RAG application: semantic search, conversational AI, the works. Their vector index was humming along with about 50 million embeddings. Then they hit product-market fit. Within six weeks, they scaled to 500 million vectors. Their monthly infrastructure costs went from $2,000 to $20,000. The real kicker? When we looked at the access patterns, over 80% of those vectors were queried less than once a week. They were paying hot-storage prices for data that was, by any honest measure, cold. The standard advice here is "just use a cheaper vector database." The more interesting question is: why are you storing all your vectors at the same temperature in the first place? The Cost-Recall-Latency Triangle Vector search forces a three-way tradeoff. You can optimize for cost, recall, and latency, but you only get to pick two. Want high recall and low latency? That costs money (in-memory HNSW graphs with full-precision vectors eating RAM). Want high recall at low cost? Latency goes up. Want cheap and fast? Recall suffers. Most teams pick a single point on this triangle and apply it uniformly to every vector in their index. That decision made sense when vector databases offered a single storage tier. It makes the same amount of sense as storing your entire filesystem on NVMe SSDs because some files need fast access. The conventional wisdom says you pick your point on the triangle and live with it. But the conventional wisdom was written before vector storage got interesting. The better approach: tier your vectors the same way you already tier your storage. Different access patterns deserve different economics. The same embedding that costs $0.12/month in RAM might cost $0.004/month on disk and $0.0002/month in object storage. When you have 500 million of them, those decimals matter. The Hot Tier: In-Memory HNSW and Exact k-NN For vectors that get hit constantly (your user-fa

Usar IA no dia a dia não é nenhuma novidade, e praticamente TODO O MUNDO já sabe disso. E hoje temos diversos "sabores" de IA, inclusive para todos os gostos, e escolher um só é difícil, porque cada um tem seu molho especial em alguma tarefa específica. Eu, como não é novidade, acabei adotando como meu "favorito das últimas semanas" o Kiro...e confesso, muito no começo pelo ícone de fantasma que acho muito massa rss, mas conforme fui usando melhor, comecei a entender a sua estrutura, e principalmente o spec-driven, aí ele me conquistou de uma maneira meio que irreversível. E engraçado que hoje mais cedo quando estava dirigindo a caminho do supermercado, pensando nas minhas demandas e atividades, comecei já a estruturar meu "steering" mentalmente de uma nova task que precisaria fazer, e nisso me veio um pensamento...Caraca! Estou usando o Kiro para praticamente tudo! É isso que quero compartilhar com vocês hoje, um pouco de não só como estou usando, mas onde e para que! Trabalho nosso de todo dia Esse é meio que óbvio né? Seja um desenvolvedor, vibe-coder, arquiteto, engenheiro e tal, todo mundo está na onda de usar a IA para acelerar seu trabalho. Como comentei acima, o spec-driven do Kiro me conquistou porque eu não saio simplesmente "curando código gerado pela IA", eu realmente troco uma ideia com a IA e estruturo realmente a arquitetura daquilo que quero construir. A geração de código virou somente a consequência de toda essa sólida estrutura que conseguimos criar antes, e nesse ponto deixei de ser apenas um curador para assumir realmente a posição de arquiteto da feature que estou desenvolvendo. Conteúdo para comunidade Inclusive, esse artigo é fruto de um pouco disso! Não é sobre ser preguiçoso e deixar a IA gerar o conteúdo (o que eu acho errado também!), mas sim em "se transformar" em uma skill, onde você produz o conteúdo (VOCÊ criando o conteúdo!) e passa por essa skill para correção de gramática, compreensão, internacionalização e regionalização...uso muit

TL;DR I designed a proposed AWS Transform Custom community skill that prepares Glue 2.0, 3.0, and 4.0 repositories for Glue 5.0. It separates safe mechanical transformations from changes that require human evidence, generates a migration report, and preserves already-compatible files unchanged. Because I didn't have live atx access, the benchmarks in this post are explicitly labeled manually simulated, not agent-executed. The proposal is open as issue #75 — not yet merged, not yet a pull request. The missing data-engineering transformation AWS Transform Custom can apply agent-driven code transformations across a single repository — or thousands of them at once, via AWS Batch and Fargate. As of July 30, 2026, its public sample repository, aws-samples/aws-transform-custom-samples , contained three community-contributed transformations: an EKS version-upgrade-readiness skill, a JBoss-to-Spring-Boot migration, and a Kubernetes readiness migration. None of them touched data engineering. Given that most of my day-to-day work sits across AWS data engineering, Databricks, and Delta Lake, that gap was the obvious thing to fill. What an AWS Transform Custom "skill" looks like Before writing anything, I studied the deepest existing example, jboss-to-springboot , since the pattern it establishes is effectively an unwritten spec for the other two skills as well: README.md — the problem, what the skill does, and how to invoke it via the atx CLI. This is also where the repo draws a clear line: these are readiness transformations. They modify repository artifacts — code and infrastructure-as-code — but they don't deploy jobs, call AWS APIs to change running resources, or claim data-level equivalence. That distinction matters throughout everything below. SKILL.md — the agent-facing definition: YAML frontmatter with trigger keywords, an Objective, explicit Non-Goals , Constraints, worked before/after examples, a "signal in source code → reference file" routing table, and a numbered V