La IA exige más disciplina de ingeniería

La conversación sobre IA en producto suele empezar mal. Alguien dice que el modelo “ya escribe código”, otra persona responde que “ahora todo será más rápido” y, en medio de ese entusiasmo, se toma una mala decisión: bajar la guardia en ingeniería. El resultado no suele ser una demo bonita, sino bugs más caros, cambios difíciles de rastrear y equipos que no saben por qué una respuesta cambió de un día para otro.

La tesis de fondo es simple: la IA no reduce la disciplina de ingeniería, la exige más. Si antes bastaba con revisar una función, ahora también tienes que controlar prompts, herramientas, contexto, límites, evaluación y observabilidad. No estás construyendo solo software; estás construyendo software que conversa con algo probabilístico, variable y, a veces, sorprendentemente frágil.

La falsa idea de que la IA reemplaza el rigor

Durante años, muchas empresas vendieron automatización como sinónimo de menos trabajo técnico. Con IA pasa algo parecido, pero el error es más visible. Cuando un equipo cree que el modelo “se encarga”, empieza a omitir prácticas básicas: pruebas incompletas, logs pobres, revisiones rápidas y despliegues sin criterio de rollback. Eso funciona hasta el primer incidente.

Si trabajas en un equipo pequeño, el riesgo es todavía mayor. En una startup o en un producto digital en Ecuador, México, Colombia o Perú, es común que una sola persona arme el flujo de IA, conecte la API, haga el UI y pase a producción. Eso puede servir para validar una idea, pero no para sostenerla. Cuando el sistema crece, la deuda aparece en forma de respuestas inconsistentes, costos variables y tickets de soporte que nadie sabe explicar.

La razón es técnica, no filosófica. Un modelo de IA no se comporta como una función determinista. Puede cambiar su salida con un prompt apenas distinto, con otro contexto o con una actualización del proveedor. Por eso, si tu proceso de ingeniería sigue siendo el mismo que usabas para una app CRUD tradicional, vas a tener puntos ciegos.

Qué cambia realmente

Cambian al menos cuatro cosas: el input ya no es solo datos estructurados, el output no siempre es predecible, la superficie de fallo se amplía y el costo de equivocarte puede escalar rápido. En una app tradicional, un bug suele afectar una ruta concreta. En una app con IA, un mal prompt o una mala herramienta puede impactar cientos de respuestas antes de que alguien lo note.

También cambia la forma de medir calidad. Ya no basta con que “funcione en mi máquina” o que pase un test unitario. Necesitas saber si el modelo responde bien en casos reales, si alucina menos en ciertos escenarios, si respeta políticas de seguridad y si el tiempo de respuesta sigue dentro de lo aceptable.

La conclusión práctica es incómoda pero útil: la IA no te ahorra disciplina, te obliga a moverla hacia nuevas capas.

Pruebas: ya no alcanza con testear código, tienes que testear comportamiento

Si integras IA en un producto, tus pruebas tienen que cubrir más que lógica de negocio. Tienes que probar prompts, formatos de salida, herramientas externas, recuperación de contexto y regresiones de comportamiento. Si no lo haces, vas a descubrir errores en producción, que es la forma más cara de hacer QA.

Un patrón útil es separar pruebas en tres niveles. Primero, pruebas unitarias para tu código normal. Segundo, pruebas de integración para la llamada al modelo, el parsing y las herramientas. Tercero, pruebas de evaluación para medir calidad de salida con un set fijo de casos. Esta tercera capa suele faltar, y es la que más valor aporta cuando la IA empieza a tocar flujos críticos.

La documentación oficial de OpenAI sobre evaluación de modelos y aplicaciones es un buen punto de partida para entender cómo pensar en calidad de forma repetible: OpenAI Evals. No necesitas copiar su stack, pero sí adoptar la idea de que una aplicación con IA debe medirse con casos de prueba reales, no con intuición.

Cómo se ve una batería de pruebas razonable

Puedes empezar con un set pequeño, pero bien elegido. No hace falta tener 5.000 ejemplos para sacar valor; muchas veces con 50 a 100 casos reales ya encuentras fallos que no viste en desarrollo. Lo clave es que esos casos representen tus flujos más usados y tus errores más costosos.

Una batería mínima podría verse así:

