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

From Yapamatico to the cloud: the story, the certifications verified on Credly, and the technical territories I explore.

About me

My AI-DLC accreditations

AI-DLC (AI-Driven Development Life Cycle) organizes AI-assisted development into traceable phases—from intent through requirements, design, construction, and operation—with an approval gate before each step forward.

AI-DLC: AI executes, people decide

With Kiro the starting point is not a chat, it is a specification: requirements, design, and tasks before any code is generated. Steering captures the repository conventions once, and hooks take care of the repetitive parts.

Kiro: the spec as the unit of work

Agents write a lot of code very quickly, and that makes the decisions we cannot delegate more valuable, not less: the boundaries of the system, the trade-offs we accept, and what we are willing to maintain for years.

What AI does not decide

AI stopped being autocomplete and started doing the work. That does not remove judgement: it changes where judgement is needed. These are the three ideas I work with today.

AI stopped being autocomplete and started executing. I work with AI-DLC, which organizes AI-assisted development into phases with an approval gate before each step, and with Kiro, where the unit of work is the specification rather than the chat. What is not delegated: the system boundaries, the trade-offs, and what we are willing to maintain for years.

Building with AI

Good ideas improve when they are shared. Send me an email, or find me on LinkedIn and GitHub.

Continue the conversation

{exams} active certifications and {micro} micro-credentials. Every badge links to its verification on Credly.

{exams} active certifications. Every badge links to its verification on Credly.

Certifications

A story that starts in two small towns in Falcón, passes through a 286, and is still open.

From Yapamatico to the cloud

Technologies and disciplines that shape my work and the questions I develop on this site.

Areas I explore

The best architectures begin with an honest question.

Andrés Aguilar

The four ideas I think architecture through before choosing a technology, and how AI enters the development life cycle: AI-DLC, Kiro, and what is not delegated.

Principles

Technology changes quickly. Purpose and principles help us decide what deserves to endure.

A useful architecture begins by understanding whom it serves, what problem it changes, and which decision it must enable.

Design from purpose

Enduring systems are rarely born complete. They learn, adapt, and improve without turning every change into an all-or-nothing bet.

Evolve incrementally

Building also means caring for what happens next: security, resilience, observability, and operations people can understand.

Operate responsibly

Cost, complexity, and energy are not final details. They are boundaries that can lead to simpler and better solutions.

Efficiency as a creative constraint

How I think

These are not universal answers. They are ideas I use to think more clearly before choosing a technology.

I write to organize ideas, share what I learn, and leave better questions about architecture, cloud, and technology.

What I write

Your cloud bill does not measure what you consume: it measures how much freedom to walk away you bought, and almost nobody knows the price they paid for it. This article prices that elasticity premium using the pricing ladder of a gym, shows with napkin arithmetic that half of the savings credited to repatriation can be collected without buying a single server, and explains why every published cloud exit belongs to a company with the same flat load.

The cloud is not expensive, it is flexible

Decomposing by volatility never tells you which of the volatilities you find deserves a module, and that is where the money goes. This article prices every encapsulation like an insurance policy: the premium is paid on every future feature, the payout only arrives if the change happens, and the premium is not set by the code you write but by what the encapsulation forbids. With arithmetic, a documented case, and a scale of deductibles so you stop choosing between everything and nothing.

Volatility-based decomposition. Part 2: every module is an insurance policy

Multi-cloud is considered the worst practice in cloud architecture and technology. Although some groups promote it, the argument here is that it compromises efficiency and the ability to innovate. The idea of running workloads across multiple cloud providers or in your own datacenter is hard to achieve in practice. Moreover, multi-cloud does not prevent lock-in to a single provider and offers no guarantee of protection against price changes. In reality, most companies that claim to be multi-cloud have a significant dependency on one primary provider. Consider an active-active approach in a single region before venturing into a multi-cloud strategy.

Multi-cloud, the worst practice

Volatility-based decomposition is fundamental in enterprise architecture for managing complexity and uncertainty. By grouping functions into domains according to synergy or autonomy, you achieve flexibility, agility, and reduced complexity. This facilitates decision-making, reuse, and consistency, and enables a fast, efficient response to the changing demands of the business environment.