El cofundador de Databricks, Patrick Wendell, explica por qué los costos de codificación con IA crecen exponencialmente y cómo los líderes de ingeniería pueden cambiar la tendencia sin frenar a sus equipos.
por Catherine Brown
En esta conversación, Catherine Brown habla con Patrick sobre lo que sucedió cuando Databricks apostó todo por los agentes de código basados en IA: cómo se dispararon los costos inicialmente a medida que aumentaba el uso, qué logró reducir realmente los costos unitarios hasta en un 90 % y por qué cada organización de ingeniería necesita una capa de control entre sus desarrolladores y sus modelos. Esa capa de control comenzó como una solución interna para la factura de IA de la propia empresa Databricks, y se convirtió en la inspiración para Unity Gateway.
Catherine: Diriges los productos de IA de Databricks y también has sido el principal impulsor interno de la adopción de la IA. ¿Por qué se ha convertido esto en una prioridad tan personal para ti?
Patrick: Porque el rendimiento de la ingeniería es el principal cuello de botella en nuestro negocio. Cada empresa necesita que su equipo de ingeniería avance más rápido, y si puedes ofrecerles algo que mejore significativamente su productividad, eso vale mucho. Los primeros productos de chat eran algo útiles. Pero el ROI cambió realmente hace aproximadamente un año, cuando aparecieron los primeros modelos de generación de código verdaderamente buenos.
Catherine: ¿Cómo sabes si estás obteniendo ganancias de productividad con las herramientas de IA?
Patrick: Rastreamos una serie de métricas de rendimiento: pull requests, funciones lanzadas y líneas de código. Ninguna de ellas es perfecta por sí sola. Veo el I+D como una gran máquina. Introduces recursos, obtienes funciones y código, y puedes medir cuánto más está saliendo. En conjunto, estamos cerca de duplicar el rendimiento con el mismo equipo. Los equipos que reestructuraron sus procesos en torno a la IA están yendo mucho más rápido que eso.
Catherine: Cuando Databricks lanzó por primera vez las herramientas de código con IA, ¿en qué se equivocaron?
Patrick: Es gracioso porque al principio teníamos el problema opuesto. Nadie quería probar las cosas nuevas. Yo andaba insistiendo a la gente. Así que hicimos lo que todos hicieron: eliminar cada barrera, usar el modelo más caro y ofrecer tantos tokens como quisieran. Creo que se hizo con buena intención. Quieres ayudar a la gente a dar el primer paso.
Luego, la gente comenzó a usarlo de verdad y vimos esta curva exponencial de costos. Todas estas herramientas se cobran ahora por consumo, no por usuario, por lo que un solo usuario puede, en principio, gastar una cantidad de dinero sin límite. Pueden ejecutar un pequeño bucle en el modelo más caro e irse a almorzar. Tal vez ese bucle esté haciendo algo realmente valioso, pero tal vez solo esté quemando tokens. Si tus costos crecen exponencialmente y tus ingresos no, en algún momento tienes un problema. Llegamos al punto en que los costos amenazaban con revertir las ganancias de eficiencia, que eran toda la razón por la que hicimos esto.
Fue entonces cuando me involucré mucho a nivel personal. Intercambié impresiones con líderes de otras empresas tecnológicas que sabía que estaban adoptando la IA a gran escala (Coinbase, Uber, Stripe y otras). Colectivamente, muchos de nosotros estábamos aplicando técnicas similares. Hoy en día, en Databricks, nuestro gasto en tokens por persona es prácticamente estable, incluso cuando el uso total y el valor siguen aumentando.
Catherine: El primer instinto de la mayoría de las empresas es un límite de gasto estricto. Ustedes lo intentaron. ¿Qué pasó?
Patrick: Es la primera medida obvia, y realmente deseas contar con ese mecanismo. Pero un bloqueo estricto es una mala experiencia. Cortas a alguien a mitad de una tarea y pierde su concentración, tal vez horas de trabajo. Y las personas que alcanzan el límite suelen ser tus mejores usuarios. Si los bloqueas, algunos simplemente se van a usar una cuenta personal, y ahora ya no puedes monitorear nada.
Por lo tanto, pasamos a una fricción progresiva, y Unity Gateway se encarga de todo ello. Primero, una advertencia; luego, una aprobación; y después, te cambiamos a un modelo más económico para que puedas seguir trabajando. Bloquear realmente a alguien es el último recurso. También enviamos a todos un desglose periódico de su propio gasto con sugerencias sobre dónde ahorrar. Solo eso ya representa un ahorro cercano al 10 %. Conozco una empresa que incluye el modelo y el costo directamente en cada pull request. Así que es básicamente un escarnio público si usas un modelo caro para algo pequeño. Me encanta.
Catherine: Has escrito sobre cuatro palancas para reducir estos costos. ¿Cuál ha tenido el mayor impacto?
Patrick: Nuestra favorita es un poco aburrida: siguen saliendo modelos mejores y más baratos, y simplemente les transfieres el tráfico. Probablemente se lanzan cinco modelos cada semana entre proveedores propietarios y de código abierto. No todos suponen un avance en términos de costos, pero tal vez uno cada una o dos semanas sí lo es. Es una marea ascendente. Obtienes el mismo resultado por menos dinero y nadie tiene que cambiar nada. Sin enrutamientos sofisticados, nada.
Para darte una idea de lo rápido que avanza esto: uno de los modelos económicos recientes equivale aproximadamente a lo que podía hacer un modelo puntero hace unos nueve meses, con cerca del 1 % del costo por tarea. Eso es una reducción de 100 veces en menos de un año. Todavía es algo preliminar, pero es la dirección hacia la que vamos.
El truco está en que realmente tienes que hacer la transición. Si sale un nuevo modelo y nadie en tu empresa lo usa, es como un árbol que cae en el bosque. Así que nos volvimos expertos en evaluar rápidamente nuevos modelos y migrar las cargas de trabajo cuando uno es lo suficientemente bueno. Como todo pasa por Unity Gateway, podemos hacer ese cambio en un solo lugar y los desarrolladores no tienen que cambiar nada. Eso ha sido lo más impactante que hemos hecho, representando un 50 % o más por sí solo. Si añades enrutamiento, visibilidad del gasto y reducción de los costos adicionales de tokens, en algunos casos nuestros costos unitarios se han reducido hasta en un 90 %.
Catherine: Tu equipo evalúa agentes de código con la propia base de código de varios millones de líneas de Databricks. ¿Por qué no confiar simplemente en las evaluaciones comparativas públicas?
Patrick: Las evaluaciones comparativas públicas no te dicen mucho sobre tu propio código. Las tareas terminan filtrándose en los datos de entrenamiento y no se parecen a la base de código de una gran empresa. Por eso creamos las nuestras a partir de pull requests reales en nuestro repositorio, y las evaluamos ejecutando realmente las pruebas. No utilizamos un LLM como juez, porque eso tiende a premiar el sonar bien por encima de ser correcto.
Algunos de los resultados sorprendieron a la gente. Un modelo de código abierto, GLM 5.2, igualó a Opus 4.8 en calidad a un costo aproximadamente un tercio menor por tarea. Un modelo que era 1,7 veces más barato por token costó más por tarea, porque consumió más tokens. Y el entorno o harness, la herramienta de código que rodea al modelo, importó casi tanto como el propio modelo. Mismo modelo, diferente harness, una diferencia de más del doble en el costo. Solo con ajustar nuestro harness y la configuración de almacenamiento en caché nos ahorramos cerca del 50 %.
Catherine: La brecha entre los modelos más baratos y los más caros puede ser de 100 veces. ¿Cómo deberían abordar ese rango los líderes de ingeniería?
Patrick: Míralo como si fueran autos. Tienes el Lamborghini, el Honda y la bicicleta. No necesitas el Lamborghini para cada viaje, y la mayor parte del trabajo de código no requiere el modelo más grande.
Astra fue un buen ejemplo. Lo implementamos para cada ingeniero, unas 3500 personas, y hasta donde sabemos, somos la primera empresa en compartir públicamente un despliegue de este tipo. Era claramente mejor en los problemas difíciles, como el diseño de sistemas. Pero el gasto aumentó aproximadamente un 60 % y no ayudaba de forma evidente en las tareas cotidianas, que los modelos existentes ya manejan bien. Gran parte de eso fue un desperdicio: personas que usaban Astra para cosas para las que deberían haber usado otro modelo. Así que le asignamos su propio presupuesto en Unity Gateway. Úsalo para los problemas difíciles.
A largo plazo, no sé hacia dónde irá esto. Los modelos económicos siguen asumiendo cada vez más el trabajo rutinario, pero la gente también le plantea problemas cada vez más complejos a la IA. Ese es de alguna forma el objetivo. Quieres poder adaptarte en cualquier dirección.
Catherine: Has argumentado que el costo de la IA es un problema de infraestructura, no un problema de adquisiciones. ¿Por qué los presupuestos y las políticas no pueden resolverlo?
Patrick: Los presupuestos ayudan, pero un presupuesto no puede decidir qué modelo debe gestionar una solicitud determinada. Eso es el enrutamiento. Renombrar un componente va a un modelo económico; un problema difícil y abierto va a uno más capaz. Nuestro Smart Router reduce el costo promedio por tarea en más de un 30 % manteniendo aproximadamente la calidad del modelo más caro. También nos permite dejar de pedirles a los usuarios que decidan cuándo usar los modelos más caros... simplemente sucede automáticamente.
Para hacer cualquier parte de esto, necesitas una capa entre tus desarrolladores y los modelos. Creamos la nuestra porque teníamos que hacerlo. Todo el tráfico de nuestras herramientas de código pasa por un solo gateway, ya sea Claude Code, Codex, Cursor o Omnigent, nuestro meta-harness. Eso fue lo que nos permitió ver realmente adónde iba el dinero. Luego nos dimos cuenta de que todos los clientes tenían el mismo problema, así que lo convertimos en producto como Unity Gateway. Miles de clientes lo usan ahora.
Catherine: ¿Terminará el enrutamiento siendo tan competitivo como los propios modelos?
Patrick: Esa es nuestra visión. A medida que los márgenes de los modelos se reducen, determinar qué modelo usar para cada caso se convierte en un terreno muy interesante. Los modelos de enrutamiento tienen que ser diminutos y rápidos. Además, es difícil hacerlo bien. Hay muchos problemas de investigación abiertos en la parte práctica del uso de estos modelos, y creo que hay propiedad intelectual real en lograrlo correctamente.
Catherine: Si pudieras darle un consejo a un CTO que ve cómo crece su factura de IA, ¿cuál sería?
Patrick: Descubre a dónde va ese dinero. La mayoría de las empresas no pueden decirte cuánto están gastando en IA por equipo o por modelo, y mucho menos si está valiendo la pena. Coloca un gateway frente a tus modelos para que todo el tráfico pase por un solo lugar y puedas verlo. Todo lo demás se vuelve más fácil después de eso. Y no bajes el ritmo. Las ganancias de productividad son reales. Pero todo esto se acumula y, si esperas, la factura será mucho mayor de lo que piensas.
El mensaje de Patrick para los líderes de ingeniería es que no hay que elegir entre la productividad de la IA y el control de costes. Las empresas que lo están haciendo bien mantienen un acceso amplio a los mejores modelos, prueban nuevos modelos en su propio código, se migran a otros más baratos tan pronto como son lo suficientemente buenos y ofrecen visibilidad a los desarrolladores en lugar de barreras. Debajo de todo hay una capa de control, un gateway, que hace que el gasto en IA sea algo que se pueda ver y gestionar. En Databricks, esa capa se convirtió en Unity Gateway.
Para obtener más información sobre cómo Databricks gestiona su propio gasto en codificación con IA, lee el blog de Patrick "Managing AI Coding Costs at Scale" y prueba Databricks Unity Gateway.
(Esta entrada del blog ha sido traducida utilizando herramientas basadas en inteligencia artificial) Publicación original
Suscríbete a nuestro blog y recibe las últimas publicaciones directamente en tu bandeja de entrada.