1. 20 casos felices con entradas comunes.
2. 10 casos ambiguos donde el usuario escribe poco o mal.
3. 10 casos de borde con contexto incompleto.
4. 10 casos de seguridad o cumplimiento, por ejemplo PII o instrucciones maliciosas.
5. 10 regresiones históricas, es decir, errores que ya viste antes.

Si tu producto atiende soporte, ventas o onboarding, agrega casos con nombres propios, fechas, montos y jerga local. En LatAm, los usuarios no escriben como en un benchmark limpio. Mezclan abreviaturas, errores ortográficos, referencias a monedas locales y mensajes muy cortos.

Tabla de ejemplo de cobertura

La tabla no es teoría bonita. Sirve para decidir dónde poner tiempo. Si hoy solo tienes capacidad para una cosa, prioriza integración y regresión. Son las pruebas que más rápido te dicen si el sistema sigue siendo confiable.

Observabilidad: si no puedes ver el sistema, no puedes operarlo

Muchos equipos conectan un modelo y luego se quedan sin visibilidad. Ven el error final, pero no el camino. No saben qué prompt se envió, qué contexto entró, qué herramienta falló, cuánto tardó cada paso ni cuánto costó la respuesta. Sin eso, diagnosticar problemas es adivinanza.

La observabilidad en sistemas con IA no es un lujo de empresa grande. Es la diferencia entre corregir un incidente en 20 minutos o pasar dos días revisando logs incompletos. Necesitas trazas, métricas y registros consistentes. También necesitas correlación entre requests, usuarios y versiones del prompt o del modelo.

Si usas un proveedor que documenta tracing y evaluación, léelo. Por ejemplo, la documentación oficial de Anthropic sobre observabilidad y herramientas para Claude puede darte una idea de qué eventos vale la pena registrar: Anthropic docs. No se trata de copiar su producto, sino de entender el tipo de señales que un sistema con IA necesita para operarse bien.

Qué deberías registrar siempre

Como mínimo, registra estos campos por interacción:

• ID de request
• versión del prompt
• modelo usado
• herramientas invocadas
• latencia total y por paso
• costo estimado
• resultado final
• estado de validación o rechazo

Si tu flujo incluye RAG, también registra qué documentos se recuperaron y con qué score. Si usas funciones o tool calling, guarda el nombre de la herramienta, el input enviado y el output recibido. Sin eso, cuando algo falle no sabrás si el problema fue el retrieval, el modelo o tu propio código.

Métricas que sí sirven

Hay métricas que suenan bien pero no ayudan mucho. “Número de prompts enviados” no te dice si tu producto funciona. En cambio, sí te sirven estas:

• tasa de respuestas válidas
• porcentaje de respuestas rechazadas por validación
• latencia p95
• costo por conversación o por tarea
• tasa de fallback a flujo manual
• porcentaje de casos que requieren reintento

Si una métrica sube, debes poder explicar por qué. Por ejemplo, si el costo por conversación sube 30% después de una nueva versión, puede ser porque el prompt creció, porque aumentaste el contexto o porque el modelo empezó a usar más herramientas. Sin observabilidad, no lo sabrás.

Límites: la IA necesita barandas, no confianza ciega

Una de las peores decisiones es dejar que el modelo haga de todo. Eso crea sistemas difíciles de auditar y más caros de mantener. En cambio, cuando defines límites claros, reduces el espacio de error. El modelo no debe decidir todo; debe operar dentro de reglas concretas.

Los límites pueden ser técnicos o de producto. Técnicos: longitud máxima de salida, formatos válidos, tiempo máximo por tarea, herramientas permitidas. De producto: qué puede responder, qué debe escalar a humano, qué datos no puede tocar y qué acciones necesitan confirmación explícita.

Esto aplica especialmente si trabajas con datos sensibles o flujos regulados. Si tu aplicación toca finanzas, salud, recursos humanos o soporte con datos personales, la disciplina no es negociable. No basta con decir que el modelo “entiende contexto”. Tienes que impedir que haga cosas que no debería.

Reglas prácticas para limitar el riesgo

Te conviene aplicar estas reglas desde el inicio:

1. Define un esquema de salida estricto, idealmente JSON validado.
2. Usa validadores antes de aceptar cualquier respuesta.
3. Separa lectura de escritura: el modelo puede sugerir, pero no ejecutar sin confirmación.
4. Añade timeouts y fallbacks claros.
5. Mantén un modo seguro o degradado cuando la IA falle.

