LLM-First o Code-First? Dónde pertenece la inteligencia en la IA de producción

Cómo decidir qué debe manejar el modelo, qué debe manejar su código y cómo conectar ambos.

Hace unos años, la arquitectura de una aplicación de IA se veía así: enviar una solicitud a un modelo de lenguaje grande -> obtener una respuesta -> mostrársela al usuario. Eso ya no es la historia completa hoy en día. A los modelos se les pide interpretar la intención, recuperar información, elegir herramientas, llamar a APIs, elaborar planes y ejecutar flujos de trabajo de varios pasos.

Ese cambio ha dividido el campo en dos: LLM-First o Code-First

En una arquitectura LLM-first, el modelo está en el centro y decide qué ocurre a continuación. Lee la solicitud, elige una herramienta, decide el orden de las operaciones, verifica los resultados intermedios y cambia de rumbo cuando lo necesita.

En una arquitectura code-first, el software/código sigue a cargo de la secuenciación, las reglas de negocio, la validación, los permisos y la ejecución. El LLM aquí es como un especialista al que el código llama cuando se necesita comprensión o generación de lenguaje.

A la gente le encanta debatir sobre cuál es mejor. Creo que ese es el argumento equivocado. La mejor pregunta es dónde pertenece cada tipo de inteligencia. Los sistemas de producción más robustos que he visto rara vez son puramente uno u otro. Mezclan razonamiento probabilístico con control determinista, y lo hacen deliberadamente.

Por qué LLM-First es tan atractivo

El software tradicional funciona perfectamente cuando puedes detallar los requisitos. Por ejemplo, un usuario elige un producto, ingresa una cantidad y envía un pago. Definis los estados permitidos, las reglas de validación, las condiciones de error y la secuencia de la transacción en código. Listo.

El lenguaje natural no coopera de esa manera. Imagina a un usuario escribiendo: “Encuentra las transacciones que parezcan inusuales, explica lo que ocurrió y dime qué debería investigar primero.”

No hay un camino fijo para esa solicitud. Aquí el sistema debe decidir qué significa “inusual”, determinar qué datos son relevantes, quizá invocar varias herramientas, sopesar la respuesta y redactar una explicación que una persona pueda usar. Ningún equipo de ingenieros/no‑code podrá anticipar cada formulación y cada combinación de peticiones de antemano.

Es donde un LLM desempeña un papel vital, actuando como una capa de razonamiento flexible entre el lenguaje humano y sus servicios deterministas. También es la razón por la que los agentes están recibiendo tanta atención. la guía de arquitectura de IA agente de Google Cloud describe un agente como una aplicación donde un modelo de IA actúa como el motor de razonamiento, mientras que las herramientas le permiten acceder a sistemas y datos externos.

Anthropic’s Building Effective AI Agents guía hace una distinción a la que sigo volviendo. En un flujo de trabajo, los modelos y las herramientas siguen rutas que su código define. En un agente, el LLM dirige su propio proceso y decide cómo usar sus herramientas. La misma guía recomienda comenzar con la arquitectura más simple que resuelva el problema, en lugar de añadir complejidad agente por reflejo. Subrayaría ese consejo dos veces.

Los límites de “Dejar que el modelo decida”

Un modelo puede razonar sobre lo que debería suceder. El razonamiento no es lo mismo que aplicar una regla.

Por ejemplo, tome un flujo de trabajo financiero. Un LLM podría ser excelente para entender “envía la misma cantidad que envié el mes pasado al mismo proveedor”. ¿Pero debería también decidir si la transferencia está autorizada, calcular los límites regulatorios, verificar la titularidad de la cuenta, anular una política de seguridad y ejecutar la transacción?

Probablemente no. Estos trabajos son determinísticos, verificables, auditables y aplicables, y eso es exactamente en lo que el software tradicional sobresale. El riesgo aumenta a medida que los modelos obtienen acceso a herramientas. la guía de seguridad de IA generativa de OWASPseñalaexceso de autonomía como un riesgo significativo: otorgar a un sistema basado en LLM más funcionalidad, permisos o autonomía de la que su tarea necesita. Un resultado extraño o manipulado del modelo es una cosa cuando solo produce texto. Es algo mucho mayor cuando el modelo puede actuar en el mundo real.

