Noticias

El coste marginal de la corrección

16 de julio de 2026

El coste marginal de la corrección tiende a cero. Tienes que interiorizar lo que esto significa para tu forma de practicar la ingeniería de software. Tienes que obsesionarte con hacer las cosas correctamente.

Un panorama en constante evolución

Antiguamente, un ingeniero podía destacar por su talento técnico puro: un pensamiento algorítmico eficiente, sistemas distribuidos escalables y la revisión minuciosa de los puntos de interrupción del depurador. Esto está dejando de ser cierto a un ritmo cada vez más acelerado. Los agentes permiten que cualquiera pueda escribir código correcto.

La habilidad más importante que debes desarrollar para destacar hoy en día es tener «olfato»: la capacidad de detectar lo que no está bien y la fuerza de voluntad para arreglarlo.

Cómo detectar una API lenta

En Pangram estamos entrenando un nuevo modelo (no creo que esté revelando demasiado al admitirlo): será más grande, más inteligente y también *más rápido* que nuestros modelos anteriores. Ese último superlativo no habría sido posible sin una obsesión por hacer las cosas bien simplemente por el hecho de hacerlo. Porque podemos. Porque nos enorgullecemos de nuestro trabajo. Porque un día estaba probando nuestra API y pensé: «Sin duda debería ser más rápido que esto».

En aquel momento no tenía forma de saber cómo, exactamente, valdría la pena adentrarme en esa madriguera. Solo contaba con la convicción de que debíamos hacer las cosas bien y la confianza en que, con Fable a mi lado, todo era posible.

Salimos airosos apenas un par de días después, tras vencer la latencia que había lastrado mis pruebas internas. Con Fable pude crear un entorno de pruebas totalmente local para nuestro complejo orquestador de API distribuidas. Generamos hipótesis para todos los puntos críticos de nuestro código y probamos soluciones para cada uno de ellos. Encadenamos operaciones complejas de Redis y validamos que se mantuviera el comportamiento. Realizamos simulaciones de diferentes patrones de carga basadas en el tráfico de producción y estimamos la infraestructura necesaria.

Sin los agentes, este habría sido un proyecto insostenible e inviable, que habría requerido semanas o meses de trabajo de ingeniería. En cambio, fue un proyecto paralelo mientras mi entrenamiento se completaba en segundo plano.

Nuestros esfuerzos se vieron recompensados con un aumento de aproximadamente cinco veces en la utilización de la GPU —del 20 % (¡ay!) al 98 %— y un rendimiento equiparable al de nuestros nodos «bare metal». Nos costó muy poco. Y nos lo dio todo. Hizo que alojar nuestro nuevo modelo pasara de ser algo prohibitivamente caro a ser una auténtica ganga.

Cómo agudizar tu olfato

Por desgracia, no existe un «truco fácil» para desarrollar el olfato, pero es una habilidad que se puede desarrollar. Esto es lo que a mí me ha funcionado (creo):

Tener poca tolerancia al dolor

Cualquier cosa que te frustre probablemente también frustre a tus usuarios; no te limites a aguantarte. Tienes que estar en sintonía contigo mismo: fíjate en lo que te provoca una ligera inquietud a lo largo del día, en las partes del código que quizá evites inconscientemente o en las tareas durante las que te pones un poco nervioso. Ahí es donde se pueden conseguir avances. Esto fue lo que me llevó a profundizar en la optimización de la API.

Me gusta decir que «las cosas fáciles deberían ser fáciles». Esto se aplica tanto a tu código (por ejemplo, ejecutar una prueba de ablación sencilla no debería suponer ningún esfuerzo mental) como a tu producto (por ejemplo, una sola llamada a la API debería ser apenas más lenta que la propia pasada hacia adelante). Cuando te encuentres pensando «esto no debería ser tan difícil», ¡arréglalo! ¡Ahora tienes agentes! Crea un árbol de trabajo y ejecuta Codex. /gol Anímate, ¿qué tienes que perder?

Cuestiona todo partiendo de los principios básicos

Los agentes lo hacen muy fácil. «¿Cuánto tiempo debería llevar esta tarea, teniendo en cuenta el tamaño del lote, las especificaciones de la GPU y el número de parámetros?». «¿Cuánto deberíamos gastar en este proveedor, teniendo en cuenta nuestro volumen de datos y de consultas?». Cuando sabes cómo debe ser lo correcto, es mucho más fácil identificar lo que está mal.

Hago esto con todas las topologías de modelo/nodo/forma de solicitud que admitimos; así es como ajusto nuestra configuración de vLLM para asegurarme de que nos acercamos al límite teórico. Así es como supe que había una diferencia entre el rendimiento de nuestra API y lo que obtenemos en un nodo «bare metal».

Este principio también se aplica a tu código. Si alguna abstracción te parece extraña, no te conformes con la respuesta de «siempre ha sido así». Reconsidera el contrato partiendo de los principios básicos: ¿cómo debería ser, teniendo en cuenta lo que sabemos ahora? Tu trabajo consiste en determinar hacia dónde debe orientarse el agente. El agente puede refactorizar y validar la corrección de la noche a la mañana.

Sé curioso, lee mucho

Una de mis optimizaciones favoritas que implementé durante mi primera semana en Pangram se inspiró en el mecanismo híbrido de atención dispersa de DeepSeek V4.

Mi optimización no tenía nada que ver con la arquitectura neuronal, y mucho menos con la atención en concreto. Se trataba de una mejora del algoritmo que utilizamos para detectar los límites entre el texto humano y el generado por IA, que antes requería una segunda pasada de inferencia de duración ilimitada.

Absorbe tantos conceptos interesantes de tantas personas inteligentes como puedas. Tu tarea ahora es tener una curiosidad infinita, establecer conexiones y preguntarte «¿y si…?» Recuerda que el coste marginal de averiguar las cosas tiende a cero.

Utiliza tus fichas

Todos los domingos tengo una costumbre que consiste simplemente en poner Codex en un lugar al azar /gol para intentar usar mis tokens semanales antes de que se reinicien. La mayoría de las veces acabo tirando el código a la basura o este se queda abandonado en un borrador de PR olvidado. A veces sale a cuenta. Casi siempre aprendo algo con el ejercicio. En cualquier caso, no me cuesta nada. Hay quien dice que esto es como jugar a las tragaperras, pero yo digo que no se puede ganar si no se juega.


Ben Glickenhaus
Ben GlickenhausIngeniero de IA en plantilla

Ben trabaja en Pangram en el ámbito que aúna la investigación en IA y la ingeniería. Le interesa entrenar modelos más grandes y más inteligentes, y desplegarlos a gran escala.

Más de Ben Glickenhaus
    El coste marginal de la corrección | Pangram Labs