-
La paradoja del éxito: a medida que un proyecto crece, termina cargando con el peso de la compatibilidad hacia atrás y de una base de código enorme (The Ship of Theseus). En cambio, un competidor puede entrenar una IA con las especificaciones de la API, la documentación y el código de pruebas del proyecto existente, extraer solo el valor central y crear en un instante una "versión más ligera y moderna".
-
El caso Cloudflare vs Vercel: Cloudflare aprovechó la vasta documentación y el test suite de Next.js que Vercel acumuló durante años para construir, en apenas una semana, un runtime compatible con Next.js, más delgado y basado en Vite. (Actualmente también se aplica en cio.gov, un sitio del gobierno de EE. UU.)
-
El código de pruebas como activo: antes lo importante era el código en sí, pero ahora el "contrato de software (Contract)" y los "casos de prueba" se han vuelto los activos más costosos. Hacerlos públicos equivale a entregar a un competidor un plano de alta precisión con el que puede copiar mi servicio tal cual.
-
La visión de SQLite: SQLite hace público el código, pero mantiene privado su enorme test suite de 92 millones de líneas, equivalente a 590 veces el tamaño del código fuente. Eso se convirtió en el "foso" que les permite sostener el ecosistema open source y, al mismo tiempo, conservar defensas comerciales.
-
Conclusión: en la era de la IA, las empresas de open source comercial enfrentan el momento de decidir entre la "altruismo total (open source)" y la "supervivencia del negocio". Parece probable que, en adelante, muchos proyectos sigan el camino de SQLite, cerrando su código de pruebas y levantando sus propias barreras tecnológicas.
19 comentarios
Desde esta perspectiva, quizá documentos como los ADR (Architecture Decision Records) o los CIR (Change Intent Records) podrían llegar a ser tratados como algo incluso más valioso que el propio código.
Es bastante impresionante. Aunque es un texto corto, se entiende de inmediato. Incluso podría ser que la seguridad del código de pruebas sea más importante que la del código fuente.
A mí me suena a que no hay que olvidarse de las pruebas e2e; me da curiosidad saber qué opinan los demás.
No soy desarrollador en absoluto... pero por lo divertido que es jugar con la IA la pongo a programar un poco, y resulta que generaba y guardaba un montón de código de pruebas que ni siquiera le había pedido; con razón era por algo como esto.
Cuando le pregunté para qué demonios hacía falta eso, me dijo que lo necesita cuando crea código y que no lo borrara.
Oh... sí, creo que tiene razón.
El enfoque de SQLite es realmente impresionante. Mantener privado un paquete de pruebas que equivale a 590 veces el código significa, al final, que el "verdadero valor del software está en la especificación de su funcionamiento".
De hecho, si hoy en día intentas crear un proyecto con herramientas de programación con IA, con solo el README + la documentación de la API + el código de pruebas de un proyecto existente, puedes replicar sus funciones principales con una rapidez sorprendente. Lo he sentido operando directamente 7 proyectos: paradójicamente, mientras mejor están probados, más fáciles son de copiar.
Sin embargo, hay una parte que se pasó por alto en el caso Cloudflare vs Vercel: "copiar" y "operar" son problemas completamente distintos. Para reproducir los casos límite de Next.js, el ecosistema de plugins e incluso la dependencia de la comunidad, el código de pruebas por sí solo no basta. Al final, parece que el foso competitivo es una combinación de código de pruebas + comunidad + know-how operativo.
Como desarrollador solista, estoy operando 7 proyectos, y este artículo me pegó durísimo.
Gracias a las herramientas de coding con IA, la velocidad de desarrollo inicial se volvió absurdamente rápida, pero el código que acumulé rápido sin tests terminó convirtiéndose en un infierno de refactorización. Sobre todo, cuando operas varios servicios al mismo tiempo, en los proyectos sin tests da miedo tocar cualquier funcionalidad porque siempre está el temor de que algo más explote en otro lado.
La metáfora de "tests = foso" es exacta. Un competidor puede copiar el código, pero es difícil que también replique una suite de tests que cubra miles de edge cases. Y esto es aún más cierto porque, aunque la IA genera código bastante bien, crear escenarios de prueba realmente significativos sigue siendo un área donde todavía hace falta el conocimiento de dominio de una persona.
Pero depende del área: hay casos donde el código de pruebas casi no tiene cobertura, así que sí da para pensarlo. También da la impresión de que en ese lado todavía no logran hacer buen código tan bien como en otros campos.
¿Podrías decirme de qué campo se trata? (No lo pregunto para discutir, de verdad es una curiosidad genuina).
El campo en el que trabajo tampoco es así de extremo, pero hago investigación y desarrollo en el área de IA.
Además de los frameworks que se usan comúnmente, a veces el entorno objetivo donde realmente se despliega el modelo es distinto del entorno en el que se entrenó.
También hay casos en los que ciertas operaciones no están soportadas, así que hay que crear operaciones personalizadas para cada plataforma. En esos casos, muchas veces ni siquiera se puede probar directamente en el entorno de desarrollo.
A veces también modelamos directamente el modelo; aunque se puede escribir código de prueba con ciertos datos, según el dataset los valores cambian de forma probabilística, y fenómenos como que los valores exploten en cierto momento son difíciles de cubrir con código de prueba.
Imagino que debe haber bastantes entornos donde probar sea incluso más difícil que en mi caso.
Es solo mi opinión, pero creo que quizá serían campos donde se usan mucho los notebooks, o áreas de IA donde las respuestas salen de forma probabilística... o el lado del cliente en videojuegos, por ejemplo.
Yo también comento mucho esto con la gente de mi entorno, pero al final, como más adelante será difícil revisar todo el código, creo que si no se prueba sí o sí la lógica realmente importante, puede terminar muy mal.
También se agregó al final del texto, y se comentó que
tldrawtambién ejecuta sus pruebas en privado (aunque dicen que era una broma).https://github.com/tldraw/tldraw/issues/8082
Si ven Cómo se prueba SQLite,
SQLite es completamente abierto, pero tiene código de pruebas 590 veces más grande que el código fuente, y eso es totalmente privado.
Tiene 100% de cobertura de ramas, cientos de miles de casos de prueba y ejecuta más de mil millones de pruebas de mutación.
Entré al tema y lo leí, y dicen que "es broma".
Parece que era una prueba de Joke.
Vaya, ya veo. Solo vi la parte de arriba jaja
Creo que la idea central de "las pruebas por encima del código fuente" realmente tiene mucho sentido. Pero no estoy seguro de que funcione una estrategia de abrir solo el código fuente sin abrir también las pruebas. También parece probable que se les dé bien extraer casos de prueba a partir del código fuente...
Lo hiciste mal.
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
Parece que está relacionado con este artículo. Al hacer open source, da la impresión de que ahora también podríamos volvernos más conservadores a la hora de publicar el código de pruebas.