El libro avanza hacia fuera desde una sola llamada.
Los primeros capítulos construyen los cimientos aburridos: un endpoint, un proveedor, salida estructurada en la que puedas confiar, prompts que viven en el control de versiones y límites sobre lo que todo eso puede costarte. Los capítulos centrales le dan manos al modelo —herramientas, bucles de agente, efectos secundarios y las fronteras de confianza que impiden que un modelo complaciente salga caro. Los últimos capítulos tratan de todo lo que ocurre después de que funcione: probar algo que nunca responde dos veces igual, el rescate determinista cuando el modelo se equivoca, observabilidad, degradación y publicación.
Cada capítulo se apoya en código que hoy está en producción. Cuando un patrón existe porque algo se rompió, el libro dice qué se rompió.
Convenciones
El código sigue las mismas convenciones que el resto de mi trabajo y que el libro anterior: tipado estricto, tipos de retorno explícitos, FormRequests para la validación, Response Wrappers para el JSON, DTOs para datos tipados y el patrón Manager-Facade-Driver en los límites de integración. Los ejemplos apuntan a Laravel 13 y PHP 8.4.
Sobre el vocabulario: «proveedor» es quien ejecuta el modelo, la empresa a la que envías una petición y de la que recibes tokens. «Driver» es tu clase que habla con un proveedor. «Herramienta» es una función que has expuesto al modelo, y «turno» es todo lo que ocurre entre que un usuario pulsa enter y la función vuelve a quedarse callada.
Algunos términos se quedan en inglés a propósito, porque es como se dicen en el oficio: prompt, token, endpoint, job. Traducirlos haría el texto más difícil de leer, no más fácil.
Las APIs de los proveedores cambian más rápido que las de un framework. Cuando este libro muestra la forma de una petición, trata la forma como la lección y los nombres de los campos como una fotografía: consulta la documentación vigente antes de copiarla.
Los cuatro principios
Todo lo que hay aquí se deriva de cuatro ideas. No son opiniones sobre arquitectura. Son lo que queda después de las caídas.
1. Un modelo es una llamada de red poco fiable con disfraz.
Es un endpoint HTTP de terceros, con latencia alta, salida variable, algún que otro 429 y una factura adjunta. Todos tus instintos sobre integrar una pasarela de pago inestable son correctos aquí. Ponle un tiempo de espera. Ponle un tope. Reintenta los fallos que merecen reintento y ninguno más. Da por hecho que falla, y decide ahora qué ve el usuario cuando ocurra.
2. Los prompts son código.
Un prompt determina el comportamiento. Eso lo convierte en código, y el código va en el control de versiones, en revisión y en un despliegue —no en una fila de base de datos que alguien edita un viernes, ni en un fichero de configuración que nadie revisa. Cuando cambia un prompt, cambia el comportamiento, y deberías poder señalar el commit.
3. Pon tope a todo: tokens, reloj, iteraciones, dinero.
Una función de IA sin topes es una factura sin tope. Todo bucle necesita un número máximo de vueltas. Todo job necesita un plazo más corto que su propio tiempo de espera. Todo cliente necesita un techo. Toda respuesta necesita un límite de tokens elegido por ti en el servidor, no insinuado por el cliente. No notarás que falta el tope hasta el mes en que lo notes.
4. El modelo es un llamante en el que no se confía.
Se le puede convencer. Se le convencerá. Cualquier cosa que impongas pidiéndoselo amablemente al modelo no está impuesta. La verificación, la propiedad, las cuotas y los permisos viven en tu base de datos y en tu middleware, detrás de las herramientas —nunca en las instrucciones.