- El white paper Coding on Copilot de GitClear analiza, con datos de cambios de código, si el código asistido por IA puede aumentar la productividad a costa de cargar la calidad y la mantenibilidad
- Se espera que el code churn, es decir, código revertido o modificado dentro de las 2 semanas posteriores a su escritura, se duplique en 2024 frente a la línea base previa a la IA de 2021
- Tras la expansión de Copilot, aumentó la proporción de código agregado y código copiado/pegado, mientras que la disminución del código movido sugiere un debilitamiento del refactoring y la reutilización
- Un estudio de GitHub de 2022 concluyó que los usuarios de Copilot terminaban las tareas 55% más rápido, pero GitClear se enfoca en los costos de mantenimiento a largo plazo más que en la productividad
- El análisis de 153 millones de líneas de código modificado escritas entre enero de 2020 y diciembre de 2023 muestra que los líderes técnicos deberían evaluar el impacto de adoptar IA mediante métricas de calidad de código
La naturaleza del código asistido por IA según el white paper de GitClear
- El white paper Coding on Copilot investiga en qué difiere el código asistido por IA, en términos de calidad y mantenibilidad, del código que habría escrito una persona
- La pregunta central es si el código asistido por IA se parece más a la contribución cuidadosamente refinada de un desarrollador senior o al trabajo fragmentado de un contratista de corto plazo
- GitClear es una empresa que vende una herramienta de revisión de código basada en la nube, y este estudio se enfoca en cómo cambia la composición de los cambios de código después del uso de IA
Señales negativas en mantenibilidad
- GitClear encontró tendencias preocupantes desde el punto de vista de la mantenibilidad
- El code churn es la proporción de líneas de código que se revierten o actualizan dentro de las 2 semanas posteriores a su escritura
- Se espera que esta proporción se duplique en 2024 en comparación con la línea base previa a la IA de 2021
- La proporción de código agregado y código copiado/pegado aumentó frente al código modificado, eliminado o movido
- Por estos cambios, se evalúa que el código generado por IA se parece al de un colaborador itinerante que tiende a violar el principio DRY de los repositorios que visita
Tres cambios vinculados con la expansión de Copilot
- GitClear señala churn, código movido y código copiado/pegado como cambios importantes tras la adopción de Copilot
-
Aumento del churn
- Considera que el “uso de Copilot” está fuertemente correlacionado con que se haga push de código erróneo al repositorio
- Esto se vincula con un flujo en el que el código asistido por IA se agrega rápidamente y luego se revierte o modifica en poco tiempo
-
Disminución del código movido
- La disminución del código movido sugiere una reducción del refactoring y la reutilización
- Vista junto con el aumento del código copiado/pegado, se interpreta que la implementación actual de los asistentes de IA no fomenta suficientemente la reutilización de código
- En lugar de crear código DRY mediante refactoring, ofrece la tentación de repetir código existente con una sola pulsación de tecla
-
Aumento del código copiado/pegado
- El código copiado/pegado se considera un factor que impone una gran carga sobre la mantenibilidad a largo plazo
- Cuando se repiten líneas de código que no son palabras clave, se interpreta como una señal de que no hubo tiempo para evaluar implementaciones anteriores
- Si se vuelve a agregar código en vez de reutilizarlo, quienes mantengan el sistema más adelante tendrán que integrar rutas de código paralelas que implementan funcionalidades repetidas
Contraste con los estudios de productividad
- Un estudio de GitHub de 2022 concluyó que los desarrolladores que usaban Copilot completaban las tareas 55% más rápido que quienes no lo usaban
- El mismo estudio también midió efectos positivos, además de la productividad, en la satisfacción de los desarrolladores y la conservación de energía mental
- A diferencia de esos resultados de productividad, el white paper de GitClear analiza principalmente los cambios en la composición de los cambios de código y la mantenibilidad al usar IA
Evaluaciones mixtas en estudios relacionados
- Exploring the Verifiability of Code Generated by GitHub Copilot: encontró evidencia alineada con el consenso de la literatura existente de que Copilot es una herramienta poderosa, pero no debería “pilotear el avión” por sí solo
- Assessing the Quality of GitHub Copilot's Code Generation: según el análisis empírico, Copilot es una herramienta prometedora, pero se necesita una evaluación más integral en el futuro
- Sea Change in Software Development: Economic and Productivity Analysis of the AI-Powered Developer Lifecycle: a medida que aumenta la habilidad para hacer prompts a IA generativa, se forma una conexión única y difícil de separar entre humanos e IA
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot: los efectos heterogéneos observados muestran la posibilidad de que los programadores en pareja basados en IA ayuden a las personas a pasar a carreras de desarrollo de software
- Study of software developers' experience using the Github Copilot Tool in the software development process: las opiniones de los desarrolladores estuvieron divididas; la actitud fue en general positiva, pero no hubo mucha intención de uso real, y la seguridad apareció como una preocupación
Alcance del análisis y preguntas pendientes
- GitClear recopiló y analizó 153 millones de líneas de código modificado escritas entre enero de 2020 y diciembre de 2023
- También plantea el diagnóstico de que, con el rápido aumento de la popularidad de la IA, entramos en una era en la que se agregan líneas de código más rápido que nunca
- La pregunta de 2024 se parece menos a cómo Copilot cambiará el significado de ser desarrollador y más a quién se encargará del trabajo de limpieza posterior
1 comentarios
Opiniones de Hacker News
Lo usé 2 meses y cancelé la suscripción. El costo mental de corregir los errores del aluvión de vómito de código era demasiado alto, y para tareas no triviales o relacionadas con SQL era casi inútil, incluso si primero le pasaba todo el esquema.
Como yo sabía qué quería escribir, me resultaba mucho menos agotador escribirlo directamente, y era más fácil corregir mis propios errores que los del bot. Me preocupan los juniors que van a quedar sepultados bajo esta basura.
Uso ChatGPT en lugar de Copilot y me sorprende todo lo que puede hacer, pero aun así es difícil llamarlo “buen código”. Puedo leer JavaScript, pero en los últimos 14 años me especialicé en iOS y no conozco bien las mejores prácticas del lado del navegador, así que lo uso; y aunque en general obtengo código que funciona, igual veo malas decisiones o cosas raras.
Creo que lo correcto respecto de la IA actual es evitar los dos extremos de “esto ya se terminó” y “no es nada”. A estos últimos les hace falta una analogía del tipo: “es como si un perro hiciera malabares, presentara impuestos y horneara un pastel, y en vez de asombrarte de que pueda hacerlo, te quejaras de que se le caen las pelotas, se equivoca en los números y la receta no es muy buena”.
Copilot es más útil como herramienta de autocompletado que reduce tipeo cuando escribes código predecible basado en contexto. Si escribes una enum class en una ventana, puede autocompletar su uso en otra ventana usando el contexto; y cuando escribes un conjunto de pruebas unitarias, con un Tab te arma el esqueleto del siguiente caso de prueba.
Especialmente en lenguajes dinámicos, Copilot complementa bastante bien a IntelliSense.
Hace unos meses escribí sobre cómo la industria de la actuación de voz parece inevitablemente empujada a ser desplazada por modelos de texto a voz, junto con ejemplos de composición tipográfica, encuadernación y grabado musical: https://news.ycombinator.com/item?id=38491203
Pero si el desarrollo mismo queda vaciado de esta forma, no tengo claro cuál es el estado final. Porque quienes impulsaron los reemplazos del pasado también fueron los desarrolladores. Alguna forma de decadencia y colapso social no me parece del todo descabellada.
“Parsea este JSON y pon esos campos en el lugar correcto de la base de datos” es un caso de uso excelente para escribir SQL con Copilot. Podrías usar un plugin de ORM o middleware, pero para un MVP o un mockup eso es una optimización prematura excesiva.
En cambio, uso con frecuencia la API de ChatGPT y me resulta bastante cómoda. Cuando escribí un SQL update que tocaba millones de filas, le pedí que lo cambiara para dividirlo en lotes y registrar el estado después de cada lote; y cuando Azure DevOps me daba un 401 al acceder a un feed de nuget, me dio no solo la causa, sino también el yaml para corregirlo.
En ambos casos son cosas que podría hacer yo investigando un poco, pero es realmente bueno no tener que gastar ese tiempo de investigación.
GPT-4 aumentó mucho mi eficiencia en el trabajo. Principalmente hago apps PHP CRUD simples para resolver problemas cotidianos de negocio, y como no uso frameworks ni una estructura MVC, el código generado por GPT-4 a partir de instrucciones claras es fácil de entender y normalmente funciona de inmediato.
Por lo general le pido que modifique fragmentos de unas 25 líneas de código para adaptar una función específica de reportes; por ejemplo, si le digo que en esta página agrupe por X y sume Y, responde con precisión. Con una QA y pruebas rápidas, queda listo; en tareas de baja complejidad e instrucciones claras, cambia las reglas del juego.
El proceso se parece a cuando un programador senior descompone una tarea en componentes básicos y se los asigna a un junior. Aquí GPT-4 cumple el rol de un programador junior de 20 dólares al mes, y como me ahorra tiempo, lo pago de buena gana de mi bolsillo.
Pero, igual que cuando de chico preguntaba por qué había que aprender matemáticas si existían las calculadoras, ahora entiendo por qué hay que aprender los fundamentos. Si no conoces lo básico, no puedes usarlo de manera efectiva. Si GPT-4 hubiera existido cuando aprendí PHP, no entendería los fundamentos tan bien como ahora. Me estoy beneficiando de haber aprendido antes de que existiera la herramienta.
Tampoco siento que la calidad del código sea particularmente peor; de hecho, a veces entrega resultados más pulidos.
Creo que buena parte de las críticas son prematuras, y que esto se parece más a un avance tambaleante que todavía necesita más soporte de infraestructura. ¿Dónde está la integración con linters para evitar que produzca resultados que no compilan, y dónde está la función que detecta y corrige automáticamente errores de baja dificultad?
También sigue abierto qué forma deberían tener las pruebas en un entorno de desarrollo con IA generativa y cómo deberían cambiar. Tal vez haya una mejor manera de maximizar los beneficios y reducir los costos de enfoques procedimentales como TDD o BDD.
El último año o dos fue un período en el que un gran cambio tecnológico simplemente se arrojó sobre los flujos de trabajo existentes. Con cualquier herramienta, el resultado surge de combinar la capacidad de la herramienta con la experiencia de quien la usa.
La industria necesita acumular mucha más experiencia y criterio al integrar IA generativa en el desarrollo para poder estimar su valor neto real. Creo que hacen falta al menos 2 o 3 años más, no por la adaptación de la tecnología, sino por el tiempo que tardan las personas en adaptarse.
Ya vi a un equipo de veinteañeros generar montañas de espagueti full-stack encima de un framework CRUD básico que yo había creado. Si puedes generar un “MMO framework” en 60 segundos, disminuye el incentivo para crear una app TODO desde cero.
Es parecido a cuando usé Firebase antes de aprender los fundamentos relacionales hace 12 años, y tardé años en llegar a esos fundamentos.
No se puede ver el futuro con exactitud, pero creo que cambiará la forma en que percibimos la calidad.
Hay un ambiente en el que la tecnología parece que será la salvadora de problemas importantes en todos los ámbitos que nos rodean, como los autos eléctricos, la salud, TI y las finanzas. Al mismo tiempo, cada vez queda más claro que la tecnología se usa principalmente para hacer crecer mercados, gobiernos, países, etc., y que funciona agregando otra capa encima de abstracciones que ya tienen fugas. Da la sensación de que, más que resolver problemas, solo intenta disolver los síntomas.
La calidad incluye lentitud, y creo que esa lentitud se volverá necesaria porque el tratamiento de síntomas tiene límites y los humanos no podremos afrontar los desafíos si seguimos apilando más abstracciones.
Creo que la idea de que debemos volvernos más rápidos es equivocada. Como humanos, no puede surgir calidad de una forma de resolver las cosas que busca beneficios superficiales sin entender los fundamentos del desafío.
LLM es un desastre para nuestro campo. Porque complace el error del humano promedio que quiere llegar a la meta sin hacer el trabajo real. El trabajo real consiste en aplicar supuestos sobre la corrección y entender qué es lo que uno realmente intenta resolver.
Por suerte, no todos intentan ir más rápido; algunas personas están volviendo a aprender los fundamentos, aplicando decisiones cuidadosas y afinando sus ideas y herramientas para crear calidad que resista el paso del tiempo.
Mi experiencia es casi la contraria. En vez de que revisar APIs o librerías desordenadas bloquee la parte difícil, un LLM deja dolorosamente claro cuando mi pensamiento no es sólido en una tarea significativa.
Para hacer algo con un LLM hay que escribir, y para escribir hay que pensar. A menudo, lo más útil es que puedo formular cuidadosamente en palabras lo que quiero hacer, dejar que el LLM me pinche, encontrar y aclarar huecos en mi razonamiento durante el proceso, y luego volver a revisar ese historial de chat.
Es especialmente útil al dar forma a una app en sus primeras etapas, para rastrear lo que en ese momento pensé que debía hacerse y revisarlo más tarde para ver si todavía es así.
Escuchan a profesionales tocar en un club y vuelven a casa intentando imitarlos, pero terminan con un amasijo caótico sin fundamentos. Enfatizaba que uno debe estar satisfecho haciendo cosas simples y construir gradualmente bases más sólidas.
Esa idea aplica casi tal cual al uso de código generado por IA.
Los muebles de IKEA son un buen ejemplo. Si haces un mueble tú mismo, se siente mucho mejor estar cerca de él que de esas cosas como de cartón de IKEA. Pero en la mente de la gente, el costo, la velocidad y la comodidad parecen ser lo más importante.
Un modelo de IA quita esa experiencia inherente y solo entrega la crema del resultado final. Es parecido a ver porno en vez de tener una relación real y llegar al sexo.
Si se usa con inteligencia, algo tipo Copilot ayuda. Se encarga del boilerplate y de las partes tediosas para que la persona pueda concentrarse en el razonamiento pesado.
Además, todavía estamos al principio. Es demasiado pronto para emitir un juicio, y tampoco parece que vaya a desaparecer.
La metodología parece interpretar los cambios como una suposición al comparar la actividad de commits de 2023 con años anteriores, sin saber cuánto de eso tuvo participación de Copilot. Es un enfoque bastante inestable.
Además, dice que “las predicciones para 2024 ejecutaron una regresión cuadrática sobre los datos existentes con el Assistant gpt-4-1106-preview de OpenAI”, y me pregunto si realmente le pidieron a GPT que hiciera una regresión con 4 datos en vez de usar una herramienta simple de regresión como sklearn, R o Excel. Incluso si lo hicieron bien, con solo 4 datos y sumando la primera preocupación, resulta poco convincente.
Decir regresión cuadrática suena convincente, pero con dos puntos de datos básicamente es solo “extender la línea tal cual”. Por eso la predicción de 2024, en esencia, casi no tiene significado.
Soy el autor del estudio original. Me alegra ver que tanta gente se preocupa por la calidad del código a largo plazo. En 2023, el aumento del churned code y de la duplicación, es decir, código copiado y pegado, y la disminución del moved code fueron incluso mayores de lo que esperábamos.
Espero que los equipos de desarrollo y los creadores de AI Assistant adopten métricas e incentivos que fomenten el código reutilizado por encima del código recién agregado. En especial, los equipos bajo gerentes que creen que las LoC deben incluirse en las evaluaciones de desempeño están en riesgo. Según un estudio de GitHub, alrededor de un tercio está en esa situación, y la generación actual de herramientas de asistencia de código hace demasiado fácil presionar Tab y hacer commit, sembrando deuda técnica futura. Como dijo Adam Tornhill en Twitter: “El desafío central de la programación asistida por AI es que se vuelve demasiado fácil generar en masa código que no debería escribirse en primer lugar”.
Dicho esto, la significancia del estudio actual tiene la limitación de que no mide directamente el código escrito por AI. Solo trazamos la correlación entre la calidad del código y la adopción de AI Assistant durante los últimos 4 años. Sería bueno que GitHub u otras empresas de AI Assistant colaboraran en un estudio de seguimiento para medir directamente las diferencias de calidad entre “código sugerido completamente por AI”, “código con sugerencias de AI modificadas por una persona” y “código escrito desde cero”.
En el próximo estudio también quiero medir directamente cómo cambia la frecuencia de bugs según el uso de AI. Si tienen otras ideas que valga la pena medir, propónganlas. Intento publicar un nuevo paper de investigación aproximadamente cada 2 meses.
La reutilización de código puede ser potente dentro de una misma codebase, pero también he visto que, al cruzar entre codebases, genera confusión. Puede ser útil o puede ser inapropiada y confusa, y el resultado depende en gran medida del criterio.
Creo que es mejor evaluar a los desarrolladores por los resultados del software. Por ejemplo, el impacto organizacional en relación con el uso de recursos, errores del servicio que no se deriven de servicios dependientes o de la infraestructura, y cosas por el estilo.
El programador moderno no es alguien responsable solo del código, sino una mezcla deliberada de ingeniero de calidad/tester, gerente técnico de producto, project manager, programador, ingeniero de performance e ingeniero de infraestructura. No quiero desacreditar el estudio en sí; me alegra que haya gente que se preocupe profundamente por la calidad del código, y creo que debemos pensar de otra manera la forma de evaluación.
También me pregunto si controlaron otras posibles explicaciones, como los cambios en la economía tecnológica.
Ese paper hizo benchmarks del desempeño de los LLM más populares en tareas de refactorización de código real, y dice que la AI proporcionó refactorizaciones funcionalmente correctas solo en el 37% de los casos.
La codificación asistida por AI sí es útil en la práctica, pero hay que mantener a humanos experimentados dentro del loop y establecer expectativas realistas más allá de la exageración del marketing.
Mi flujo de trabajo normalmente consiste en revisar la documentación, hacer un prototipo, pulir un poco el código, agregar tests, mover cosas, romperlas, volver a trabajar, estudiar la documentación, refactorizar más, y solo entonces entender el problema lo suficiente como para tirar el 80% del código y rehacerlo bien.
Si Copilot me da código que funciona lo suficiente en la etapa de prototipo y hace que simplemente pase a lo siguiente, no profundizo lo bastante mi comprensión como para estructurar todo correctamente. Me permite saltarme el 90% del flujo de trabajo, pero se paga un precio. Por supuesto, en la etapa final del desarrollo Copilot puede ser muy útil.
Si los resultados del estudio son correctos, no me sorprende. El mal código nace de una comprensión insuficiente, y Copilot no puede tener más comprensión que la que yo le proporciono. Puede escribir código mejor que el programador promedio, pero el resultado no puede ser mejor que la entrada. Con lo mucho que la gente se enfoca en la “ingeniería de prompts”, no entiendo por qué se sorprenden de que un mal “prompt” en VSCode produzca malos resultados.
En mi experiencia, Copilot es excelente para ayudar a arrancar. El código a veces es bueno, a veces mediocre o completamente roto.
Aun así, es valioso porque te ayuda a empezar a pensar. Antes de usarlo, perdía mucho más tiempo. Tal vez sea porque mis circuitos cerebrales son raros.
Soy junior y tengo Codeium instalado en VSCode, pero la mayor parte del tiempo me distrae muchísimo. No entiendo muy bien por qué tanta gente usa este tipo de herramientas de asistencia.
Cosas como Phind sí me resultan útiles. Cuando pasa algo que no entiendo, en alrededor del 60% de los casos me ayuda a entender el problema. Es como encontrar bugs pequeños que no vi porque estaba cansado o distraído.
En cambio, Codeium quizá pueda ser útil para generar boilerplate de frameworks, pero en mi pequeña experiencia con scrapers, pipelines de datos simples y JS+HTML/CSS puro, revisar sus sugerencias es muy molesto. Sobre todo porque muchas veces no funcionan, y aunque sea por algo menor, como que falta un argumento, al final igual tengo que gastar tiempo debuggeando.
Además, en JavaScript hay un estilo común de encadenar métodos y funciones anónimas sin parar, como una cadena infinita, y a mí eso me cuesta muchísimo. Prefiero separar líneas y ponerles nombres a las funciones y variables. Las sugerencias de código también suelen seguir ese estilo; supongo que así son los datos de entrenamiento. Codeium dice que aprende de esto, y a veces de hecho lo hace.
Lo que más me preocupa es cómo se supone que voy a aprender, siendo junior, si le encargo el código a estas herramientas de asistencia. Darle contexto y preguntas a Phind puede ayudarme a aprender, o darme una dirección para buscar por mi cuenta en internet, pero no sé cómo podría aprender solo apretando Tab.
Hace unos días me di cuenta de que mucha gente, incluidos desarrolladores, está usando los LLM no como una herramienta para mejorar, sino como un reemplazo del esfuerzo. Me pregunto si eso no debería dar miedo, no porque las empresas nos vayan a reemplazar, sino también como una cuestión de introspección.
Programar no es la pasión de mi vida, pero me gusta. Porque me permite hacer que pasen cosas y lidiar con la complejidad. Si no entiendo qué está pasando, tampoco puedo construir algo, ni darme cuenta de cuándo la complejidad me está por devorar.
Seguí así; si no cambiás, vas a llegar a un buen lugar. Sin duda estás en el camino correcto.
Lo importante es que, durante mi carrera, escribí tantas especificaciones de API a mano que 1) pude detectar los problemas de inmediato y 2) pude corregirlos sin ayuda adicional. Fue más rápido corregir los modelos a mano que afinar el prompt.
En un área que conocés bien, es impresionante ver cómo hace en 30 segundos algo que te habría llevado toda la mañana. Pero no le pido a la IA que haga cosas que yo no sé hacer. En cambio, converso mucho con la IA sobre lo que estoy haciendo: trade-offs, posibles problemas de seguridad, etc.
Se siente como un ingeniero junior con un doctorado en el lenguaje que uso. No entiende muchas cosas, pero lo que entiende parece entenderlo en profundidad.
A algunos desarrolladores, especialmente los de JS, les encanta el chaining aunque no aporte ningún beneficio salvo mantener todo en una línea. Eso no es un beneficio. Seguí como vas y no dejes que ese modismo tonto te infecte la cabeza.
El momento en que esta tecnología sorprende es cuando se adapta a mi estilo y preferencias. Por ejemplo, pone nombres como yo los quiero y usa correctamente el método que acabo de escribir en lugar de volver a implementarlo.
No lo he probado mucho en proyectos vacíos o pequeños, pero si no estuviera fuertemente sesgado por el contexto alrededor hacia la forma en que ya trabajo, imagino que se sentiría mucho menos ideal.
El mayor uso de las herramientas asistidas por IA fue escribir tests y acelerar cambios repetitivos del tipo “esto mismo, pero un poco distinto”. En IntelliJ + GitHub, incluso cuando un nuevo parámetro debe reflejarse en varios métodos y archivos, si escribo a mano las primeras dos o tres variantes, el resto normalmente se resuelve con enter + tab. El contexto completa lo demás.
Codeium en VSCode parece menos suficiente como IA en sí, y el plugin también parece escrito de una forma en la que las sugerencias y las teclas para aceptarlas estorban con frecuencia. Sigue ayudando en tareas repetitivas, pero menos a la hora de proponer cómo alcanzar un objetivo.
Decidí intentar crear un clon de Yourls basado en Django/Python con ChatGPT. Le indiqué específicamente que permitiera URLs cortas personalizadas y que también rastreara el tráfico, pero no lo tuvo bien en cuenta en la lógica ni en el modelo de datos. Para arreglarlo después tuve que volver a darle instrucciones concretas.
Las herramientas de IA son parecidas a un desarrollador junior que hace el trabajo. Solo que mucho más rápido.
Si no sabés lo que estás haciendo, solo aceleran la velocidad a la que cometés errores.
Hace poco necesitaba agregar prefijos con el nombre de la tabla a los alias de columnas en una consulta SELECT, y como no existía una función para eso, le pasé a ChatGPT la definición del esquema y la consulta, y le pedí que escribiera una lista larga de selección de unas 40 columnas.
No encontré una buena forma de automatizarlo en varios RDBMS, y aunque se podía hacer con expresiones regulares u otras manipulaciones de texto, fue agradablemente simple describir el problema y recibir el resultado necesario.
Fuera de eso, uso los LLM como autocompletado. También tienen el efecto de empujarme a poner buenos nombres de funciones, porque con solo esa información el LLM muchas veces puede dar un punto de partida razonable. Es especialmente útil en APIs o lenguajes que no he usado mucho, cuando el problema que tengo delante ya se resolvió miles de veces. Casi dejé de usar StackOverflow.
Por eso compré Copilot y también uso mucho ChatGPT. Los LLM están entre mis cosas favoritas, junto con un buen autocompletado tipo IntelliSense, la generación de especificaciones OpenAPI o de código EF/JPA, migraciones de bases de datos/creación de tablas a partir de modelos ER, contenedores e IDE inteligentes como los de JetBrains.
Las empresas van a querer más código, más rápido, y creo que de ese torbellino saldrá cada vez menos gente que realmente sepa lo que está haciendo.
El paper completo está aquí: https://gitclear-public.s3.us-west-2.amazonaws.com/Coding-on...
Incluso antes de que las herramientas de asistencia de “IA” llegaran al mercado, ya había una reacción contra el código DRY y, lamentablemente, era una tendencia que venía creciendo cuando usaba Twitter entre 2019 y 2022.
Algunos desarrolladores jóvenes tienen una actitud hacia el código muy distinta de la que me enseñaron. Desprecian enormemente a la Gang of Four y los patrones de diseño, y parecen no darse cuenta de que sus frameworks favoritos están llenos justamente de esos patrones. Se burlan de principios como DRY y, especialmente, SOLID.
En lugares como Twitter, cuanto más sarcástico y contrario a la postura opuesta sea el comentario, más interacción genera. Es una tendencia bastante inquietante.
También siento un enorme desprecio por lo que pasa en los codebases corporativos. No está bien crear capas y capas de indirección con clases, diga lo que diga algún gurú de SOLID. Las mejores prácticas, DRY y SOLID se usan simplemente como excusas.
Lo que no soporto es tratar una lista arbitraria de principios surgidos del pensamiento orientado a objetos al estilo Java como si fuera la verdad del modelado de software. También estoy harto de la enésima discusión sobre cómo se supone que debe entenderse SOLID.
La gente no pelea así sobre el teorema CAP, porque no es un conjunto arbitrario de ideas armado para formar un acrónimo bonito.
DRY también puede abusarse, y la reacción es simplemente contra la actitud de tratarlo como si fuera perfecto.
Por ejemplo, el principio importante de DRY no era no repetir código, sino no repetir ideas. Para cualquier concepto de un sistema, idealmente debería haber una única fuente de verdad, y también un solo lugar que entender o cambiar al trabajar con ese concepto.
Por eso, copiar y pegar una cantidad no menor de código en lugar de crear una abstracción significativa suele ser malo. Al mismo tiempo, también es una advertencia de que, en el momento en que repites una idea, generas una deuda continua de tener que mantener sincronizadas distintas representaciones. Esto aplica a migraciones de DB que definen un esquema y clases ORM separadas, a una API de backend y un cliente de frontend, a los valores de formulario y el estado interno en una UI de modo retenido, y a invariantes de modelos de datos expresadas tanto en tipos como en pruebas unitarias.
Quienes se oponen a forzar la unión de ideas distintas solo porque casualmente tienen implementaciones parecidas no están equivocados cuando dicen que eso se convierte en un riesgo de mantenimiento más adelante. Pero están atacando un hombre de paja que no era el punto original de DRY.
Ahora el problema es dónde y cuándo los nuevos desarrolladores aprenden correctamente estos principios. Algunos tienen formación universitaria, pero no todos, y tampoco es que un programa académico de CS tenga que enseñar muchas habilidades prácticas de desarrollo.
Cuando empecé, los seniors daban a los juniors una capacitación real y considerable, pero con la cultura actual de cambios frecuentes de empleo y el ambiente en el que se evita contratar juniors como inversión a largo plazo, eso parece ocurrir mucho menos. Los cursos formales son caros para una persona, aunque para una empresa casi no representen costo, pero en la práctica muy pocas empresas enviarán a sus nuevos desarrolladores.
También hay libros que valen la pena leer, pero no sé si alguien de veintitantos en 2024 querría lidiar voluntariamente con ese formato anticuado de tinta impresa sobre trozos de árboles cortados. Parece que los desarrolladores en crecimiento de hoy aprenden muchas de estas ideas en blogs y YouTube, y allí también hay material excelente, pero el problema siempre es encontrarlo entre basura mal entendida o empaquetada de forma sospechosa.
Así que, cuando aparece una herramienta mágica capaz de generar 12 líneas de código que más o menos funcionan en el lapso de un latido, no sorprende que los desarrolladores jóvenes piensen que ese código es excelente sin conocer casi nada de sus problemas más profundos. Es difícil decir que sea culpa de alguien, pero claramente es un problema, y ojalá supiera qué hacer al respecto.