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

Giving every team or every task its own autonomous agent feels like freedom, but it reproduces the dynamic that made multicloud the worst practice. When building an agent is cheap, the cost moves to making the agents agree, and that cost grows much faster than the number of agents. This essay argues that the architect's lever is no longer how many agents you have, but the substrate they share: memory, identity, and a common bus to coordinate on.

One Agent per Team Is the New Multicloud

When an agent generates the implementation from a specification, the spec becomes the artifact you version, review, and treat as source, and the generated code behaves like the binary a compiler emits. This essay argues that the architect stops reviewing the disassembly and starts reviewing the source, and that the review effort and the governance therefore have to move to the spec, with the guardrail layer as the place where its guarantees get compiled in.

The spec is the source code, the code is the binary

Every degree of autonomy you grant an AI agent is a constraint you remove from it, and architecture, following Gregor Hohpe, is the discipline of satisfying constraints, not of removing them. This essay argues that autonomy works like delegated signing authority: an approval limit set before the transaction, one that grows with a demonstrated track record and lives in the limit itself, not in reviewing every move afterward. The architect job is not to maximize the agent autonomy but to calibrate that limit, because autonomy is granted cheap and clawed back expensive.

Autonomy Is a Blank Check

When an AI agent writes code for almost nothing, each line stops behaving like an asset you invested in and starts behaving like inventory on a shelf: something you have to store, understand, insure and one day throw away. This essay argues that the constraint moves from the factory floor (writing) to the warehouse (maintaining and understanding), and that the architect leverage moves with it, onto the constraints the agent reads: specs, governance rules and guardrails.