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 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.

Descomposición basada en volatilidad. Parte 2: cada módulo es una póliza

La factura de la nube no mide lo que consumes: mide cuánta libertad de marcharte compraste, y casi nadie sabe a qué precio la compró. Este artículo cotiza esa prima de elasticidad con la escalera de precios de un gimnasio, demuestra con aritmética de servilleta que la mitad del ahorro que se atribuye a la repatriación se cobra sin comprar un servidor, y explica por qué todas las fugas de la nube que se publican son de empresas con la misma carga plana.

La nube no es cara, es flexible

La multinube es considerada la peor práctica en arquitectura de nube y tecnología. Aunque algunos grupos la promueven, se argumenta que compromete la eficiencia y la capacidad de innovación. La idea de ejecutar cargas de trabajo en múltiples proveedores de nube o en un datacenter propio es difícil de lograr en la práctica. Además, la multinube no evita el lock-in a un solo proveedor y no garantiza protección contra cambios de precios. En la realidad, la mayoría de las empresas que dicen ser multinube tienen una dependencia significativa en un proveedor principal. Se sugiere considerar un enfoque activo-activo en una sola región antes de aventurarse en una estrategia multinube.