Lo que aprendí construyendo 9 proyectos de IA en 12 meses

Hace doce meses tomé la decisión deliberada de profundizar en ingeniería de IA. No solo experimentar con APIs, sino construir sistemas reales, en producción, que manejen datos reales y sirvan a usuarios reales. Nueve proyectos después, quiero compartir las lecciones que ningún tutorial ni curso me enseñó.

Los proyectos

Para dar contexto, esto es lo que construí:

• Un pipeline multiagente de generación de contenido que produjo más de 1000 artículos
• Un sistema de puntuación de señales financieras con 8 factores de calidad
• Un sistema de arte generativo autónomo con lógica espacial
• Una base de conocimiento con RAG para documentación técnica
• Un pipeline de optimización de SEO para YouTube usando Gemini
• Un sistema automatizado de producción de video con ElevenLabs y Suno
• Un motor de puntuación de cumplimiento de marca para agencias de contenido
• Un servidor MCP para integración con Claude Desktop
• Un sistema de automatización de newsletters con resúmenes generados por IA

Lección 1: Empezá por el manejo de errores

Cada proyecto me enseñó lo mismo: escribí el manejo de errores antes que el camino feliz. Los sistemas de IA fallan de maneras creativas e inesperadas. Límites de tasa, filtros de contenido, salidas malformadas, JSON alucinado, cascadas de timeout. Si construís primero el camino feliz y le atornillás el manejo de errores después, vas a pasar más tiempo debuggeando fallas que construyendo funcionalidades.

Mi enfoque actual: construyo primero la lógica de reintentos, las cadenas de fallback y las dead letter queues, y después completo la lógica de negocio real. Se siente al revés, pero produce sistemas consistentemente más confiables.

Lección 2: La gestión de costos es una preocupación de primera clase

Mi segundo proyecto acumuló 400 dólares en costos de API durante una sola sesión de debugging porque me olvidé de implementar el seguimiento de costos. Después de eso, todo proyecto recibe una capa de monitoreo de costos desde el día uno.

Prácticas específicas que me ahorraron dinero:

• Usar el modelo más barato que cumpla con los requisitos de calidad. GPT-4o-mini maneja el 70% de las tareas que la gente reflexivamente enruta a GPT-4o.
• Cachear todo. Prompts idénticos con inputs idénticos nunca deberían llamar a la API dos veces.
• Poner límites duros de gasto por proyecto, por día y por usuario.
• Registrar cada llamada a la API con su cantidad de tokens y su costo. No podés optimizar lo que no medís.

Lección 3: Los prompts son código, tratalos como tal

En mis primeros proyectos, los prompts eran strings embebidos dispersos por todo el código. Eso fue una pesadilla de mantenimiento. Ahora trato los prompts como artefactos de código de primera clase:

• Guardados en archivos dedicados con control de versiones
• Testeados con suites de evaluación que miden la calidad del output
• Parametrizados con nombres de variables claros
• Revisados en code review igual que cualquier otro cambio de código

Un solo cambio de palabra en un prompt puede alterar drásticamente el comportamiento del sistema. Tratá los cambios de prompt con el mismo rigor que los cambios de código.

Lección 4: Multiagente no siempre es mejor

Después de construir el pipeline de contenido multiagente, traté de aplicar el patrón a todo. A veces una cadena simple de llamadas a funciones es mejor que un sistema multiagente. El overhead de comunicación entre agentes, gestión de estado y coordinación solo vale la pena cuando realmente tenés tareas especializadas y distintas que se benefician de una optimización independiente.

Mi regla general: si podés describir todo el flujo de trabajo en un solo prompt sin perder calidad, no necesitás agentes.

Lección 5: La evaluación es el problema más difícil

¿Cómo sabés si tu sistema de IA está funcionando bien? Para el sistema financiero, las métricas eran claras: ratio de Sharpe, tasa de aciertos, drawdown. Para la generación de contenido y los sistemas de arte, evaluar es mucho más difícil. “¿Este artículo es bueno?” es una pregunta subjetiva.

Lo que me funcionó:

• Definir dimensiones de calidad específicas y medibles (precisión, legibilidad, cumplimiento de marca)
• Construir rúbricas de puntuación automatizadas que midan cada dimensión de forma independiente
• Calibrar los puntajes automatizados contra el criterio humano
• Monitorear las métricas de calidad a lo largo del tiempo para detectar degradación

Lección 6: La brecha entre prototipo y producción es real

Hacer andar una demo lleva un día. Dejarla lista para producción lleva un mes. Esa brecha se llena con manejo de errores, validación de inputs, límites de tasa, monitoreo, logging, testing, documentación e infraestructura de deploy. Cada proyecto confirmó esta proporción.

Ahora planifico esto explícitamente. Cuando estimo los tiempos de un proyecto, asigno 20% a la lógica central de IA y 80% a todo lo demás.

Lección 7: Construí tus propias herramientas

El proyecto del servidor MCP fue lo más impactante que construí. No porque fuera técnicamente complejo, sino porque multiplicó mi productividad diaria. Todo ingeniero de IA debería invertir tiempo en construir herramientas que automaticen su propio flujo de trabajo. Los retornos compuestos son enormes.

Lección 8: Documentá todo en tiempo real

Escribir estos posts de blog no fue solo marketing de contenidos. Fue documentación forzada. Cada vez que redactaba un proyecto, descubría decisiones de arquitectura cuya razón había olvidado, casos borde que no había considerado, y optimizaciones que quería revisar. Escribir es pensar, y pensar sobre tus sistemas los mejora.

Lección 9: El campo se mueve rápido, pero los fundamentos son estables

Los modelos cambian cada pocos meses. Los fundamentos no. Una buena arquitectura de software, un manejo robusto de errores, testing sistemático, conciencia de costos y código limpio importan tanto en ingeniería de IA como en cualquier otra disciplina. Los ingenieros que van a prosperar no son los que persiguen cada nuevo lanzamiento de modelo, sino los que construyen sistemas confiables sobre bases sólidas.

Qué sigue

Los próximos 12 meses se van a enfocar en una especialización más profunda. Me interesan particularmente los flujos de trabajo agénticos avanzados, los sistemas de IA en tiempo real, y los patrones emergentes alrededor de la arquitectura de aplicaciones nativas de IA. Los cimientos están puestos. Ahora es momento de construir sobre ellos.

Si estás considerando un camino similar hacia la ingeniería de IA, mi consejo es simple: construí cosas. No tutoriales, no cursos, no ejemplos de juguete. Proyectos reales con restricciones reales. Ahí es donde ocurre el aprendizaje.

Adaptación del artículo original de Steve Light, “What I Learned Building 9 AI Projects in 12 Months”, publicado en su blog personal.