Cuidar los LLMs
Leo un artículo que dice que el código se ha vuelto barato. Lo que antes costaba semanas ahora puede generarse en horas. La documentación impecable, el código bien organizado, los READMEs completos: cualquiera puede producirlos. El valor, dice el autor, está ahora en la capacidad de articular problemas, no en escribir sintaxis.
Estoy de acuerdo, pero creo que se queda corto. El código siempre fue la parte fácil. Las dificultades del software nunca estuvieron principalmente en la escritura.
Lo que ha cambiado
En Dcycle llevamos meses trabajando intensamente con Claude Code y herramientas similares. Los cambios son reales y profundos.
Hemos reducido la barrera con el código. Mucha más gente contribuye. Equipos que antes solo podían pedir cosas ahora pueden resolverlas por sí mismos. La capacidad de respuesta se ha multiplicado. La autonomía ha crecido.
Las capacidades evidentes están ahí: explorar código, corregir bugs, generar documentación, escribir tests. Pero hay también una dimensión menos visible, casi emocional. Sabes que siempre puedes ampliar tu perspectiva. Que hay un diálogo disponible que te enriquece y te empuja a pensar mejor. Eso cambia la forma en que te enfrentas a los problemas.
El embudo se ha movido
Durante décadas, el cuello de botella estuvo en la producción de código. Había pocas personas que sabían escribirlo, y esas personas eran el recurso escaso.
Ese cuello de botella se ha desplazado. Ahora la parte estrecha del embudo está en otro sitio: en las pull requests, en la revisión, en la capacidad de integrar código nuevo con lo que ya existe. Escribir código es más fácil; mezclarlo bien sigue siendo difícil.
Dan Shapiro lo llama deflación técnica: el coste del trabajo técnico está bajando. La deuda técnica ya no pesa igual porque arreglarla será más barato mañana que hoy. Lo que antes era una decisión dolorosa —limpiar código, refactorizar, mejorar arquitectura— ahora tiene un coste decreciente. Pero eso no significa que desaparezca; solo cambia el cálculo.
También hemos visto algo que no esperábamos: los nuevos contribuyentes te obligan a mejorar tus bases. Si quieres que más gente pueda contribuir, necesitas mejores entornos locales, mejor documentación de cómo montar las cosas, mejores formas de probar que el código funciona antes de mezclarlo. Los LLMs no eliminan esa necesidad; la amplifican.
Lo que no ha cambiado
Las dificultades del software siguen siendo las mismas. La información sigue siendo precaria. Los problemas siguen estando mal definidos. La incertidumbre sigue siendo constitutiva, no accidental.
He escrito antes sobre por qué son tan difíciles los productos basados en software. Las cajas negras siguen siendo cajas negras. El software sigue desvaneciendo nuestras aspiraciones de control. Lo que no vemos sigue siendo más que lo que vemos.
Los LLMs son, de hecho, la caja negra llevada al extremo. Nadie puede explicar exactamente qué pasa entre la entrada y la salida. Usarlos bien requiere las mismas habilidades que siempre necesitamos para trabajar con software: representar el espacio del problema, explicitar asunciones, resistir la tentación de certezas prematuras.
Cuidar los LLMs
Hay algo en la expresión "usar los LLMs" que no me gusta. Sugiere extracción, explotación. Prefiero pensar en cuidarlos.
Cuidarlos significa crear las condiciones para que funcionen bien. Alimentarlos con buena documentación. Darles contexto suficiente. Mantener bases de código que puedan entender. Escribir para ellos igual que escribimos para las personas que vendrán después.
Es lo mismo que siempre supimos que debíamos hacer, solo que ahora hay una razón inmediata para hacerlo. Los LLMs te devuelven lo que les das. Si les das desorden, te devuelven desorden. Si les das claridad, multiplican esa claridad.
La misma historia
Internet siempre fue de ir incorporando a más gente a este tipo de capacidades. Todos empezamos así. Unos en Visual Basic, otros en PHP, otros en JavaScript. Cada generación de herramientas bajó la barrera de entrada y permitió que más personas participaran en la construcción.
Los LLMs son continuación de esa historia, no ruptura. Otra vuelta de tuerca en la democratización del software. Más gente podrá contribuir. Más equipos podrán resolver sus propios problemas. El código será más barato.
Pero las preguntas difíciles seguirán siendo difíciles. Qué construir. Para quién. Cómo saber si funciona. Cómo vivir con la incertidumbre de no saberlo del todo.
El código era lo fácil. Siempre lo fue.