Un buen patrón es tratar la salida del modelo como input no confiable. Eso suena duro, pero es sano. Si el output pasa por validación, reduce la probabilidad de que un texto raro rompa tu flujo.

Ejemplo de contrato de salida

{
  "intent": "refund_request",
  "confidence": 0.82,
  "needs_human": false,
  "summary": "El usuario solicita devolución por un cobro duplicado.",
  "actions": ["create_ticket"]
}

Ese tipo de contrato te permite validar campos, bloquear valores extraños y decidir qué hacer si el modelo se sale del formato. Si el modelo devuelve texto libre cuando esperabas JSON, no deberías improvisar. Debes rechazar, reintentar o caer al flujo manual.

Revisión de código: ahora revisas más que sintaxis

La revisión de código en proyectos con IA ya no se trata solo de estilo o complejidad. También tienes que revisar prompts, criterios de evaluación, prompts encadenados, manejo de herramientas y condiciones de fallback. Si el equipo revisa solo la parte visible del código, deja intacta la parte más frágil.

Esto cambia el rol de quien revisa. Ya no basta con preguntar “¿compila?” o “¿está limpio?”. Tienes que preguntar si el prompt está versionado, si el conjunto de pruebas cubre el caso, si el modelo puede devolver una salida inválida y qué pasa cuando el proveedor responde lento o falla.

En equipos chicos, esta revisión puede ser ligera pero no superficial. En equipos grandes, conviene tener una checklist. No porque el proceso sea burocrático, sino porque la IA introduce errores que el ojo humano no detecta si no sabe qué mirar.

Checklist mínima de revisión

• ¿El prompt está en una versión rastreable?
• ¿Hay pruebas para el caso nuevo?
• ¿La salida está validada?
• ¿Hay timeout y retry controlado?
• ¿Existe fallback si el modelo falla?
• ¿Se registran métricas y trazas?
• ¿El cambio afecta costo o latencia?

Si respondes “no sé” a una de esas preguntas, todavía no está listo para producción. Y si tu equipo usa IA para generar código, la revisión debe ser todavía más estricta, porque el código puede verse correcto y aun así esconder supuestos malos.

Cómo usar IA para programar sin bajar el estándar

La IA sí puede ayudarte a escribir más rápido, pero no a pensar por ti. Úsala para explorar alternativas, generar tests, resumir errores o proponer refactors. No la uses como sustituto de revisión, ni como atajo para saltarte diseño.

Un buen flujo es este:

1. Pides una propuesta inicial.
2. La comparas con el comportamiento esperado.
3. Generas pruebas antes o junto con el cambio.
4. Revisas edge cases y fallbacks.
5. Haces merge solo si el sistema completo queda medible.

Ese flujo suena más lento que “copiar y pegar y luego ver”, pero en la práctica ahorra tiempo. Evita regresiones, reduce retrabajo y hace que el equipo aprenda a operar el sistema en vez de perseguir errores.

Cómo se ve una operación madura con IA

Un equipo maduro no pregunta si la IA “funciona”. Pregunta cuánto falla, en qué casos, con qué costo y con qué impacto. Esa mentalidad cambia la conversación de marketing a ingeniería. Y cuando eso pasa, las decisiones mejoran.

La madurez también se nota en el lenguaje. En vez de decir “el modelo se equivocó”, el equipo dice “la validación no atrapó este formato” o “el retrieval trajo contexto irrelevante”. Ese nivel de precisión importa porque convierte un problema difuso en una tarea de ingeniería resoluble.

Si tienes que priorizar, empieza por lo que más reduce incertidumbre: pruebas reproducibles, observabilidad útil, límites explícitos y revisiones que miren el sistema completo. No necesitas una plataforma gigante para eso. Necesitas disciplina, criterio y una cultura que no confunda velocidad con descuido.

Señales de que vas por buen camino

• puedes reproducir un fallo con una request concreta
• sabes qué versión del prompt generó una respuesta
• tienes un set de regresión que corre solo
• puedes medir latencia y costo por caso
• el equipo sabe cuándo escalar a humano

Si todavía no tienes esas señales, no significa que estés atrasado para siempre. Significa que tu siguiente mejora no es otro modelo, sino mejor ingeniería alrededor del modelo.

Tabla resumen

La IA no elimina la necesidad de ingeniería seria. La hace más visible. Si tu producto depende de modelos, tu ventaja no va a venir de prometer magia, sino de construir sistemas que puedas probar, medir y mantener sin improvisar cada semana.