AWS AI-Driven Development Lifecycle (AI-DLC) Champions Advanced (L300)

AWS AI-Driven Development Lifecycle (AI-DLC) Practitioner Intermediate (L200)

AWS AI-Driven Development Lifecycle (AI-DLC) Ambassador Foundational (L100)

AWS Certified Generative AI Developer - Professional

AWS Certified Advanced Networking – Specialty

AWS Certified Machine Learning – Specialty

AWS Certified DevOps Engineer – Professional

AWS Certified Security – Specialty

AWS Certified Solutions Architect – Professional

AWS Certified CloudOps Engineer – Associate

AWS Certified SysOps Administrator – Associate

AWS Certified Data Engineer – Associate

AWS Certified Machine Learning Engineer – Associate

AWS Certified Developer – Associate

AWS Certified Solutions Architect – Associate

Claude Certified Architect - Foundations

AWS Certified AI Practitioner

AWS Certified Cloud Practitioner

AWS Data Lakehouse Demonstrated

AWS Data Streaming Demonstrated

AWS Data Visualization Demonstrated

AWS Incident Response Demonstrated

AWS MLOps Demonstrated

AWS Application Networking Demonstrated

AWS Agentic AI Demonstrated

AWS Serverless Demonstrated

De Yapamatico a la nube: la historia, las certificaciones verificadas en Credly y los territorios técnicos que exploro.

Sobre mí

Mis acreditaciones de AI-DLC

AI-DLC (AI-Driven Development Life Cycle) organiza el desarrollo asistido por IA en fases trazables —de la intención a los requisitos, el diseño, la construcción y la operación— con una puerta de aprobación antes de cada avance.

AI-DLC: la IA ejecuta, las personas deciden

Con Kiro el punto de partida no es un chat, es una especificación: requisitos, diseño y tareas antes de generar código. El steering guarda las convenciones del repositorio una sola vez y los hooks se ocupan de lo repetitivo.

Kiro: la especificación como unidad de trabajo

Los agentes escriben mucho código muy rápido, y eso vuelve más valiosas —no menos— las decisiones que no se delegan: los límites del sistema, los compromisos que aceptamos y lo que estamos dispuestos a mantener durante años.

Lo que la IA no decide

La IA dejó de ser el autocompletado y pasó a ejecutar. Eso no elimina el criterio: cambia dónde hace falta ponerlo. Estas son las tres ideas con las que trabajo hoy.

La IA dejó de ser el autocompletado y pasó a ejecutar. Trabajo con AI-DLC, que organiza el desarrollo asistido por IA en fases con una puerta de aprobación antes de cada avance, y con Kiro, donde la unidad de trabajo es la especificación y no el chat. Lo que no se delega: los límites del sistema, los compromisos y lo que estamos dispuestos a mantener durante años.

Construir con IA

Las buenas ideas mejoran cuando se comparten. Escríbeme un correo, o encuéntrame en LinkedIn y GitHub.

Sigamos la conversación

{exams} certificaciones y {micro} micro-credenciales vigentes. Cada insignia enlaza a su verificación en Credly.

{exams} certificaciones vigentes. Cada insignia enlaza a su verificación en Credly.

Certificaciones

Una historia que empieza en dos pueblos de Falcón, pasa por una computadora 286 y sigue abierta.

De Yapamatico a la nube

Tecnologías y disciplinas que forman parte de mi trabajo y de las preguntas que desarrollo en este sitio.

Territorios que exploro

Las mejores arquitecturas empiezan con una pregunta honesta.

Andrés Aguilar

Las cuatro ideas con las que pienso la arquitectura antes de elegir una tecnología, y cómo entra la IA en el ciclo de desarrollo: AI-DLC, Kiro y lo que no se delega.

Principios

La tecnología cambia rápido. El propósito y los principios nos ayudan a elegir qué merece permanecer.

Una arquitectura útil empieza por comprender a quién sirve, qué problema cambia y qué decisión debe hacer posible.

Diseñar desde el propósito

Los sistemas duraderos rara vez nacen completos. Aprenden, se adaptan y mejoran sin convertir cada cambio en una apuesta total.

Evolucionar de forma incremental

Construir también significa cuidar lo que ocurre después: seguridad, resiliencia, observabilidad y una operación comprensible.

Operar con responsabilidad

El coste, la complejidad y la energía no son detalles finales. Son límites que pueden conducir a soluciones más simples y mejores.

Eficiencia como restricción creativa

Cómo pienso

No son respuestas universales. Son ideas que uso para pensar con más claridad antes de elegir una tecnología.

Escribo para ordenar ideas, compartir lo aprendido y dejar mejores preguntas sobre arquitectura, cloud y tecnología.

Lo que escribo

Cuando un agente genera la implementación a partir de una especificación, la spec pasa a ser el artefacto que versionas, revisas y tratas como fuente, y el código generado se comporta como el binario que sale de un compilador. Este ensayo sostiene que el arquitecto deja de revisar el desensamblado y empieza a revisar la fuente, y que por eso el esfuerzo de revisión y la gobernanza tienen que mudarse a la spec, con la capa de guardrails como el lugar donde sus garantías se compilan.

La spec es el código fuente, el código es el binario

Cada grado de autonomía que le concedes a un agente de IA es una restricción que le quitas, y la arquitectura, siguiendo a Gregor Hohpe, es la disciplina de satisfacer restricciones, no de eliminarlas. Este ensayo sostiene que la autonomía funciona como un poder de firma delegado: un límite de aprobación que se fija antes de la transacción, crece con el historial demostrado y vive en el límite, no en revisar cada movimiento después. El trabajo del arquitecto no es maximizar la autonomía del agente, sino calibrar ese límite, porque la autonomía se concede barata y se recupera cara.

La autonomía es una firma en blanco

Cuando un agente de IA escribe código casi gratis, cada línea deja de comportarse como un activo en el que invertiste y empieza a comportarse como inventario en una estantería: algo que hay que almacenar, entender, asegurar y algún día tirar. Este ensayo sostiene que la restricción se muda de la fábrica (escribir) al almacén (mantener y comprender), y que por eso la palanca del arquitecto se traslada a las restricciones que el agente lee: especificaciones, reglas de gobierno y guardrails.

El código es inventario, no un activo

Descomponer por volatilidad no dice cuál de las volatilidades que encuentras merece un módulo, y ahí es donde se pierde el dinero. Este artículo trata cada encapsulación como una póliza de seguro que hay que cotizar: la prima se paga en cada feature futura, la indemnización solo llega si el cambio ocurre, y la prima no la fija el código que escribes sino lo que la encapsulación te prohíbe. Con aritmética, un caso documentado y una escala de franquicias para no elegir entre todo y nada.