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 la salida de un agente es no determinista, una suite de pruebas en verde deja de ser una compuerta que demuestra que el sistema es correcto y pasa a ser una muestra con un intervalo de confianza: «verde» significa «no atrapé un defecto en esta corrida», no «es correcto». Este ensayo lleva el muestreo de aceptación de la manufactura a la verificación de agentes y sostiene que la palanca del arquitecto se muda de inspeccionar la salida a diseñar el proceso para que el defecto sea imposible.

Probar un agente no es demostrar: es muestrear

Darle a cada equipo o a cada tarea su propio agente autónomo se siente como libertad, pero reproduce la dinámica que convirtió a la multinube en la peor práctica. Cuando construir un agente es barato, el costo se muda a ponerlos de acuerdo, y ese costo crece mucho más rápido que la cantidad de agentes. Este ensayo sostiene que la palanca del arquitecto ya no es cuántos agentes tiene, sino el sustrato que comparten: memoria, identidad y un bus común sobre el que coordinarse.

Un agente por equipo es la nueva multinube

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.