- GitHub y Microsoft anunciaron la vista previa pública de GitHub Copilot Agent, y en el repositorio de .NET Runtime se está probando que este agente genere PR automáticamente
- Sin embargo, estos PR incluyen cambios deficientes o innecesarios, así que los revisores la están pasando mal, mientras que los usuarios de Reddit lo ven como una situación entre graciosa y triste
- PR de ejemplo:
- PR #115762 – agrega otra verificación de null innecesaria en código donde la llamada a
string.Concat ya tenía esa validación
- PR #115743 – propone un refactor de una condición sin ningún efecto real
- PR #115733, PR #115732 también van en la misma línea
- El autor dice: “si este es el futuro de la industria, ya estoy listo para bajarme”, dejando ver su cansancio y escepticismo ante la adopción de IA
- Pero al mismo tiempo subraya que “siente compasión por los empleados encargados de revisar esto”, y añade que esta situación probablemente sea la carga de una orden desde arriba para adoptar Copilot
> Mi “schadenfreude (placer)” va dirigido a los ejecutivos de Microsoft que alimentan el hype de la IA. Por favor, respeten a los desarrolladores.
> * schadenfreude es una palabra de origen alemán que literalmente significa “placer que viene del daño”. Es decir, “la satisfacción secreta que se siente ante la mala suerte de otros”
Resumen de los comentarios principales
1. Los PR escritos por IA son inexactos y simplemente repiten ‘suposiciones’ sin entender el contexto
- Proponen cambios sin entender qué hace realmente el código del PR
- Corrección de un error repetitivo → código que sigue mal → otra corrección de error… un bucle interminable
- “Ya lo arreglé” → “todavía está mal” → “ahora sí de verdad lo arreglé”… algunos opinan que este proceso se parece al patrón de un junior dev
2. Para resolver problemas complejos, en realidad toma más tiempo
- Puede ayudar con cambios simples, pero no sirve para los problemas complejos donde de verdad quieres ahorrar tiempo
- Hay que entender el problema → entender a Copilot → comparar → verificar → hacer ajustes manuales
- En la práctica, es más rápido resolverlo yo mismo
3. La idea corporativa de que ‘la IA sirve para todo’ está dejando de lado a los desarrolladores
- El mensaje de que “si usas Copilot no te quedas atrás” está desconectado de la realidad del trabajo de desarrollo
- El tiempo de revisión de PR se alarga y la responsabilidad termina recayendo en los desarrolladores
- Existe preocupación por un ‘bucle de entrenamiento de IA para IA’, donde una IA entrenada con código generado por Copilot vuelva a degradar la calidad del código
4. La IA solo entrega respuestas equivocadas con mucha seguridad, pero no tiene criterio para decir ‘esto está bien’
- Incluso cuando recibe feedback de que está mal, responde “¡lo corregí!” → y propone cambios todavía más extraños
- No hace el juicio de “este código está bien, no hace falta tocarlo”
- Algunos señalan que esto podría ser un diseño pensado para evitar responsabilidad legal
5. La presión constante por adoptar IA está deteriorando la experiencia de los desarrolladores
- Los experimentos de adopción de IA continúan por instrucciones gerenciales o por evaluaciones de desempeño
- Los desarrolladores expresan el cansancio de sentir que se convirtieron en niñeras de la IA
- También hay una visión pesimista de que, si esta tendencia sigue, “los desarrolladores se van a cansar de la IA y van a dejar la industria”
Frases destacadas
- “La IA parece un practicante que repite suposiciones equivocadas mientras insiste con total seguridad”
- “En vez de gastar tiempo revisando código de Copilot, mejor lo escribo yo desde cero”
- “Esto es un estado de ‘reverse centaurs’, donde el desarrollador termina ayudando a la máquina”
- Un término usado por Cory Doctorow para decir que “no somos humanos ayudados por máquinas, sino humanos obligados a ayudar a las máquinas”
- “Copilot es como poner parches chapuceros al código, solo que automatizado, así que se convierte en miles de parches molestos”
- “Parece que el valor por defecto de los LLM es: ‘puedo estar equivocado, pero no tengo ninguna duda’”
12 comentarios
La productividad ha subido mucho con un flujo de trabajo asíncrono en el que le planteas un problema y, si la respuesta está mal, lo descartas; ¿pero esto no se parece a una herramienta estática? Si lo ves como una herramienta de análisis estático muy evolucionada, es un buen aliado. Sinceramente, también analiza rápido y sabe más que un ingeniero junior.
Sí uso IA, pero como es tonta, si no sabes corregirla no puede implementarlo bien. Viendo eso de vibe coding, todo está lleno de código con errores...
Cada vez que uso un LLM, tengo esta experiencia. Por más que le señale infinitamente las partes que no puede hacer, sigue sin poder hacerlas.
Al final termino cansándome y analizándolo y corrigiéndolo yo mismo. Cuando este tipo de experiencia se acumula, terminas sintiendo que los LLM y todo eso son pura basura y ya no dan ganas de usarlos.
Me hace pensar en una historieta web donde la IA les da prompts inversos a los humanos para que programen.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Parece que esto va a seguir ocurriendo a menos que la IA realmente pueda resolver problemas y aprender al mismo tiempo, como lo hace una persona.
Si cumples bien con la fecha límite y los requisitos, en realidad no importa mucho si usaste IA al programar o si, en plan macho alfa, ni siquiera usaste un IDE y escribiste todo solo en el Bloc de notas.
Cuando pensaba que esto era solo una nueva tecnología, lo miraba con curiosidad,
pero ahora que los empleadores realmente están llevando adelante contrataciones y recortes salariales con este tipo de tecnología como motivo, la verdad es que no me hace sentir nada bien..
Parece que, como todavía estamos en una etapa de transición, siguen pasando todo tipo de situaciones.
En adelante puede mejorar más, o quizás siga igual, así que también será divertido ver cómo cambia jaja
Estoy usando Gemini integrado en GitHub para que revise PR, y a veces pasa justo eso.
Por ejemplo, aunque en la línea de arriba ya se hizo la verificación de
null, te deja una revisión diciendo que lo estás usando sin verificarnully te pide agregar exactamente la misma línea que está justo arriba.Además, me hace pensar que todo el conocimiento de contexto, los patrones de trabajo y los resultados esperados y su formato, que una persona va aprendiendo de forma natural al hacer su trabajo,
no solo no se pueden escribir por completo en un prompt, sino que incluso si se pudiera, quizá sería más realista automatizarlo con algoritmos tradicionales de antes del deep learning, en lugar de con una IA compleja como un LLM.
Cuando lo usas, el vibe coding y los agentes de codificación sí tienen partes claramente convenientes, pero para que de verdad sean útiles hay que mandar prompts extremadamente precisos, y desde el principio también hay muchos proyectos donde simplemente no funcionan bien según la naturaleza del proyecto. Si las funciones están bien divididas en partes pequeñas y simples, como en un servidor web con arquitectura MSA, trabajan bien; pero si intentas arreglar con IA una lógica compleja con muchos módulos enganchados a un gran monolito, tienes que planear las tareas con muchísimo cuidado y redactar muy bien los prompts.
Opiniones de Hacker News
Comparte lo curioso de la situación en la que todos los comentarios traen el mensaje "Help improve Copilot by leaving feedback using the or buttons", pero en realidad nunca ha visto que se adjunte ningún feedback; cuenta que esto pasa a menudo cuando, al usar LLM, la configuración del system prompt no está bien hecha; el ejemplo de PR más gracioso es cuando, supuestamente para arreglar fallas en los tests, simplemente borran los casos de prueba, los comentan o cambian las assertions sin más; especula que los modelos de Googles y Microsofts muestran esto más seguido que los de OpenAIs y Anthropics, y que parece reflejarse en los resultados la diferencia entre los procesos internos de cada empresa; presenta el proceso real en el que una persona lo señala tres veces más en el PR y luego se rinde; dice que ni siquiera puede imaginar cómo se sienten quienes revisan estos PR, porque se parece a lidiar con un desarrollador junior que no hace caso, salvo que aquí ni siquiera existe comprensión del contexto; da el ejemplo de un PR donde el 90% está lleno de "Check failure", lo que dificulta incluso revisar el código o los diffs, y la tristeza de ver unit tests que solo dicen "Test expressions mentioned in the issue"; opina con honestidad que, si esta situación no fuera tan dolorosa para los humanos, en realidad sería muy divertida
La analogía con un desarrollador junior está demasiado exagerada; también trabaja con juniors, pero ellos no cometen errores rarísimos tan seguido como un LLM, no requieren tanto esfuerzo y aprenden rápido; cree que un LLM es una herramienta auxiliar decente si se usa con cuidado, ayuda a mejorar la velocidad y también sirve como compañero para brainstorming de ideas, pero no puede reemplazar a un intern ni a un desarrollador real
Cuando entró al campo de la ingeniería de software a fines de los 80, había diversión, pero hoy el ambiente se ha vuelto tóxico por procesos de entrevistas, por la imitación de big tech en empresas pequeñas y medianas, y ahora por experimentos de PR con IA; expresa dudas sobre si todavía queda alegría en el trabajo de ser desarrollador profesional hoy en día
Al menos a un desarrollador junior se le puede decir que corra las pruebas en local antes de mandar un PR; le preocupa que en algún momento los desarrolladores humanos simplemente se rindan, cierren los PR de "basura de IA" y tiren todo excepto lo que realmente funcione; piensa que, de seguir soportando los experimentos de la máquina, llegará un día en que todos se cansen de sus límites y abandonen
Cuestiona si realmente hace falta un sistema de feedback; desde el punto de vista del desarrollo, el éxito es un PR que se mergea al primer intento, y el fracaso puede entenderse como el deterioro acumulado según la cantidad de cambios correctivos que pidió el agente; sostiene que pedir feedback manual es ineficiente y que sería mejor medir el rendimiento igual que con los desarrolladores, usando métricas como cycle time, tasa de aprobación y change failure rate
Comparte la experiencia de haber sentido que hablaba con una pared al comunicarse con el equipo de soporte de Microsoft; aunque abrió varios casos, nunca obtuvo una resolución satisfactoria; entiende que Microsoft quiera usar su propia tecnología, pero pide que no se la impongan a él; opina que Microsoft no debería lanzar productos para los que aún no está preparada en soporte
Vio recientemente un video donde Eric de Google hablaba sobre IA; él sostiene que la IA hoy está subestimada, y citó que compró una empresa de cohetes y que, al intentar desafíos fuera de su especialidad con IA como Deep Research, enfatiza que "no es un experto"; dice que él tampoco odia la IA, pero que la IA generativa actual, basada en reconstrucción de patrones, es muy buena para provocar el asombro de principiantes; si no conoces el área, el resultado parece impresionante, pero cuando entiendes el tema a fondo, te decepcionan rápido sus huecos; las personas que trabajan en primera línea, como en Microsoft, tienen claro cuál es el problema, pero los ejecutivos, especialmente alguien como Eric, son vulnerables a dejarse engañar por una IA que solo habla de forma vistosa; espera que algún día la IA pueda escribir código que realmente funcione, pero cree que ese día todavía está lejos
Explica que él usa la IA con mucho cuidado y de forma muy limitada; en cambio, esos multimillonarios que "compraron una empresa de cohetes" se entusiasman con la IA y hasta la usan para tomar decisiones de inversión que sigan aumentando su fortuna; incluso si fracasan en grande, lo que perderán será apenas una parte de sus accesorios y eso no alterará su situación social; en cambio, para los empleos de TI en el terreno, siente que el riesgo lleva a malos resultados por ambos lados
Menciona la facilidad con la que líderes no expertos se maravillan con la IA y se imagina qué podría pasar si Google colabora con el ejército de Estados Unidos para montar Gemini en drones autónomos a gran escala
Se pregunta qué confianza puede darle a las empresas que construyeron productos sobre .NET ver a empleados de Microsoft pasarse horas discutiendo con un LLM en vez de resolver problemas reales
Antes, incluso antes de introducir LLM, ya había visto en issues de GitHub a usuarios incapaces de explicar bien un problema y a maintainers cada vez más irritados; ahora ya ni siquiera hace falta el usuario final molesto
De hecho, este resultado sería la consecuencia natural de una mala gestión y de instrucciones torpes; esta vez ya no se puede culpar al junior y solo queda culparse a uno mismo
Subraya especialmente el dolor que se siente al ver que hasta Stephen Toub, conocido por el famoso blog de rendimiento de .net, participa en este proceso
No quiere impedir que se experimente con nuevas tecnologías, pero aclara que la diferencia es que ahora el experimento simplemente quedó expuesto a todo el mundo
Afirma con cinismo que Microsoft llevaba años fomentando una cultura de pasar problemas a "Will Not Fix" con la lógica de "simplemente ignora el error", atrapada en la autosatisfacción de los managers, y que por eso se buscó sola todo lo que está ocurriendo ahora
Explica el contexto con un comentario en el primer PR: están identificando los límites de la herramienta mediante varios experimentos y preparándose para el futuro, y la responsabilidad de hacer merge sigue recayendo en los maintainers igual que con cualquier PR normal; nada se mergeará hasta cumplir los estándares de calidad
El empleado de Microsoft que escribió ese comentario también plantea que, si no piensas en cómo usar IA, te quedarás atrás; describe el ambiente en Microsoft como una mezcla de ansiedad y entusiasmo por la idea de que la IA ponga patas arriba la industria del software; sin embargo, el experimento se lee no como una evaluación de límites de la herramienta, sino como una participación forzada para proteger empleos, lo que más bien reduce la confianza
Dice que hay que entender que los managers no necesariamente ya sacaron una conclusión sobre las capacidades del modelo, sino que podría tratarse de un experimento razonable para identificar fortalezas y debilidades en contexto real
Le parece extraño que se le asigne un PR que ni siquiera pasó CI; lo normal sería asignar solo PR aprobados por las verificaciones, pero da la impresión de que el sistema está tan desordenado que ni eso pueden hacer; comenta con cinismo que, si de verdad funcionara bien, eso debería ser lo mínimo
Pide que no se interprete toda la situación siempre en el peor escenario posible; probablemente los humanos involucrados saben que es un experimento y ya tienen las expectativas ajustadas; sin este tipo de enfoque experimental sería difícil que el sistema mejorara, así que tal vez simplemente lo están afinando y probando en un entorno real; en su empresa también hicieron el mismo tipo de experimento al principio de adoptar herramientas de asistencia de código con IA, y aunque la calidad del código era peor que cuando programaba un humano, aprendieron mucho del proceso; al tener una línea base, pudieron ver claramente cómo mejoraba con el tiempo
En los comentarios se explicó que, por un problema de firewall, no podían verificar si los tests pasaban, y que si se resolvía solo ese problema, podría funcionar normalmente
Propone reemplazar al agente de IA por cualquier otra tecnología nueva y dice que igual se vería como la imagen típica de una empresa: experimentar de forma abierta (dogfooding al estilo big tech), contribuir de verdad al avance técnico de la industria y, si algo sale mal, que el daño quede totalmente limitado al equipo interno; pregunta por qué habría una razón clara para no apoyar este tipo de experimentos
Le resulta raro el ambiente donde todos solo lanzan críticas contra estos experimentos abiertos; le parece mucho más útil que no lo escondan en un fork privado y que expongan con transparencia sus capacidades reales, algo mejor que el humo de ventas y marketing
Considera que hacer este tipo de experimentos en un framework de infraestructura central para el desarrollo de software sí da pie a controversia
Se pregunta por qué "nosotros" tendríamos que apoyar o no apoyar algo, y de qué manera; personalmente, solo le da risa ver a MS fracasar de forma tan escandalosa
Dice que cuesta verlo como un verdadero "avance"; sin un POC interno previo, exponer públicamente problemas del sistema resulta más bien irresponsable; cuestiona por qué no validaron antes lo básico del entorno, como el firewall, o por qué no lo probaron primero en otros codebases internos; argumenta que el código de infraestructura requiere estándares altos y que, incluso bajo la excusa de dogfooding, debería empezar por proyectos menores; critica que ni siquiera es "state of the art" y se burla de lo tosco del resultado frente al costo invertido
Considera problemático hacer estos experimentos en un proyecto popular del que dependen muchísimos desarrolladores; teme una baja de calidad por código deficiente generado por IA, acumulación de código inútil o que solo termine desgastando la productividad del equipo
Si se trata de obediencia pasiva a algo, propone con ironía aprobar todas las solicitudes sin revisar y, si el stack tecnológico de Microsoft se hunde a nivel mundial, entonces renunciar y volver como consultor cobrando tres veces más
Dice que no querría trabajar con esa actitud burlona; no entiende el marco hostil de "nosotros contra ellos" respecto a la dirección de la empresa, ni la idea de sabotear a propósito; aunque se queje de las imperfecciones, no va con su conciencia obstaculizar o atacar a toda la organización
Responden con cinismo que, de todos modos, el stack tecnológico de Microsoft ya está roto
Señala que, en realidad, fueron los propios responsables del proyecto quienes enviaron directamente el PR generado con CoPilot
Bromea con que algún día CoPilot sobrescribirá todo el codebase y, si ya no hay código, entonces tampoco habrá más fallas de testing
Opina que, como cualquiera puede ser víctima de layoffs en cualquier momento, como pasó con quien hizo el compilador de TypeScript en Go, no hay motivo para ser tan leal dentro de una organización así
Abrir un PR es, al menos, una forma segura de experimentar: si no sirve, se puede descartar enseguida; todo intento nuevo trae prueba y error, y ese aprendizaje en sí importa; espera que, al entrenarlo con dureza sobre código real y problemas reales, la herramienta pueda mejorar rápido; por ejemplo, cree que en el futuro podría incorporar aprendizaje iterativo hasta que los tests pasen o verificaciones para impedir que se borren tests; al final, imagina un futuro en el que la IA se encargue de las tareas repetitivas y simples del proceso de desarrollo y los desarrolladores se concentren en el trabajo creativo esencial
Aun así, considera más seguro hacer este tipo de experimentos en un fork privado y no en un repositorio público; duda si fue una buena decisión exponer públicamente estos casos desde el punto de vista de ventas; cuando un tomador de decisiones interno vea CoPilot en una revista y quiera intentar lo mismo, este tipo de ejemplo real podría servir de referencia; normalmente, la mayoría de las empresas tienden a esconder al máximo los casos de fallas en sus aplicaciones y a mostrar solo una imagen pulida
Incluso en PR que por fuera parecen aceptables, puede haber problemas poco visibles ocultos, y eso los hace todavía más peligrosos
Comparte la experiencia de que revisar código de IA resulta incluso más irritante que el trabajo repetitivo simple, especialmente cuando hay bugs escondidos y el desarrollador termina sufriendo más
Abrir PR en sí mismo añade carga y complejidad a la gestión del proyecto; hacer los experimentos en un fork aparte sería un buen ejemplo para la comunidad; muchos proyectos open source terminan abandonados o sobreviven solo mediante forks que rescatan algunos PR valiosos porque sus maintainers se agotan gestionando el acumulado de PR; le preocupa que este tipo de práctica aumente la cantidad de proyectos abandonados y forks
Si de verdad se cree que un LLM puede aprender a programar correctamente estando lleno de bugs, entonces después hará falta construir datasets con casi cero bugs; en la práctica, eso no está pasando y solo están raspando cualquier dato disponible
GitHub gastó miles de millones de dólares para construir una IA que falla con frecuencia incluso en lint de espacios en uno de los repositorios más maduros del mundo; como experimento de hobby podría pasar, pero venderlo con un precio real como "producto innovador" sí genera controversia
Desde la perspectiva de un investigador, claro que es un experimento lógico, pero el problema es la actitud de una empresa que vende de inmediato algo todavía inacabado
Hace una broma sobre el ex-CEO Nat Friedman: "ya debe haberse muerto... no, todavía sigue vivo"
El verdadero problema es la falta de métricas objetivas para medir el desempeño de los desarrolladores de software; la situación queda reducida a evaluaciones subjetivas como las de fin de año; así es difícil saber si el uso de IA realmente está siendo eficiente o ineficiente; puede parecer más barato que un junior, pero desperdicia tiempo de seniors y no sigue instrucciones; al combinarse con el culto al CEO, se profundizan los desacuerdos dentro de la organización; la resistencia de los desarrolladores se descarta como "miedo a ser reemplazados", mientras que del lado del CEO se maximiza el impulso político del proyecto; como no existe un estándar de la industria que ambos lados acepten, es imposible conocer la verdad; llevado al extremo, incluso podrían exigir bajar el estándar de revisión para aumentar la cantidad de PR de IA dentro de la organización