Nada de esto significa que los modelos nunca deban tomar acciones. Significa que la autonomía del modelo debe estar limitada por una autoridad determinista.

Code-First sigue siendo importante

Con la IA avanzando tan rápido, es fácil sentir que la ingeniería convencional ha pasado de moda. Yo sostengo lo contrario. La IA hace que los buenos sistemas deterministas sean más importantes, no menos.

El código sigue siendo la elección correcta siempre que una tarea requiera una repetibilidad exacta. La autenticación es el ejemplo más sencillo. Un modelo no debe “razonar” sobre si alguien tiene privilegios de administrador. Su aplicación debe consultar a un sistema de gestión de identidad y acceso autoritativo. Lo mismo ocurre con los cálculos monetarios, las verificaciones de derechos, la validación de datos, las restricciones regulatorias, los límites de transacciones, la validación de esquemas y cualquier cosa irreversible. Estos necesitan contratos explícitos, no conjeturas.

Esto se alinea con un pensamiento de gobernanza más amplio. El NIST AI Risk Management Framework pide a las organizaciones que gestionen el riesgo de IA en el diseño, desarrollo, despliegue y uso. Su compañero Generative AI Profile añade que los sistemas generativos pueden necesitar supervisión adicional, documentación, revisión y controles, según el riesgo involucrado.

Así que me resulta útil dividir cada decisión de diseño en dos preguntas:

¿Qué debería suceder?

y

¿Qué se permite que suceda?

Un LLM a menudo puede ayudar con lo primero. Los sistemas determinísticos deberían normalmente encargarse de lo segundo.

El patrón híbrido: razonar probabilísticamente, ejecutar determinísticamente

Para la mayoría de las aplicaciones empresariales, la respuesta práctica es un híbrido. El LLM funciona como una capa de interpretación y razonamiento. Los servicios determinísticos funcionan como la capa de ejecución y aplicación.

Aquí hay un ejemplo. Supongamos que un asistente de IA ayuda a los desarrolladores a crear entornos temporales de pruebas de API, y un desarrollador escribe: “Dame un sandbox para el flujo de incorporación del cliente.”

El LLM puede interpretar eso, averiguar cuál flujo de trabajo se pretende, leer la documentación y sugerir qué API son probablemente relevantes. Pero la creación real del entorno no debería depender del texto generado libremente. El código puede confirmar que las API solicitadas existen, validar sus contratos, comprobar la autorización, aplicar límites de recursos, generar una configuración aprobada y ejecutar el despliegue.

La división aproximada se ve así:

• El LLM: entender, razonar, clasificar, proponer, resumir.
• El código: validar, autorizar, calcular, persistir, aplicar, ejecutar.

Cada lado hace el trabajo en el que es mejor, y a ninguno se le pide que imite las fortalezas del otro.

Los límites importan más a medida que los agentes se vuelven más poderosos

Esta separación se vuelve más importante a medida que pasamos de asistentes a agentes. Un asistente que da una respuesta incorrecta incomoda a alguien. Un agente con acceso de escritura a producción puede causar un desastre mucho mayor.

La solución no consiste necesariamente en eliminar la autonomía. Consiste en añadir autonomía gradualmente mientras se mantienen los puntos de control explícitos. la guía de Google sobre sistemas multi‑agente recomienda combinar el comportamiento dinámico de IA con controles de seguridad deterministas, observabilidad, autonomía claramente definida y supervisión humana para escenarios críticos de negocio.

La aprobación humana también puede integrarse en el propio flujo de trabajo en lugar de ser una red de seguridad informal. Microsoft’s agent framework documentation, por ejemplo, soporta llamadas a herramientas que se detienen hasta que una persona aprueba explícitamente la operación solicitada.

El principio es simple: cuanto mayores sean las consecuencias de una acción, más fuertes deben ser los controles determinísticos que la rodean.

Cinco preguntas que hacer antes de asignar una tarea a un LLM

Cuando decido si un componente debe ser LLM-first o code-first, reviso lo siguiente:

1. ¿La tarea tiene una respuesta objetivamente correcta? Si es así, inclínate por código determinístico. Los cálculos de impuestos, permisos y validación de esquemas no deberían cambiar porque un modelo los interprete de forma diferente hoy.
2. ¿Implica lenguaje ambiguo o información no estructurada? Si es así, un LLM puede aportar valor real.
3. ¿Qué ocurre si el modelo se equivoca? La arquitectura adecuada para un resumen de reunión es muy diferente de la arquitectura adecuada para iniciar un pago.
4. ¿Puede validarse la salida de forma independiente? Los planes generados por LLM son mucho más seguros cuando reglas determinísticas pueden verificar la acción resultante antes de que se ejecute.
5. ¿Realmente necesita un agente? Si ya conoces los pasos, un flujo de trabajo regular con algunas llamadas específicas al LLM suele ser más simple, más barato, más fácil de probar y más fácil de operar.

Esa última pregunta merece especial atención. Los agentes son poderosos precisamente porque pueden manejar situaciones en las que no puedes predecir cada paso. Pero si puedes predecir los pasos, convertirlos en un problema de razonamiento abierto a menudo añade variabilidad sin añadir inteligencia.

La fiabilidad es una propiedad arquitectónica, no un prompt

Muchos equipos comienzan intentando mejorar la fiabilidad casi exclusivamente mediante la ingeniería de prompts. Los prompts importan, pero no pueden asumir toda la carga.

Un sistema de producción debe asumir que la salida del modelo a veces será incompleta, malformada, inesperada o simplemente incorrecta. El OWASP Top 10 para aplicaciones LLM enumera riesgos como inyección de indicaciones y manejo inadecuado de la salida, lo que refuerza un hábito clave: tratar la salida del modelo como entrada no confiable para los sistemas posteriores, no como instrucciones para ejecutar automáticamente.

Eso cambia la pregunta que haces. En lugar de \”¿Cómo escribo un prompt que siempre haga que el modelo siga la regla?\”, pregunta \”¿Cómo diseño el sistema para que la regla no pueda romperse incluso cuando el modelo cometa un error?\”

Eso es un problema de arquitectura de software, no de prompts. Un prompt puede indicar a un agente que no realice una acción no autorizada. Un servicio de autorización puede detenerlo realmente. Esos dos controles no son equivalentes.

Más allá del debate: sistemas de intención‑primero

Al reflexionar sobre todo esto, he llegado a creer que el debate LLM‑first versus code‑first apunta a una tercera idea: intención‑primero arquitectura.

En un sistema de intención‑primero, la aplicación comienza comprendiendo lo que el usuario intenta lograr. Ahí es donde un LLM es más valioso, porque las personas rara vez son precisas sobre lo que quieren. A partir de ahí, el sistema convierte gradualmente esa ambigüedad en operaciones estructuradas y deterministas.

Una solicitud como \”Ayúdame a resolver el problema de pago del cliente\” podría convertirse en una cadena de procesos: comprender la intención, recuperar la transacción, identificar la razón del fallo, recomendar una solución, solicitar aprobación, ejecutar la operación aprobada.

Algunas de esas etapas se benefician del razonamiento de modelos de lenguaje. Otras deberían ser servicios fijos. La arquitectura no se define por si la IA o el código \”ganan\”. Se define por dónde es aceptable la incertidumbre.

Conclusión

A medida que los modelos mejoren, será tentador darles control sobre partes cada vez más grandes de la pila. A veces esa será la decisión correcta. En otros sistemas, el diseño más sofisticado será aquel que deliberadamente le otorgue al modelo menos autoridad.

La ingeniería de IA en producción, al final, se trata de colocar la inteligencia en el límite correcto. Utiliza modelos de lenguaje donde la interpretación, el razonamiento, la síntesis y la adaptación generan valor. Utiliza software determinista donde la consistencia, la autorización, la precisión y la aplicación son importantes. Luego conecta ambos mediante interfaces estrechas, observables y bien probadas.

El futuro de la IA empresarial probablemente no sea puramente LLM‑first ni puramente code‑first. Es LLM donde la incertidumbre requiere inteligencia, y código donde la certeza requiere control.

Esa distinción puede importar mucho más que el modelo que elijas.