He pasado los últimos seis años construyendo infraestructura de IA en producción para Baur Software. No del tipo que ves en los carruseles de LinkedIn con diagramas de Mermaid perfectos. Del tipo que se ejecuta sin supervisión durante la noche, gestiona recursos reales de AWS y no ha borrado nada importante. Todavía.
La brecha entre "funciona en mi máquina" y "confío en esto con acceso a producción" es enorme. La mayoría de las configuraciones de programación con IA viven y mueren en esa brecha. Si estás improvisando, tienes los días contados.
El problema de la excavadora
Esto es algo que no se dice lo suficiente: darle a Claude Code o a cualquier asistente de programación con IA acceso ilimitado a tu infraestructura es arriesgado. Es como entregarle a un adolescente las llaves de una excavadora. Claro, puede que construya algo impresionante. También puede que arrase con el garaje.
El adolescente no es malicioso. Simplemente optimiza para la tarea que tiene delante sin el contexto completo de las consecuencias. Investigaciones recientes muestran que más del 40 % del código generado por IA contiene fallos de seguridad, incluso con la última generación de modelos. ¿Te suena?
Lo aprendí de la forma más cara. Un agente de IA, muy servicial, "limpió archivos sin usar". Resultó que esos archivos eran plantillas de configuración críticas. Técnicamente estaban sin usar porque eran plantillas. El matiz importaba. El agente no tenía el contexto para saberlo.
Lo que hace la mayoría de los desarrolladores (y por qué falla)
Cuando los desarrolladores integran por primera vez herramientas de programación con IA, suelen seguir uno de tres caminos:
Camino 1: Modo YOLO total Conectas Claude Code directamente a todo. Le das acceso de administrador porque gestionar permisos constantemente es molesto. Cruzas los dedos. Esto funciona hasta que deja de funcionar de forma espectacular. Informes recientes documentan cientos de vulnerabilidades generadas por IA que llegan a producción, y organizaciones que descubren dependencias fantasma y fallos de seguridad meses después del despliegue. El radio de impacto siempre es mayor de lo que esperabas.
Camino 2: Blindaje paranoico Restringes todo. Aprobación manual para cada operación. La IA se vuelve inútil porque no puede hacer nada sin que la lleves de la mano. La abandonas después de una semana porque habrías escrito el código más rápido tú mismo.
Camino 3: El término medio (que igual se rompe) Intentas ser razonable. Algunos permisos, algunas barreras de protección, quizá un modo de simulación (dry-run) que olvidas usar. Esto dura más, pero falla de forma más sutil: estado corrupto, casos límite que se pasan por alto y deuda técnica que se acumula porque la IA no entiende tus principios de arquitectura.
Ninguno de estos funciona a largo plazo porque son respuestas tácticas a un problema estratégico.
Qué significa realmente "listo para producción"
Cuando digo "infraestructura de IA lista para producción", no hablo de cumplir con palabras de moda corporativas. Me refiero a una infraestructura donde:
- Puedes dormir tranquilo sabiendo que la IA no hará cambios que requieran reversiones a las 3 de la madrugada
- El costo es predecible y no se dispara porque olvidaste establecer límites
- El contexto está gestionado para que la IA tome decisiones con la información correcta, no con suposiciones alucinadas
- Los fallos son controlados con reversiones automáticas y registros de auditoría claros
- La calidad es medible mediante evaluación continua, no por intuición
Esto no es teórico. Mi infraestructura aws-ai-agent-bus ejecuta agentes de larga duración que orquestan revisión de código, planificación estratégica y enrutamiento de tareas a agentes especializados. Procesa solicitudes de AWS Bedrock con modelos conscientes del contexto que reducen los costos de tokens hasta en un 90 % mediante el almacenamiento en caché de prompts. Y lo más importante: no ha roto la producción en meses.
El recorrido en ocho partes
Durante las próximas ocho semanas, voy a mostrarte exactamente cómo construí esta infraestructura. No la versión maquillada. La versión real, con los errores que cometí y las barreras de protección que ojalá hubiera implementado desde el primer día.
Esto es lo que cubriremos:
Semana 2: Base de AWS Bedrock + Claude Code La capa de infraestructura que hace posible todo lo demás. Por qué Bedrock específicamente (con capacidades de almacenamiento en caché de prompts que pueden reducir costos hasta en un 90 % y latencia hasta en un 85 %), cómo configurarlo correctamente y los compromisos entre costo y contexto que importan.
Semana 3: Integración de la CLI sin el caos Límites de seguridad, roles de IAM y alcance de permisos. Las barreras de protección que permiten que la IA sea productiva sin ser destructiva.
Semana 4: Arquitectura de monorepo para un contexto de IA máximo Cómo estructurar tu base de código para que los asistentes de IA obtengan el contexto que necesitan sin alucinar. Organización de directorios, estrategias con .claudeignore y patrones de localidad del contexto.
Semana 5: Barreras de protección que realmente funcionan Hooks de pre-commit, flujos de aprobación, limitación de tasa y estrategias de reversión automática. Los sistemas de seguridad que te permiten confiar en la automatización.
Semana 6: Optimización de la ventana de contexto Estructura de código para la comprensión de la IA, ubicación de la documentación y cómo hacer que los monorepos jueguen a tu favor en lugar de saturar la ventana de contexto.
Semana 7: Evaluaciones de IA que importan Qué medir (precisión, seguridad, costo, velocidad), cómo configurar una evaluación continua y cómo detectar cuándo el comportamiento de la IA se degrada.
Semana 8: Uniéndolo todo El recorrido completo del sistema, mi flujo de trabajo diario real y la construcción de una funcionalidad de principio a fin que muestra cómo se integra todo.
Por qué esto importa ahora
La ventana para construir una infraestructura de IA adecuada se está cerrando. No porque la tecnología vaya a desaparecer. Porque el costo de no tenerla se acumula.
La encuesta de 2025 de Stack Overflow encontró que el 84 % de los desarrolladores usa herramientas de programación con IA, y el 51 % las usa a diario. Pero los equipos de seguridad informan que la mayoría de las organizaciones ya ha experimentado vulnerabilidades por código generado por IA, y muchas ven cómo estos problemas derivan en incidentes reales.
Cada día que ejecutas herramientas de programación con IA sin las barreras de protección adecuadas es un día en el que acumulas deuda técnica. El código funciona hoy. Quizá funcione mañana. Pero dentro de seis meses, cuando intentes depurar por qué tu agente de IA tomó una decisión, desearás haber tenido el registro de auditoría.
Las decisiones de arquitectura que tomes ahora determinan si podrás adaptarte a nuevos requisitos de seguridad, implementar una observabilidad adecuada o integrar nuevas capacidades de IA sin reescribirlo todo.
No estoy creando esta serie para venderte consultoría (aunque si quieres ayuda para implementar esto en tu empresa, deberíamos hablar). La estoy creando porque necesitaba esta guía hace seis meses y no existía. Así que la creo ahora, con errores y todo.
La próxima semana: la capa de base
El próximo lunes nos sumergiremos en la integración de AWS Bedrock y Claude Code. Te mostraré la arquitectura de aws-ai-agent-bus, explicaré por qué Bedrock específicamente (no es solo marketing) y recorreré la configuración que lleva meses ejecutándose en producción.
La base importa más que cualquier otra decisión que tomes en esta serie. Si te equivocas en esto, todo lo demás estará construido sobre arena.
Nos vemos la próxima semana.
Esta es la Semana 1 de una serie de 8 partes sobre cómo construir infraestructura de desarrollo con IA lista para producción. Si estás implementando herramientas de programación con IA para tu negocio y quieres orientación que no implique que yo te venda algo, acompáñanos cada lunes.
¿Te resultó útil? Cuéntame en los comentarios qué desafíos de infraestructura específicos estás enfrentando. La publicación de la próxima semana incluirá soluciones a las preguntas más comunes.