Ingeniería en la era de los LLM

• Un texto que resume un año y medio de reflexión en Reindeer sobre cómo construir productos y organizaciones de desarrollo en la era de los LLM, partiendo de la idea de que el contexto humano (human context) es el recurso más escaso
• La producción de contenido se disparó, pero la velocidad de consumo humano sigue igual, y esa brecha es el nuevo cuello de botella: hay que cortar el círculo vicioso en el que slop alimenta más slop (slop feeds slop)
• Las decisiones estructurales como el modelado y el diseño de APIs siguen siendo territorio humano, y hace falta alguien que pueda decir "no" a lo que produce el LLM
• No se puede vencer a un LLM solo con code review, así que hace falta construir capas de defensa automáticas y basadas en disciplina como linters, jueces LLM (LLM judges) y PRs pequeños
• La capacidad clave del desarrollador ya no es el conocimiento técnico profundo, sino el cambio de contexto y el tamaño de su propia ventana de contexto; quien se adapta se vuelve superproductivo, y quien no se adapta se convierte en un net negative para el equipo

---

El contexto humano es un recurso escaso

• Una verdad que no ha cambiado en 25 años de industria: el recurso más caro es el contexto humano; las personas, igual que los LLM, tienen una ventana de contexto limitada y una attention mask
• El cambio actual es que ahora cae slop generado por LLM desde todas partes; la proporción entre velocidad de producción y velocidad de consumo humano es el nuevo cuello de botella
• El problema es que el slop alimenta al slop
  • Código comentado de más por LLM, descripciones de PR excesivamente largas, documentación que enumera historial en vez de resultados
  • El siguiente LLM lo lee, llena su contexto de ruido y continúa de la misma forma
• El contenido textual dentro de la organización debe ser comprimido, y contener solo lo que no queda claro a partir del código y su comportamiento

Áreas que no se pueden reemplazar con humanos

• El modelado es trabajo humano
  • Traducir un CUJ (Critical User Journey) al flujo de una API y decidir qué es cada componente, cuáles son sus responsabilidades y dónde están sus límites
  • Como el LLM escupe código rápido, el mal modelado también se propaga rápido, creando dependencias torcidas que luego no se pueden corregir
  • Cuanto más barato se vuelve ejecutar, mayor es el peso de las decisiones humanas sobre la estructura en el valor final
  • El modelado es la verdad real de la organización y debe vivir en un lugar accesible
• Definir APIs requiere una disciplina humana estricta
  • Los LLM tienden a agregar campos que les facilitan una tarea específica, y cada uno de esos campos ensucia la API de forma permanente
  • Una API es un contrato público (public contract), no un scratch pad; hace falta un humano que diga "no"

Defensa a gran escala contra el slop

• No se puede ganarle a los LLM con code review humano; no escala y al final se llega a un estado donde todos aprueban con los ojos cerrados
• Reindeer converge hacia capas de enforcement automático
  • Linters: reglas lógicas absolutas como dependencias prohibidas entre servicios o límites de arquitectura
  • Jueces LLM (LLM judges): cosas difíciles de codificar pero que un modelo puede inspeccionar, por ejemplo contratos implícitos
• Aun así, cuando se toca una API o hay cambios de modelado, sigue siendo obligatorio el review humano real
• A nivel cotidiano, la regla es: "no se lancen slop entre ustedes"
  • PRs pequeños, y stacked PRs si hace falta
  • Hay que resistir la tentación de lanzar un PR de slop de 2,000 líneas y la probabilidad de que el reviewer lo apruebe con los ojos cerrados
  • El PR es la unidad básica de atención; si supera la ventana de contexto de una persona, se aprueba pero no se lee

Padded rooms: áreas donde soltar a los LLM

• Si se tiene esa estructura, se pueden identificar zonas donde el LLM puede correr libremente, los "padded rooms" (cuartos acolchados)
  • Áreas que no afectan el modelado ni tienen dependencias de largo plazo
  • Aunque se genere slop, se pueden reemplazar fácil y no se propagan por toda la base de código
  • Pueden ser la mayor parte del código de la empresa, pero no son load bearing
• Ahí también está la respuesta para la customización de clientes
  • La customización debe vivir 100% dentro de padded rooms
  • En el momento en que se filtra al core, el core se fractura y cada nuevo cliente introduce riesgo
  • Los padded rooms son la infraestructura que permite decirle "sí" rápido al cliente sin pagar el precio en la arquitectura

