El delicado equilibrio entre principios de diseño y relación entre equipos
Demasiado celo en no repetir código genera dependencias entre equipos. En tiempos de productividad individual, esas dependencias matan tu capacidad de entregar software.
Allá vamos con otra edición de nodos y sinapsis de cara al fin de semana. Es además el finde de los Málaga Tech Games, uno de mis eventos preferidos del año (junto al BiznagaFest). Así que seguro que va a ser un buen finde, aunque nos chispee un poco. Vamos con la nota de hoy.
Unas ideas para profundizar
Google y la transparencia. Google Chrome ha descargado un modelo de 4GB a tu ordenador sin pedirte permiso ni decirte nada. Es el motor de Google Nano. No es nuevo, diferentes versiones de Nano han estado en Chrome desde 2024 (Engadget), pero se ha viralizado ahora. Sin embargo, la falta de transparencia no deja de ser llamativa.
Esta semana hablábamos de la delicada situación del software libre en plena expansión de la IA y la brecha de supervisión. Una idea: donad unos euros a cualquier proyecto de software libre que uséis diariamente. ¿No usas ninguno? Piensa bien, seguro que encuentras alguno. Ayudad a esos programadores a mantener viva esa herramienta que usas y te ayuda, hacedle sentir ese agradecimiento.
Lo barato sale caro, también en agentes de IA. Dos casos:
La clásica de comparar precios y efectividad de modelos. Otro aspecto donde agentes programadores usando Opus 4.7 tienen 95% de fiabilidad en tareas complejas frente a modelos abiertos más baratos que cuestan una quinta parte por cada token (Kimi 2.6, 68% de fiabilidad) pero que requieren muchísima más validación, o consumo extra de tokens si has de solicitar la tarea de nuevo. Al final, con ese 68% de fiabilidad no puedes delegar sin supervisión ninguna tarea. Y por ahí se esfuma la ganga.
La sutil de delegar tareas de compra en agentes que negocien en tu nombre. Un buen post de Antonio Ortiz en Error 500, comentando cómo en negociaciones entre agentes, los mejores modelos son capaces de obtener mejor precio, especialmente si les toca negociar contra agentes que trabajan con modelos más pequeños.
Una rápida sobre anuncios y conflictos de intereses en modelos IA. ¿Y si el modelo no te da la mejor opción porque compra “el anuncio”? Un paper en Arxiv analiza diferentes modelos a los que el investigador pide reservar un vuelo. En una abrumadora mayoría de casos (>80% en el mejor caso) el modelo compra un vuelo patrocinado más caro que el que le has pedido. Algunos modelos ocultan siempre este conflicto de intereses.
Un par de recomendaciones
Eric Evans y Domain-driven Design. Una charla (~1h, Youtube) que vi hace ya unos años. Tiene muchas sobre el tema (su tema) y yo he visto varias pero ésta es en la que lo sentí más inspirado el tema. Y se relaciona con la idea breve de hoy sobre dependencias entre equipos.
Troubled, de Rob Henderson. Este libro no va de tecnología, pero de todo hay que saber un poco. Lo que sí hace este libro es ayudar a entender cómo se difunden las ideas en este mundo en que vivimos, que normalmente permean desde las clases más acomodadas a las menos acomodadas como algo aspiracional (queremos tener los mismos hábitos y gustos percibimos como refinados y las mismas aficiones que esa gente a la que vemos que le va bien). El concepto de creencias de lujo es imprescindible para entender cómo estas esta dinámica favorece a quiene ya tienen una posición más cómoda.
Nota: Estos enlaces ayudan a mantener esta newsletter sin coste adicional para el lector. Gracias por el apoyo.
Una reflexión breve: Sembrando dependencias entre equipos sin darnos cuenta, el caso de la librería compartida
A todos los proyectos grandes les llega el momento de “la librería compartida”.
Cuando tienes muchos equipos trabajando en la misma empresa, es inevitable que haya lógica parecida, si no directamente duplicada, en software que entregan dos equipos distintos, puede que incluso en dos productos distintos.
A los programadores nos encanta optimizar estas cosas. Don’t repeat yourself. “Esto se saca a una librería común y todos contentos”. Así más adelante sólo habrá que actualizar fallos en un sitio. O en tres: primero la librería y luego cada producto que la está usando. Con todo, de entrada es buena idea. No repitas tu código, ya sabes.
Al menos hasta que por la evolución de los diferentes productos uno de los equipos necesita un cambio que el otro no necesita. Ahí de repente nos damos cuenta de que el coste de no repetir código era generar una dependencia entre equipos.
En ese contexto, es habitual que muy rápido escale el tiempo dedicado a meta-trabajo, a gestionar esa dependencia: gobernanza de la librería, estrategia de ramas, de releases de esa librería, backwards compatibility. Un universo de desdichas. Especialmente en tiempos de elevada productividad individual pero organizaciones ineficientes.
El mal menor.
Quizá hasta comencemos a pensar que, en algunos casos, sería mejor no tener la dependencia, evitar el acoplamiento de la lógica de ambos equipos. Aunque eso implique duplicar cierta lógica.
Como product owner o arquitecto muchas veces es lo que tienes que poder valorar: en este caso concreto, ¿es mejor tener algo de código duplicado o generar una dependencia? No hay una respuesta única antes de aceptar el uso de una librería compartida entre equipos, hay que sopesar caso a caso.
Muchos temas. Tendremos que volver a comentar las creencias de lujo cuanto termine un trabajo sobre la ley trans. Una temática en la que te pueden romper -literalmente- las narices.