Resumen
- Descripción general del estudio
- Este estudio evalúa el impacto de la IA generativa en la productividad de los desarrolladores de software mediante tres experimentos controlados aleatorizados realizados en Microsoft, Accenture y una empresa anónima de manufactura electrónica de Fortune 100.
- Los experimentos se llevaron a cabo como parte del trabajo diario de cada empresa, y a desarrolladores seleccionados aleatoriamente se les proporcionó GitHub Copilot, un asistente de programación impulsado por IA.
- Este estudio, realizado con un total de 4,867 desarrolladores de software, encontró que la cantidad de tareas completadas por los desarrolladores que usan herramientas de IA aumentó en 26.08% (error estándar: 10.3%).
- En particular, los desarrolladores con menos experiencia mostraron mayores tasas de adopción y mejoras de productividad.
Resumen de GN⁺
- Este estudio muestra que la IA generativa puede mejorar significativamente la productividad de los desarrolladores de software.
- Es especialmente útil para los desarrolladores con menos experiencia, lo que sugiere que las herramientas de IA pueden ayudar a suavizar la curva de aprendizaje.
- Las herramientas de IA como GitHub Copilot pueden desempeñar un papel importante para aumentar la eficiencia del desarrollo de software.
- Otros proyectos con funciones similares incluyen TabNine y Kite.
1 comentarios
Opiniones de Hacker News
A veces me pregunto si la calidad del personal de TI está bajando porque las empresas, para reducir personal, le están metiendo cada vez más roles a una sola persona.
Antes desarrollo, operaciones y seguridad eran roles dedicados por separado, pero cuando surgió DevOps, algunas empresas lo interpretaron no como integración de equipos, sino como que podían arreglárselas con solo 2/3 del personal; y cuando surgió DevSecOps, pensaron que bastaba con 1/3 de los roles originales, y que los desarrolladores podían encargarse también de operaciones y de la seguridad de aplicaciones.
No estoy criticando el shift-left ni el modelo operativo integrado en sí; digo que esta es la consecuencia lógica que producen estos modelos cuando los ejecutivos creen que pueden recibir más bonos si recortan costos reduciendo personal.
Ahora un desarrollador junior entra a un entorno absurdamente complejo de n microservicios y tiene que aprender la base de código existente, cinco pipelines de CI/CD y hasta el rol de DBA, mientras mantiene un ciclo constante de releases.
¿De verdad sorprende que use ChatGPT para ponerse al día? Y esto seguirá pasando hasta que las empresas de TI dejen de reducir personal para “hacer subir la línea” en vez de apostar por buenas estrategias de negocio.
Creo que lo que los MBA no ven es el fenómeno de las restricciones excesivas. Si divides el rol general de “desarrollador” en “desarrollo, operaciones, seguridad”, aparecen todo tipo de detalles sobre cómo debe hacerse cada rol. Aunque luego los vuelvas a unir como DevSecOps, esos detalles siguen ahí, así que una persona no trabaja tres veces más eficientemente: termina cargando con tres veces más trabajo.
Para revertirlo bien, hay que relajar las restricciones y permitir que esa persona decida cómo hacer el trabajo.
La conclusión que se deriva de esto es que el tamaño de una organización no puede reducirse; solo puede crecer. A medida que aumenta la cantidad de empleados, los puestos se vuelven más especializados, y si los eliminas, esa función simplemente deja de realizarse. En ese nivel de especialización, a los empleados restantes les cuesta asumir nuevas responsabilidades con solo cambiar un poco la descripción del puesto.
Al final hay que abandonar la organización vieja y volver a empezar con una nueva y más pequeña; por eso existe el ecosistema de private equity/capital de riesgo/startups. La ley de Gall va en la misma línea: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
En cambio, si miras las startups nuevas que están apareciendo estos días, hay cada vez más gente realmente talentosa. Creo que en un entorno donde el financiamiento está más ajustado, para fundar una empresa se necesita gente de verdad capaz, y esa gente a su vez contrata a personas excelentes.
La industria tecnológica actual se siente mucho más parecida a la época de 2004-2008, cuando casi todos los que estaban interesados en startups se metían porque les gustaba hackear problemas técnicos.
Por mi experiencia usando Cursor, es excelente para lo que puede hacer un ingeniero promedio, pero pésimo para tareas más avanzadas, y además exige la capacidad de entender código ajeno muy rápido.
Probablemente haga que los ingenieros técnicos senior que no se enfocan en frontend o desarrollo de apps web ya no necesiten contratar tantos desarrolladores web junior como antes. Es parecido a cómo desaparecieron los webmasters cuando aparecieron frameworks y herramientas para crear rápidamente HTML/CSS básico para páginas web.
Si decimos que el personal de “DevSecOps” está haciendo tres veces el trabajo que debería, también hay que mirar qué más están haciendo. Puede que reserven viajes, liquiden y reporten gastos, dividan sus horas de trabajo por categorías de negocio para reportarlas, administren vacaciones, gestionen reuniones, armen presentaciones con gráficos hechos por ellos mismos y preparen hasta el 80% de las compras a proveedores externos.
Estas tareas no están en la descripción del puesto, interrumpen el trabajo real y erosionan de forma desproporcionada la capacidad de hacer la función principal. Antes había especialistas dedicados para cada una de estas cosas, que podían resolverlas 10 veces más eficientemente y a mucho menor costo.
Especialistas como secretarias, departamentos internos de diseño gráfico o personal de finanzas aparecían en los estados financieros. Eliminar esos roles no hace que el trabajo desaparezca; solo lo distribuye en pedacitos entre todos, bajo el argumento de que el software de oficina de autoservicio mejora la “productividad”.
El resultado es que todos se vuelven desproporcionadamente más lentos, pero quienes solo miran números ven únicamente el dinero ahorrado en los sueldos de los roles eliminados. La lentitud aparece como una sensación difusa y general de caída de productividad, como una misteriosa enfermedad de costos que afecta a todos.
No tiene nada de misteriosa: creo que no hay aumento de productividad, sino pérdidas. Pero como convierte costos claros y visibles en costos distribuidos y difíciles de calcular, es fácil caer en la ilusión de que se está ahorrando dinero.
La habilidad clave que están pasando por alto es la capacidad de entender el negocio al que pertenece la empresa. Incluso una capacidad de desarrollo moderada, si se combina con una buena comprensión de los objetivos del negocio, puede seguir siendo valiosa mientras algunos desarrolladores puros son reemplazados por IA.
En 13 años en una empresa del sector bancario, vi cómo la complejidad aumentaba muchísimo y cómo también crecía una burocracia absurda. Todavía se puede hacer el trabajo necesario, pero no tengo los accesos. Tampoco puedo tenerlos.
Una tarea simple ahora se convirtió en negociar diez pasos con un equipo desconocido de Pune, y hay que perseguirlos y escalar el tema diez veces hasta que reconozcan que efectivamente tienen algo que hacer.
Los procesos se volvieron ridículos: cuando empiezas algo, no sabes si va a tardar dos días o tres meses. Todas las apps se rompen bastante rápido si no se les da mantenimiento constante, ya sea por una nueva tarea de red, una actualización de Unix no validada o una de las muchas cosas que inevitablemente van a ocurrir.
Al final ganaron los tramitadores de papeles y las personas que, incluso en su trabajo principal, apenas están en el promedio, porque se incrustaron profundamente en el proceso; las unidades de negocio reciben TI de baja calidad, los proyectos se retrasan y se pasan de presupuesto. Esto refuerza aún más la imagen de TI como un “mal necesario, pésimo pero inevitable”.
Ya dejé de preocuparme; basta con que el trabajo sea un medio para vivir. Mi foco y mis logros están en esa “vida”.
Lo que se mide importa. Este estudio solo analizó el uso de Copilot.
Soy un ingeniero con mucha experiencia, y Copilot no solo no me sirve: me estorba. La mayor parte del tiempo la paso entendiendo el dominio del problema, identificando las restricciones y posibilidades del entorno en el que estoy, y pensando en el código que voy a escribir.
Cuando por fin empiezo a teclear código, ya sé qué voy a escribir, así que el autocompletado de Copilot que “ayuda” solo me distrae. Empeora mucho mi flujo de trabajo.
En cambio, en las etapas previas a escribir código, la IA es tremendamente útil. A veces, con un prompt bien armado a partir del razonamiento previo, puedo obtener un borrador; después, hacer pair programming con un LLM para responder rápido a pequeños problemas inesperados resulta muy útil.
Por eso, a diferencia de este informe, creo que un desarrollador experto que usa bien la IA podría obtener más beneficios que un desarrollador con menos experiencia.
Pero usar Claude Sonnet 3.5 junto con Cursor o Continue.dev mejora la experiencia de forma drástica. Puedes controlar explícitamente el contexto; por ejemplo, seleccionar e inyectar 6 o 7 archivos, y sumado a la gran capacidad de Claude, cambia por completo el panorama.
Según la tarea, fácilmente te vuelve entre 2 y 5 veces más rápido. Algo que originalmente podría tomar medio día puede convertirse en menos de una hora en 100 líneas de código listo para producción, con pruebas incluidas.
Lo digo desde 26 años de experiencia y desde roles de principal/staff/lead desde 2012. Eso sí, no esperaría la misma mejora en perfiles por debajo de senior, porque en realidad hay que explicar con bastante detalle lo que se quiere, y normalmente tomar una solución inicial que funciona y refinarla unas seis veces hasta dejarla en una forma ideal y bien descompuesta.
Por ejemplo, al escribir IaC para AWS hay muchas cosas que consultar. Si le pregunto a la IA, obtengo respuestas y ejemplos muy rápido. Si estoy aprendiendo la IaC de un servicio nuevo, miro la documentación de AWS, pero cuando solo necesito una respuesta rápida o repasar algo, la IA es mucho más veloz.
Mientras más te apoyes en patrones funcionales, diseñes mónadas, hagas entrada/salida solo en los bordes y uses fluent programming, el efecto es muy grande.
Como referencia, esta es mi experiencia en Java. Llevo 3,5 años usando Java y dependo mucho de las funciones de Java 8+. Cuando se usan muchos genéricos en código de biblioteca, el LLM tiene más margen para elegir de forma consistente la opción correcta.
En diseños más rápidos y hechos a la ligera, no se obtiene tanto beneficio. Me gustaría escuchar más experiencias de usuarios de programación funcional de verdad, como Haskell, OCaml, F# o Scala.
Sí fue útil para escribir boilerplate de pruebas unitarias, en especial pruebas basadas en tablas, pero no lo suficiente como para mantener una suscripción paga.
Fue muy valioso cuando trabajaba con lenguajes que no conocía bien, o en tareas repetitivas donde podía juzgar fácilmente si el código generado estaba bien.
En cambio, se debilita cuando tengo muy claro lo que quiero hacer y es parecido a una implementación estándar, pero con algo un poco más novedoso. Esto pasa a menudo con “reduce” o procedimientos más ambiguos.
Como ingeniero de plataformas, voy saltando entre muchos espacios: Bash, Python, navegador, JS puro, TS, Node, GitHub Actions, flujos de trabajo Java en Jenkins, Docker, etc. Cuando cambio de dominio, me ayuda a descansar el cerebro y entrar en calor.
Me pregunto si el estudio incluyó la deuda técnica que los desarrolladores con menos experiencia generaron con IA y que luego tuvieron que resolver desarrolladores con más experiencia. Lo digo porque personalmente viví mucho de eso en una de las empresas mencionadas en el estudio.
También vi de primera mano que los desarrolladores a quienes les interesa menos la tecnología en sí, pero mucho la entrega, muestran más interés por la IA. A los PM les gusta esa gente, pero...
Lo que habíamos pedido era un cambio pequeño de unas 5 líneas y una prueba. Pero ahora no solo cargamos con nueva deuda, sino también con código que nadie puede explicar por qué fue cambiado por completo, parte del cual es cambio por cambiar, y además código que resulta totalmente ajeno para las personas que lo mantienen.
Lo veo constantemente entre personas que usan estas herramientas y no son ingenieros senior. Al final terminamos rechazando esos PR y diciéndoles que lo hagan de nuevo, y la ganancia de tiempo que supuestamente se obtuvo al principio desaparece.
No significa que estas herramientas no sirvan, pero la gente las está usando sin entender qué es el resultado, ni el impacto a largo plazo que tendrá en la base de código.
El día que perdí una parte de mi alma fue cuando le pregunté a un desarrollador si podía darle feedback sobre el esquema de la DB, me dijo que sí y, a los pocos minutos, me cortó diciendo: “Sí, a mí X no me interesa mucho”.
¿Que no te interesa? Como especialista en el área te estoy diciendo qué se puede mejorar, cómo hacerlo y por qué hay que hacerlo, ¿y no te interesa?
La nube fue un error. Le metió a la gente la idea de que, como siempre se puede escalar vertical u horizontalmente, no hace falta buscar eficiencia ni optimización. Y ni siquiera hablo de microbenchmarks, sino de cosas muy simples como “¿no convendría usar esta otra estructura de datos en vez de esta?”.
También la usamos internamente, y creo que la deuda técnica es una amenaza enorme que no se está dimensionando bien.
Es muy útil para aplicar en masa APIs y patrones con los que uno no está familiarizado, pero si no se tiene cuidado produce una enorme duplicación de código y boilerplate difícil de manejar.
La razón son dos grandes sesgos. Primero, los datos de entrenamiento del modelo son datos de ejemplo estilo StackOverflow, así que no consideran el contexto ni las restricciones. Segundo, tiende a mirar la base de código existente y copiar y repetir, en vez de proponer refactorizaciones.
Lo primero se puede mitigar si uno hace su trabajo y revisa y edita lo que escupe el LLM.
Lo segundo solo podría mitigarse si los diffs y el historial de commits entraran en los datos de entrenamiento, pero ese dataset es mucho más difícil de manejar y etiquetar. Algunos cambios son buenos, como una refactorización, pero otros pueden ser bugs que se corrigen en commits posteriores, y los mensajes de commit básicamente mienten, así que tampoco hay una distinción clara. Nadie escribe “introduce bug”.
Además, merge, rebase y squash cambian, eliminan o agregan ruido al significado del historial, haciendo que todo sea aún más borroso.
A mí me gusta la tecnología y también escribo software por diversión, pero objetivamente es más divertido hacerlo con IA. Mi productividad sube muchísimo y, sobre todo, desaparece la procrastinación.
Cuando me trabo o no tengo ganas de empezar una tarea, empiezo a conversar con Aider y, sin darme cuenta, ya terminé algo que ese día no habría hecho sin IA.
Gracias a eso, ahora publico proyectos públicos y privados cada dos semanas, cosas que antes me tomaban meses o años. Tener al lado a un equipo de desarrolladores rápidos y experimentados cuesta como máximo unos pocos dólares al día.
Antes de sacar conclusiones, hace falta mirar el paper con un poco más de profundidad. Creo que el estudio en sí también podría haber resumido mejor los resultados.
El resumen y la conclusión presentan como resultado una sola proporción: un aumento de productividad del 26.08%, pero parece tener demasiados decimales. Si uno profundiza un poco más, aparecen cifras de 27~39% para juniors y 8~13% para seniors.
Si se mira todavía más a fondo, no solo hay variación por experiencia, sino también grandes diferencias entre empresas. En Microsoft, aparte de los pull requests, otros indicadores de resultado como commits, builds y tasa de éxito de builds no parecen ser estadísticamente significativos. El aumento de PR también parece significativo en Microsoft, pero no en Accenture, y aun así quizá solo lo sea para juniors.
El resumen y la conclusión tienen que sintetizar, pero los resultados cambian tanto según la variable que no sé si tiene sentido dar un único número global como resumen. Sobre todo porque la significancia estadística parece bastante irregular.
Accenture es una empresa que colabora y hace co-marketing con grandes organizaciones como Microsoft. Su grupo de unos 300 desarrolladores casi no mueve la muestra total y, como está creando divisiones de marketing/consultoría alrededor de workflows de IA, tampoco es fácil asumir que sea objetiva.
La tercera empresa anónima en realidad no fue un ensayo controlado aleatorizado, así que es difícil decir cómo deberían combinarse sus resultados con los RCT. Además, seguramente hubo otras grandes empresas tecnológicas que hicieron experimentos similares y querían conocer la eficacia, por lo que se puede asumir que existen otros datos además de los incluidos en los resultados.
¿Por qué eligieron estas empresas de un conjunto de muestras más grande? Probablemente porque Microsoft y Accenture tienen incentivos para la adopción, y la tercera empresa fue elegida por p-hacking.
En particular, la frase del resumen “cada experimento individual es ruidoso, pero al combinar los tres experimentos” es una muy mala señal. Es prácticamente admitir que, si se mira cada empresa por separado, no hay resultados estadísticamente significativos, pero que al combinar estos tres grupos sí aparecen. Eso no es ciencia.
Los desarrolladores junior pueden estar haciendo tareas que a un LLM le resulta fácil acertar, o cometer el error de aceptar el primer borrador porque parece LGTM, lo que puede hacer que su throughput se vea más alto.
Usar modelos de código generado también requiere habilidad, y esa habilidad es la misma que se necesita para delegar trabajo a otras personas e integrar soluciones de varios autores en un sistema cohesivo.
Es solo mi intuición, pero creo que la programación asistida por LLM es perjudicial para crecer como desarrollador. Puede que eleve la productividad solo hasta cierto nivel, y ese nivel quizá sea repetición aburrida para un senior, pero para un junior es parte del proceso de formación.
En mi experiencia, los LLM no se usan solo para código boilerplate simple, sino que se invocan cuando un desarrollador junior se enfrenta a tareas bastante comunes que todavía no entiende lo suficiente. El proceso de experimentar, aprender y comprender suele ser reemplazado por el LLM, y la verdadera habilidad pasa a ser ajustar el prompt hasta que parezca que funciona.
Anoche configuré Linux RAID por primera vez. No es algo extremadamente difícil, pero requiere varias herramientas como mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs, etc., y durante el proceso uno puede desviarse de los pasos exactos de una guía, así que mirar solo tutoriales o documentación no es especialmente útil.
Hice decenas de preguntas sobre cada herramienta y cada paso; antes probablemente habría copiado y pegado, y rezado.
Hace dos días también logré recuperar todos los datos de un SSD dañado aprendiendo con ChatGPT. Aunque pueda equivocarse un 20%, fue realmente bueno abordar una tecnología totalmente nueva teniendo una “guía” mucho mejor que el promedio de la internet abierta.
Para alguien a quien le gusta aprender, se siente como botas de siete leguas comparado con escarbar interminablemente entre la basura de internet. Claro que, como con todo lo demás en internet, hay que desconfiar de lo que dice la IA, pero reduce muchísimo la fricción.
Tengo la misma intuición y, más aún, quisiera llamarla una opinión fuerte y fundamentada. Creo que la industria pagará el precio en unos años.
El pipeline de oferta de “desarrolladores de software junior con criterio” se va a secar mucho, y será reemplazado por una inundación de “desarrolladores de software junior dependientes de la IA”. Entre ambas categorías hay un abismo profundo.
Naturalmente, esto tendrá efectos en cadena sobre la cantidad de desarrolladores mid-level con criterio y desarrolladores senior con criterio.
En cambio, quienes quieren entender todo el código que usan probablemente investiguen las partes que no conocen de lo que escupe el LLM.
Al menos yo lo uso así. Y, como contraejemplo a la hipótesis, a veces el LLM usa funciones o componentes de bibliotecas que yo no conocía, así que me ahorra mucho tiempo al aprender un lenguaje o toolkit nuevo. Para mí acelera el aprendizaje, no lo frena.
Pero para quienes de todos modos iban a tener éxito, es como hacer una pregunta en StackOverflow y recibir una respuesta inmediata y sin reproches, así que es un regalo enorme.
No siempre será correcto, pero StackOverflow tampoco lo era. Al final, como siempre, depende de cada persona.
¿Cuántos desarrolladores actuales saben usar lenguaje de máquina, que hace 50 años era prácticamente indispensable para construir algo?
Tal vez los LLM estén pasando de ser otra muleta de abstracción a convertirse en un pilar sólido de abstracción.
Lo más interesante de este estudio es que, al dividir por nivel de experiencia, los desarrolladores con una antigüedad por encima de la mediana no muestran un aumento estadísticamente significativo en esa mala variable proxy llamada “productividad”. El intervalo de confianza del 95% incluso se hunde bastante hacia valores negativos en todos los indicadores, y apenas se inclina un poco hacia lo positivo
Coincide con mi experiencia. Copilot es bueno para reducir parte del trabajo tedioso y permitir que el cerebro se enfoque en preguntas más profundas, pero no cambia el mundo como dicen algunos desarrolladores junior
Además, a menudo se equivoca de formas sutiles, de esas que un desarrollador con poca experiencia podría pasar por alto. Yo tengo que detenerme y ajustar la mayor parte de lo que genera, y es muy probable que un desarrollador menos experimentado no sepa cómo hacer esos ajustes
Después de usarlo durante algunos años, ya tengo bastante intuición sobre cuándo usar Copilot y cuándo no, así que creo que el efecto neto es positivo, pero no siempre fue así
También me pregunto si parte de la aparente reducción de la “productividad” de los desarrolladores senior se debe al aumento de productividad de los juniors dentro de la empresa. Si los juniors crean más PR y estos tienen más errores, aumentando el tiempo de revisión, la mejora de productividad de los seniors podría reducirse proporcionalmente
El aumento de productividad del 26% coincide en general con mi experiencia. Creo que otra dimensión a analizar es si se está trabajando con una tecnología nueva o con una que ya se domina. La IA me resulta mucho más útil en lenguajes o frameworks que estoy intentando aprender
No suelo recordar bien las particularidades y trampas de lenguajes auxiliares, como exactamente qué hechizo de comillas se necesita para escribir condicionales en Bash. Por eso, antes casi no escribía scripts de Bash para automatización, y solo hacía el esfuerzo cuando era una tarea que repetía con suficiente frecuencia. Lo mismo pasaba con procesar JSON con jq o parsear con AWK
Ahora, gracias a los LLM, hago muchos más scripts de Bash, y como se volvió tan fácil, también los uso más seguido para documentar procesos. Lo que antes era un README estático paso a paso ahora viene acompañado de un script Bash interactivo que pide entradas al usuario
En general veo a muchos programadores senior discutiendo por qué las herramientas de IA no funcionan. Los juniors simplemente las usan sin prejuicios
Fue útil en cuatro casos. Primero, preguntas sobre frameworks/lenguajes que no uso a menudo pero que tienen mucho contenido de ejemplo, como Qt o CSS
Segundo, preguntas muy específicas que antes habría buscado en Google Search o StackOverflow. Por ejemplo, para algo como “la forma más eficiente de obtener el uso de CPU y RAM en Windows con Python”, en vez de generar de inmediato código para copiar y pegar, me apunta a bibliotecas o ejemplos
Tercero, código repetitivo que ya sé escribir, pero donde me ahorra algo de tiempo y reduce errores de tipeo. Usando el plugin de CoPilot para PyCharm, si escribo la intención en un comentario dentro del archivo, completa las siguientes líneas. De nuevo, los resultados son mejores cuando es algo muy corto y específico. Si se alarga, hay que iterar demasiado con CoPilot y deja de valer la pena
Cuarto, como forma de buscar documentación rápidamente
Hay gente que dice que es bueno para escribir pruebas unitarias, pero para mí no lo fue. Al menos no para el tipo de pruebas unitarias que yo quiero
Si tuviera que cuantificarlo, diría que mejora la productividad entre 5% y 10%. Mucho menos que usar un IDE completo como PyCharm en lugar de Notepad, o un buen cliente de git en vez de escribir comandos de git directamente en la CLI. Es decir, es solo una herramienta de productividad más; no diría que es “revolucionaria”
Probé Cursor durante unos 10 días en un proyecto enorme de Ruby on Rails, y llevo más de 13 años usando ese stack
No obtuve una mejora de productividad más allá de la que ya me daba GitHub Copilot. Estimo que la mejora de Copilot ronda el 25%
Pero cuando se crea por primera vez un proyecto nuevo como Node.js en una carpeta vacía, es extrañamente potente. Solo con prompts, puede crear en unos 5 minutos una API que maneja requests a partir de un esquema OpenAPI y entrega el esquema OpenAPI con swagger
Sin embargo, empezar proyectos nuevos desde cero es algo poco común para mí, así que probablemente vuelva a Copilot y VSCode básico
Permite que la gente haga más PR. Vaya, impresionante. A quién le importa
¿Aumenta la cantidad de ítems que pasan QA? ¿Las cosas hechas con ayuda de IA tienen menos bugs detectados después de QA? ¿Son fáciles de extender o modificar más adelante, o tienen un diseño rígido e inflexible?
Una herramienta que convierte a los desarrolladores en monos de código de calidad desconocida no es lo que busco. Quiero una herramienta que ayude a los desarrolladores a encontrar bugs o fallas de diseño en lo que hacen, o que los ayude a escribir pruebas bien diseñadas
Contar solo la cantidad de PR no dice nada útil. Más bien activa mi intuición de que más código por unidad de tiempo implica menor calidad promedio
Copilot: “¡Claro, con gusto! ¡Aquí están los nuevos commits!”
Desarrollador senior: “¿Por qué? El cambio es atómico. Si la gerencia vuelve a sacar métricas tontas como la cantidad mensual de cambios, les diré cortésmente que se vayan al diablo”
Probablemente esto haya sido con Copilot basado en GPT-3.5
Microsoft: septiembre de 2022 al 3 de mayo de 2023
Accenture: julio de 2023 a diciembre de 2023
Empresa anónima: octubre de 2023 a ¿?
La actualización de GPT-4 para Copilot Chat fue el 30 de noviembre de 2023: https://github.blog/changelog/label/copilot/
Para mí, la IA revivió la documentación. A los frameworks nuevos les falta demasiada documentación. La última documentación buena que recuerdo fue la de los libros de DOS. Siento que los desarrolladores de hoy quizá ni siquiera tienen una idea de cómo es una buena documentación.
Aun así, como la IA puede hacer una sugerencia distinta cada vez, el criterio todavía debe quedar en manos de un desarrollador con experiencia. Al final, la IA reemplaza la documentación y el tecleo.
Si es un proyecto público, como la documentación pasó a ser parte de los datos de entrenamiento de los LLM, se volvió mucho más importante que sea exhaustiva y precisa. Porque muchos desarrolladores obtendrán respuestas de ese sistema.
Si es un proyecto privado, se puede lograr el mismo efecto poniendo la documentación en un dataset de fine-tuning o en un sistema RAG.
Eso también podría explicar por qué no se documenta nada.
Así que, en la práctica, también tiene el efecto de obligar a los desarrolladores a documentar mejor el código.
No tiene que ser necesariamente documentación moderna y viva; cualquier cosa sirve. Quiero ver qué era tan excelente en el pasado y qué perdimos, e intentar incorporar algo de eso en mi propia documentación.