La inversión económica de la deuda técnica

• Separar entre áreas de carga y áreas padded también cambia la relación con la deuda técnica
• Antes: si durante el desarrollo se descubría un problema de modelado, se pateaba para el yo del futuro; como el costo de reescritura era alto, la deuda se tragaba durante trabajos grandes
• Ahora: el costo de reescritura converge casi a 0
  • La inversión real nunca estuvo en teclear, sino en el modelado
  • Tirar, corregir el modelado y reescribir es barato
  • Posponerlo se vuelve muy caro: cada LLM que pasa por ese código incorrecto lo adopta, slop alimenta slop, y un error de modelado que no se corrige de inmediato se convierte en una deuda varias veces más compleja en poco tiempo

El PM de esta era

• El rol del PM cambia: debe colaborar de cerca con quien modela para asegurar que el CUJ no se rompa al traducirse a APIs y componentes
• Si el PM y quien modela no están sincronizados
  • se obtiene un producto que técnicamente funciona pero no satisface el CUJ, o
  • un CUJ limpio pero imposible de construir de manera razonable
• En Reindeer, los PM construyen directamente el MVP en un repo separado
  • Bajo la premisa de que ese código jamás toca producción
  • Con libertad para moverse rápido junto con el LLM y mostrar cosas al cliente
  • Todo lo que tenga éxito o deba llegar a clientes pasa por el proceso formal de modelado y desarrollo
  • Eso permite levantar demos rápido y validar con clientes antes de invertir en el core: un equilibrio entre la velocidad para probar ideas y la rigurosidad quirúrgica sobre lo que entra al producto

Infraestructura que te libera del loop

• La diferencia entre llevar al agente de la mano y poner varias tareas a correr en paralelo mientras te vas a dormir es una buena reward function
  • Sin eso, el LLM se va de viaje y no sabe volver
  • Con eso, puede juzgar por sí mismo cuándo está cerca y cuándo está lejos
• En desarrollo, una buena reward function se traduce en buenos tests
  • Incluyendo tests E2E para la plataforma
  • Separando al LLM del mal hábito de depender de mocks que no prueban nada
  • Evals para salidas basadas en LLM
  • Jueces LLM con contexto limpio que ejecutan el loop automático de review, para que el juez no caiga en la misma alucinación que el agente que escribió el código
• A nivel organizacional, esa infraestructura debe ser compartida
  • En Reindeer hay un repo central de marketplace de skills dividido por categorías, que incluye todos los skills internos
  • Tiene soporte automático en todos los harnesses como Claude Code, Codex, y también en pi.dev para la gente tan profundamente unhinged como él
  • Un desarrollador nuevo recibe de inmediato todos los skills de la organización, incluidos los que hacen onboarding y setup

El desarrollador del futuro

• La capacidad decisiva del desarrollador en esta era no es el conocimiento profundo, sino el cambio de contexto y el tamaño de su ventana de contexto / attention mask
  • Gana quien puede sostener un contexto grande, moverse entre tareas sin perder foco y gestionar varios agentes en paralelo
  • La profundidad técnica puntual importa menos porque el LLM la rellena
• Otra capacidad adicional es la habilidad de modelar, una buena comprensión de la arquitectura del sistema y criterio para saber qué vigilar en la etapa de diseño
• La razón por la que el nuevo mundo divide a los desarrolladores en dos grupos
  • Quien se adapta se vuelve superproductivo (super-productive)
  • Quien no se adapta no es neutral, sino un lastre neto (net negative) para el equipo
  • El LLM es un multiplicador (multiplier): productividad para quien sabe usarlo, daño a alta velocidad para quien no
  • En términos de recompensa, el salario del segundo tipo de desarrollador se vuelve 0: no habrá trabajo para esa persona
• Se puede hacer muchísimo más con muchísima menos gente, pero crecer será muy difícil y habrá que ser extremadamente selectivos

Sobre el costo de los tokens

• Pregunta recurrente: ¿qué pasa si el costo de los tokens sube entre 5 y 10 veces?
• Con el tiempo, esa preocupación parece poco realista
  • En la IA hay una ley de Moore acelerada y la calidad por dólar sigue subiendo
  • Existen suficientes modelos abiertos como para impedir la formación de un cártel
• La razón por la que los tokens son baratos: si Claudex de pronto se vuelve absurdamente caro, todos se irán a algún Qwen en alguna neocloud