El cuello de botella nunca fue el código
(thetypicalset.com)- En .txt, Codex creó en pocas horas la primera versión funcional de un experimento de algoritmos de generación estructurada que llevaban más de un año postergando, pero el cambio clave fue que quedó en evidencia el cuello de botella de la colaboración más que la velocidad individual para programar
- Cuando un agente se encarga de la implementación, lo que frena al equipo deja de ser quien escribe el código y pasa a ser la creación de especificaciones precisas que el agente pueda ejecutar de inmediato, como el roadmap, los criterios de aceptación y los documentos de diseño
- Si baja el costo de escribir código, aumentan los prototipos y herramientas internas que antes no se habrían construido, y como la velocidad que los usuarios pueden absorber sigue siendo la misma, se vuelve más importante la disciplina del enfoque para decidir qué no construir
- Los agentes pueden extraer decisiones implícitas y convenciones de Slack, PRs, issues, commits y documentos de diseño para crear una base de conocimiento, pero no pueden reconstruir por completo el contexto compartido que las personas acumulan directamente
- Es probable que la ventaja en la próxima década no esté en la empresa con el mejor modelo, sino en la que logre mantener una coherencia organizacional alineada con un conjunto cada vez más reducido de decisiones, incluso a escalas de 50, 200 o 2,000 personas
El cuello de botella que cambiaron los agentes de código
- En .txt, un experimento que llevaban más de un año postergando consistía en probar un algoritmo de generación estructurada y alternativas open source, y en verificar no solo si “acepta esta cadena”, sino algo más cercano a “genera la distribución correcta de tokens”
- Este experimento seguía en el roadmap, pero después de explicarle el enfoque a Codex durante unos 30 minutos, se obtuvo en pocas horas una primera versión funcional
- Los agentes de programación ya están cambiando de forma importante la manera en que una persona escribe código, pero es difícil concluir que una mejora en la productividad individual se traduzca de inmediato en un aumento de velocidad para toda la industria del software
- El software con impacto suele construirse en colaboración entre varias personas, y la unidad de análisis más interesante no es la productividad individual sino la colaboración
- El software se parece más al resultado residual que queda después de que las personas negocian qué debe hacer un sistema; el código importa, pero es el residuo de una tarea más difícil
El roadmap se vuelve el límite
- En los equipos donde los agentes se encargan de la implementación, lo que ralentiza el trabajo es crear especificaciones lo bastante precisas como para que el agente pueda tomarlas y ejecutarlas de inmediato
- El roadmap, los criterios de aceptación y “lo que realmente queremos” deben quedar escritos de forma clara en test suites, tickets y documentos de diseño
- Las funcionalidades se implementan muy rápido, y en lugar de que un ingeniero espere a otro, termina esperando la siguiente especificación correctamente redactada
- El cuello de botella se desplaza de quien escribe el código hacia quien decide qué código debe existir, y eso se convierte en un problema de gestión
Un código más barato exige más consenso
- Si baja el costo de escribir código, el resultado no es hacer el mismo trabajo con solo el 10% del esfuerzo, sino dedicar el mismo esfuerzo a resultados que antes no valía la pena perseguir
- Prototipos que hace tres meses se habrían considerado “una pérdida de tiempo” ahora pueden construirse en una sola tarde, y herramientas internas sin una demanda clara pueden crearse y luego quedar olvidadas
- La velocidad de funcionalidades que los usuarios pueden absorber se mantiene más o menos igual, ya sea que el equipo publique 10 o 50
- Como dijo Steve Jobs en 1997, “enfocarse es decir que no”, y Apple recortó cerca del 70% de su línea de productos ese año
- Con agentes, la sensación de lanzar nuevas funcionalidades se vuelve más fácil, así que la disciplina para decidir no solo qué construir, sino también qué no construir, se vuelve más difícil
El contexto se vuelve el recurso clave
- La negociación y el consenso operan sobre un contexto compartido dentro de la organización
- Ese contexto incluye qué se está construyendo, por qué importa, qué se ha intentado, quién decidió qué, y qué es esencial y qué es solo un rastro residual
- Las personas del equipo acumulan ese contexto de forma natural al estar en la misma sala, leer los mismos canales de Slack y depurar la misma caída a las 2 de la mañana
- Gran parte de ese contexto no se documenta, y cuando un ingeniero senior dice en una revisión de PR “esto va a romper la migración”, muchas veces está usando contexto no documentado
- Los agentes no pueden absorber ese contexto por ósmosis, ni obtenerlo por estar en la sala, escuchar a medias una conversación de planificación o conservar el recuerdo de un incidente pasado
- El contexto que no queda dentro del prompt, el árbol de archivos, las herramientas o las instrucciones explícitas no está disponible de forma confiable para el agente
- Sin contexto, un agente puede producir una respuesta plausible para una pregunta ligeramente equivocada
- Incluso cuando un agente hizo trabajo útil en .txt, en realidad fue porque una persona ya había hecho el trabajo de contexto, y eso no significa que los siguientes 10 ingenieros vayan a tener automáticamente esa misma visión
- El contexto del que las organizaciones siempre han dependido de forma implícita ahora se convirtió en un insumo que limita la velocidad, y las personas tienden a dejarlo implícito porque nunca hubo algo explícito para que alguien lo leyera
El ciclo en el que los agentes producen contexto
- Crear contexto que las personas puedan consumir fácilmente es un trabajo que a la gente no le gusta hacer
- Los agentes son buenos para leer sin omitir nada los comentarios de PR, issues cerrados, mensajes de commit, documentos de diseño antiguos y archivos de Slack, y extraer patrones que nadie documentó
- En .txt, comenzaron a construir un agente que rastrea el codebase, los issues, los PRs y los hilos para convertir decisiones implícitas, convenciones y el “por qué se hizo así” en una base de conocimiento
- Esa base de conocimiento no solo contiene “este módulo existe”, sino también contexto como “este módulo es extraño porque la migración debe preservar el comportamiento anterior” o “este benchmark es importante porque una optimización previa alteró silenciosamente la distribución”
- Otros agentes usan esa base de conocimiento cuando tienen que actuar sobre el codebase
- La ósmosis que antes realizaban las personas de manera informal se externaliza en una forma que tanto agentes como personas pueden leer
- Los agentes que consumen contexto necesitan agentes que produzcan contexto, y cuando ese ciclo funciona, la organización obtiene una base documentada que no habría creado por sí sola
- Aun así, lo que produce ese ciclo siempre es una imagen parcial
- Como dijo Michael Polanyi, “sabemos más de lo que podemos decir”, y parte del contexto esencial existe precisamente porque nunca fue escrito, y puede cambiar en el momento en que se escribe
- La capa de ósmosis que las personas construyen al interactuar directamente no puede reconstruirse por completo solo con subproductos documentados
- El resultado se parece más a un punto de partida útil que a una reconstrucción completa, y sigue siendo una pregunta experimental si eso basta para generar un efecto acumulativo
El nuevo foso está en la organización, no en la tecnología
- Es probable que los ganadores de la próxima década no sean necesariamente las empresas con el mejor modelo o la mejor infraestructura de agentes, sino las que logren producir más por persona mientras crecen a 50, 200 o 2,000 personas y se mantienen alineadas con un conjunto cada vez más reducido de decisiones
- Esas empresas son organizaciones que ya sabían, incluso antes de la llegada de los agentes, que su problema más difícil era la coherencia
- Esto es un problema de cultura y de gestión, y siempre lo ha sido
- Las herramientas de generaciones anteriores como IDEs, control de versiones, CI, microservicios y DevOps prometieron resolver la coordinación con mejores herramientas, pero en la práctica amplificaron la coherencia organizacional que ya existía
- Los equipos pequeños obtienen coherencia casi gratis, por lo que ese efecto de amplificación suele ser positivo, y esa es también una razón por la que muchas de las voces más favorables a los agentes vienen de equipos pequeños: en su contexto, en gran medida tienen razón
- Una vez que se supera cierto tamaño, la coherencia debe construirse y mantenerse, y el efecto de amplificación se vuelve agudo en ambas direcciones
- Las buenas organizaciones mejoran aún más, y las malas se descomponen más rápido
- Los agentes son amplificadores mucho más potentes que las herramientas anteriores, y están sobrevalorados como medio para que un individuo escriba código más rápido, pero subvalorados como medio para externalizar lo que una organización sabe
Los agentes como extensión de la cultura de empresa
- Los agentes pueden sentirse como una extensión del propio pensamiento, y esa sensación es poderosa
- La tarea más difícil es convertir a los agentes en una extensión de la cultura de la empresa
- Para eso se necesita una cultura de escritura, una gestión lo bastante reflexiva como para identificar dónde uno sigue siendo el cuello de botella del contexto, y personas que traten la coherencia como un resultado real que debe mantenerse
- Lo nuevo es que ahora ya se puede construir parte de eso
- El ciclo de leer y extraer es una de esas formas, y podrían surgir otras
1 comentarios
Comentarios de Hacker News
Me parece gracioso que los ingenieros que durante toda su carrera se quejaban de todo lo que interrumpía esas horas de estado de flujo de programación que decían que había que proteger por ser su actividad más esencial y sagrada —reuniones de equipo, rituales ágiles, rastreadores de issues, backlog, Slack, correo, revisiones de diseño— ahora que las máquinas escriben código más rápido que ellos, de pronto y sin pizca de vergüenza se pongan a dar sermones sobre la importancia de la colaboración y lo poca cosa que son el código y programar
No es que esté mal, pero sigue sorprendiendo la hipocresía descarada de quienes hasta hace un año eran, en cualquier equipo, los más antisociales y menos colaborativos
En cualquier caso, ambas cosas pueden ser ciertas al mismo tiempo: escribir código no es el cuello de botella, así que se pueden desarrollar funciones más rápido de lo que se pueden desplegar, y aun así ser interrumpido cuando haces trabajo que requiere concentración profunda sigue siendo molesto y rompe el flujo
https://en.wikipedia.org/wiki/Group_attribution_error
Las reuniones que de verdad aumentan la sincronización entre cliente y programador son raras y valiosas. En las organizaciones grandes, las reuniones ritualizadas aumentan por malas razones. La gente intenta meterse en el proceso entre cliente y programador para hacer notar su presencia
Personalmente me gustan las reuniones con clientes, usuarios finales, diseñadores UX y stakeholders reales. Detesto las reuniones con ocupados políticos de empresa que consumen ancho de banda para ganar influencia interna. No necesito otro gerente intermedio entre mis usuarios y yo
En cambio, en este nuevo mundo donde escribir código se volvió muy rápido y lo difícil pasó a ser entender los requisitos de negocio y técnicos que hay que cumplir, esa misma persona puede priorizar más esos rituales y tolerar interrupciones mientras los agentes de IA escriben el código
Cambiar de opinión cuando cambian los hechos de la situación no es hipocresía
Hay muchas razones por las que, si fueras a hacer un proyecto creativo con alguien fuera de una empresa, no pensarías primero en rituales de Scrum o en Jira. Valorar la colaboración y al mismo tiempo criticar esas cosas es totalmente coherente
El equipo se queja de que tiene demasiado trabajo y no da abasto, así que el gerente me mete al equipo. Y de pronto nadie quiere pasarme nada. Estoy justo en medio de eso ahora mismo
El equipo dice que está “completamente saturado”, pero aun así tiene energía para insistir en que casi cualquier cosa que yo podría hacer es mejor que la hagan ellos y que no necesitan ayuda. A mí me da igual, me puedo quedar sentado cobrando. Pero el olor es el mismo
A: no quieren admitir que son reemplazables y que su trabajo no es tan único, B: no quieren admitir que el cuello de botella no es el proceso ni la carga de trabajo, sino ellos mismos
Los ingenieros veteranos probablemente ya sabían que la verdadera causa de los problemas de velocidad siempre tuvo más que ver con la organización que con la tecnología
La incapacidad del negocio para definir una hoja de ruta productiva y enfocada ha sido un problema histórico de la ingeniería de software. Seguir saltando a la siguiente cosa brillante con casi nada de ROI, mientras se impide atender la deuda técnica sistémica, arruinó a largo plazo varias empresas donde trabajé
Conozco ingenieros junior que usan C++ todo un año y aun así no entienden
std::unique_ptr, y ese tipo de persona siempre es la más lenta de todo el equipoCuando antes escribía evaluaciones de desempeño de ingenieros junior, su rendimiento sí estaba muy determinado por la velocidad, y más o menos se medía por cuántas líneas de código sin bugs podían producir en cierto tiempo. Un buen junior tomaba una funcionalidad bien definida y escribía buen código rápido; uno malo tomaba la misma tarea y la hacía lento, o escribía rápido código lleno de bugs que luego generaba mucho más trabajo de depuración y reescritura
Si entiendes con claridad la justificación de negocio, el alcance, las entradas y la salida deseada, el modelo de datos, el diseño del sistema y el código casi salen solos, o al menos se vuelven mucho más evidentes
— Melvin E. Conway, 1967
Primero habría que preguntarse si entiendes qué son las leyes de escalado tipo Chinchilla y cómo funciona en lo fundamental el aprendizaje por refuerzo con verificación
Sí estoy totalmente de acuerdo en que la limitación fundamental está en si el negocio puede expresarse a sí mismo y a su estrategia de forma consistente
Pero la ventaja actual es que básicamente se puede prototipar gratis. Antes había que ser extremadamente cuidadoso con invertir capacidad de ingeniería; ahora se pueden probar muchas más cosas en la misma restricción de tiempo
Qué funciones y correcciones lanzar, cuándo hacerlo y cómo desarrollar y gestionar el producto completo siempre fue el verdadero reto, y gran parte de esa estrategia depende de ciclos de retroalimentación que la IA no puede fabricar rápidamente
Al mismo tiempo, también siento que muchos líderes del lado del negocio usan la velocidad de ingeniería como chivo expiatorio en vez de asumir responsabilidad por las malas decisiones de su lado
Normalmente el cuello de botella sí es el código, pero no escribir código, sino el código en sí. En mi carrera hubo incontables retrasos causados por aplicaciones lentas
Tengo que usar editores basados en Eclipse que son lentos y se congelan o se caen periódicamente. Las tareas de build tardan 15–20 minutos. También me topo seguido con apps web que tardan una eternidad en hacer algo que debería tomar como máximo 50 ms
La lista podría seguir para siempre. Cada retraso es una interrupción que me destroza la concentración. Ahora estoy en gestión y lidio con decenas de personas y distracciones administrativas, pero igual sigo escribiendo código en la empresa
Si el software es lento, pasa a ser mi prioridad más baja. No me importa a quién afecte. Si realmente fuera importante, no estaríamos todos secuestrados por este jarabe de software lento que nos arrastra hacia abajo
El código es deuda
Puede ser fácil ver el código como un activo, pero en el fondo es deuda. Algunos de los “cuellos de botella” para meter código nuevo existen para asegurar que el valor entregado sea mayor que la deuda aumentada. Agentes que generan más código más rápido también generan más deuda más rápido
Gran parte del entusiasmo y el escepticismo sobre los agentes de programación gira en torno a si el aumento inmediato de productividad —es decir, resultados inmediatos como nuevas funciones, nuevos productos y nuevos ingresos— compensa el aumento de deuda a largo plazo. La respuesta no se sabrá hasta dentro de 1 a 3 años, y variará según el área
Desde esta perspectiva, tiene cierto sentido intentar meter estos cuellos de botella directamente en un flujo de trabajo agentivo. Darle al agente de código contexto adicional que priorice una visión coherente del proyecto y que pueda oponerse a nuevas funciones o a procesos sin restricciones sí tiene valor
¿Es eso lo que el artículo intenta decir? ¿Un intento de hacer que algún agente asuma responsabilidades de gestión de producto, sintetice la mayor cantidad posible en una visión de producto coherente y luego recuerde esa visión al agente de código de la forma más estricta posible?
¿Ese agente debería revisar nuevas propuestas y nuevos pull requests desde la perspectiva de “encaje con el panorama completo”? Llámalo contexto, visión o como quieras
Ese tipo de agente podría ser muy bueno sintetizando contexto y presentando hojas de ruta coherentes que lingüísticamente suenen alineadas con los valores y la visión del equipo. Pero soy escéptico de que pueda tener el criterio de un buen gerente o de un buen equipo. Aprobar una hoja de ruta específica de forma rápida y convincente podría hacer más daño que bien
El mínimo código necesario para resolver una necesidad de negocio sin agregar complejidad extra es un activo con una carga de mantenimiento. Como el tractor de un agricultor: es un activo que requiere mantenimiento y se deprecia si lo dejas abandonado al deterioro digital
El código que existe para crear complejidad innecesaria sí es deuda pura
Sí, pero escribir código siempre te enseña algo
He trabajado tanto en startups del tamaño del fundador como en empresas públicas de decenas de miles de millones, y nunca he visto una especificación de producto, pitch deck o PRD que describa una solución que, implementada tal cual, resolviera el problema. Al construirla de verdad aprendes cómo debe funcionar
El software es un medio complejo e interactivo. Iterar dentro del código con personas que quieren entender y resolver el problema siempre ha sido la única forma de producir algo valioso. Las reuniones y los diagramas ayudan, pero hasta que escribes software funcional no sabes si de verdad tienes algo
“El objetivo era probar nuestro algoritmo de generación estructurada y sus equivalentes open source, reemplazando el ingenuo ‘¿acepta esta cadena?’ por una pregunta más parecida al problema real: ‘¿genera la distribución de tokens correcta?’… El mes pasado le expliqué el método a Codex durante 30 minutos. Unas horas después salió una primera versión funcional. Eso fue todo”
Esto prueba que el cuello de botella sí era el código. Lo que pasa ahora es que la IA fue quien escribió ese código
Quien pensó “el cuello de botella no era el código” ya había discutido el objetivo y lo tenía ordenado coherentemente en la cabeza
Decir que el código es el cuello de botella no necesariamente significa “queríamos esta función pero tomó meses programarla”. También incluye “quisimos esta función durante 2 años, pero la fuimos postergando por la fricción de sentarnos a traducirla a código y gastar de 5 a 10 días en eso”
Si el código no hubiera sido el cuello de botella, simplemente se habrían sentado a escribirlo ellos mismos. Pero no querían invertir el esfuerzo y el tiempo de hacerlo a mano, y sabían que no tomaría tan poco como con un LLM
Incluso cuando la especificación final no está clara, la exploración escribiendo código, verificando, descartando y probando nuevos diseños va más rápido con un LLM. Precisamente porque la parte de “código” se acelera
En otras palabras, el cuello de botella sí era el código
Este mismo texto también parece un texto generado por IA con una instrucción de evitar frases obvias, y por eso sigue siendo aburrido de leer
En el texto dicen “Paradoja de Jevons: cuando algo se vuelve más barato, no usas menos sino más”, pero esa formulación arruina la paradoja de Jevons
Esa frase no es una paradoja, es un efecto totalmente natural. Si algo se abarata, es obvio que su uso aumente
Lo que la paradoja de Jevons realmente describe es una situación en la que el uso de un recurso se vuelve más eficiente y por eso se necesita menos para una tarea dada, pero aun así el uso total de ese recurso aumenta
Pero si el uso de un recurso se vuelve más eficiente, ¿no es natural también que el precio de ese “uso” baje?
Entonces, si aumenta la eficiencia, es natural que aumente el uso. Se le llama paradoja porque algunas personas creen ingenuamente que mejorar la eficiencia es una buena forma de reducir el consumo
Casi todo lo que llaman “paradoja” es así de obvio
O quizá en que, si un proceso se vuelve más efectivo, es decir, toma menos tiempo, terminamos dedicándole más tiempo a ese proceso
¿Cuello de botella para qué? ¿Más funciones?
No creo que la cantidad de software determine el éxito de una empresa. Tampoco creo que capturar más cantidad de contexto sea tan importante
Lo importante es la calidad del contexto. ¿Qué tan bien razonan los humanos?
Luego viene la actitud. ¿Qué tan bien responden los humanos ante situaciones malas?
Después la gestión de recursos. ¿Qué tan bien maneja la empresa a la gente y el dinero?
Y por último la suerte. ¿Cuántos factores fuera de control están a nuestro favor?
Esos son cuellos de botella bastante buenos para una empresa. No parece que los agentes los vayan a resolver pronto
El cuello de botella para mejorar el software que usa un negocio no relacionado con software está en asegurarse de que el software haga todo el trabajo de software que realmente beneficie al negocio
Cosas que ahorran tiempo, hacen a las personas más productivas, reducen errores humanos, vuelven más eficiente al negocio y aumentan los márgenes
Todo eso es bastante difícil de predecir y cuantificar. Puedes empezar con una idea que ayude al negocio, diseñarla, prototiparla y probarla. Al final intentas crear o mejorar una aplicación de software y medir cuánto mejoró el negocio
En todo ese proceso, es difícil asegurar que el software esté atacando el problema correcto de la manera correcta y que al final realmente mejore el negocio. Eso es así sin importar qué tan rápido o fácil se haya vuelto crear software
Aun así, la velocidad sí puede ayudar mucho. Puedes prototipar, probar y mejorar los ciclos de retroalimentación
Con asistentes de programación con IA, cosas que antes se consideraban trabajo de desarrollador junior ahora se implementan con un prompt rápido y un agente corriendo en segundo plano
Ese trabajo de junior ahora lo entregan los asistentes casi sin intervención humana. El backlog se vacía más rápido de lo que entran elementos nuevos. Y como la capacidad de ejecución ya no es el problema, siguen entrando cada vez más elementos nuevos
Ahora el reto es mantenerse al día con el volumen de cambios. Lo vemos directamente en nuestra organización
Que puedas imaginar otros cuellos de botella no significa que generar código no fuera el cuello de botella, o que no lo sea ahora. El concepto mismo de backlog demuestra que sí lo es
“El software es lo que queda después de que un grupo de humanos negocia entre sí qué debería hacer el sistema”
Me gusta esa frase. Sobre todo estoy de acuerdo con lo del contexto. Ahí es justamente donde se recompensa a los equipos experimentados que permanecen juntos a largo plazo
Gestioné equipos así durante décadas. Al final, cuando integraron nuestro departamento, hasta el ingeniero con menos antigüedad ya tenía 10 años
Cuando un equipo lleva tanto tiempo junto, la sobrecarga de comunicación baja a un nivel casi despreciable
Por eso me deprime tanto la cultura actual de permanencias efímeras
Hoy trabajo sobre todo solo. Soy muy productivo, pero el alcance es realmente limitado
Extraño la época en que formaba parte de un buen equipo
¿Qué clase de proyectos hacen como para que lo único difícil sea entender la función que quiere la gerencia, y todo lo demás sea simplemente “teclearlo” o ahora pasárselo a un LLM?
Si eso es lo que hacen, no sorprende que tanta gente en HN crea que los LLM pueden reemplazarlos
Entonces una vez más damos vueltas al mismo círculo, expresamos ansiedad, hablamos unos al lado de otros y 30 minutos después esperamos la siguiente oportunidad de comentar
La mayoría son basura humeante en términos de calidad de código por los ciclos de offshoring y despidos