- El autor no usa herramientas de programación con IA porque, sobre todo, no lo hacen más rápido
- Considera que el tiempo necesario para revisar y entender el código generado por IA puede ser mayor que escribirlo directamente
- Como la calidad del código y la responsabilidad siguen recayendo en el propio desarrollador, usar código de IA sin revisarlo es riesgoso
- Frente a la idea de ver a la IA como un becario, critica que la IA no puede aprender, así que sería como un becario con amnesia
- Al explicar la diferencia entre contribuir a código abierto y usar código de IA, destaca que la interacción con personas aporta ideas nuevas, y eso tiene valor
Introducción
- Mucha gente le pregunta si usa herramientas de programación con IA generativa y qué opina de ellas
- En este texto deja de lado las posturas a favor y en contra para ordenar solo su experiencia técnica personal
- Explica desde una perspectiva técnica por qué la IA no le ayuda en su forma de programar
La IA no es más rápida
- Incluso usando herramientas de programación con IA generativa, su velocidad de trabajo no aumenta
- Aunque la IA escriba código, la responsabilidad del código sigue siendo suya, así que solo puede incorporarlo al proyecto después de revisarlo a fondo y entenderlo por completo
- La revisión de código requiere tanto tiempo y concentración como escribirlo, y hasta existe el dicho en la industria de que “leer código es más difícil que escribirlo”
- Confiar en el código escrito por IA como si fuera una “caja negra” es una decisión muy irresponsable. Si hay defectos, la responsabilidad legal y económica también recae en el programador
- Sin bajar la calidad ni aumentar el riesgo, no es posible elevar la productividad o las ganancias con IA
La IA no es una herramienta de apalancamiento
- Algunas personas afirman que las herramientas de programación con IA multiplican la eficiencia, pero para él eso no pasa de ser una impresión subjetiva
- Algunos usuarios usan el código generado por IA sin revisarlo o solo lo revisan en parte para ahorrar tiempo, pero él no puede saltarse ese proceso, así que no le resulta útil
- Tampoco está de acuerdo con la idea de que usar IA para aprender nuevos lenguajes o tecnologías sea más eficiente. El proceso mismo de aprender cosas nuevas es parte del disfrute de programar
- De hecho, aprende directamente varios lenguajes como Rust, Go y TypeScript, y no delega esa experiencia a la IA
- Eso se debe a que la responsabilidad de todo el código termina siendo suya
El código de IA es distinto del código humano
- A menudo se enfrenta a la pregunta: “Si en código abierto también uso código que no escribí yo, ¿por qué tratas distinto el código de IA?”
- En realidad, también dedica tiempo a revisar a fondo los PR de código abierto. Pero colaborar con usuarios conduce a ideas nuevas y a motivación
- También hay quienes dicen que ejecutar varios agentes de IA para recibir PR que resuelvan issues de bugs cambia las reglas del juego, pero al final el cuello de botella de la revisión sigue siendo humano, así que más bien se vuelve más lento
- A medida que se difunden las herramientas de IA, se generan con frecuencia PR de baja calidad. El código de IA tiene una extraña sensación de ajenidad, y muchas veces, cuando se le hacen preguntas a quien envió el PR, no responde
- La contribución responsable de código y la comunicación dentro de la comunidad de código abierto son diferencias clave del código humano
La diferencia entre la IA y un becario
- También existe la comparación entre la IA y un becario, pero para él son fundamentalmente distintos
- El código inicial de un becario requiere mucha revisión y tiempo, pero crece rápido gracias al feedback
- Esa inversión en el crecimiento del becario termina convirtiéndolo en un colega importante al que se le pueden confiar tareas de manera independiente
- Las herramientas de IA olvidan lo aprendido y vuelven a empezar con cada tarea nueva, por lo que no pueden crecer ni acumular experiencia
- Eso las hace parecidas a un becario que nunca mejora y que no puede contribuir a aumentar la productividad
Conclusión
- Con este texto busca transmitir con claridad los problemas técnicos de aplicar herramientas de programación con IA generativa
- En la programación con IA no existe tal cosa como un “almuerzo gratis”
- Las afirmaciones de que la IA hace el trabajo más rápido o más productivo provienen de bajar el estándar de calidad y aceptar riesgos adicionales, o del interés de quienes venden IA
- Los programadores deben recordar siempre que son los responsables finales
5 comentarios
Ya me asenté por completo con el modo agent de copilot (claud) + codex (o3/4o/codex-mini, usando 3 modelos al mismo tiempo vía mcp), pero creo que la efectividad varía muchísimo según quién lo use y el tipo de proyecto.
Yo lanzo trabajo en 5 o 6 workspaces al mismo tiempo y reviso conforme van terminando; como el modelo puede encargarse de meterse hasta dentro del código open source y validarlo todo, me parece bastante bueno. Si dejo tareas corriendo a la hora de la comida, una o dos suelen estar terminadas cuando vuelvo. A veces también las dejo corriendo toda la noche, pero eso del copilot rate limit es una caja negra...
También resuelve tareas que a una persona le toman tiempo porque implican muchos cambios de contexto, como kernels de alto rendimiento, simplificar todo el call stack o mejorar la legibilidad, siempre que se le den bien el prompt y el objetivo (porque puede cargar más código en memoria que un humano). Y en ese tipo de código, revisar los parches sí es fácil... Además, para quienes ya hayan sufrido incidentes causados por errores al usar APIs o bugs del propio proyecto open source, hacer que el Agent lo valide bien de forma consistente también ayuda bastante a la salud mental...
Eso sí, al final el desarrollador que lo usa tiene que ser capaz de entender los parches. Y también tiene que saber cómo plantear prompts. Solo se puede empezar de verdad cuando uno, por experiencia, sabe identificar rápido el problema y formularlo bien para lanzarlo. Igual que no se puede desarrollar un kernel de alto rendimiento sin fórmulas. Tener una idea de si el problema está en el nivel de chip/OS, en la aplicación o en un recurso remoto, me sigue pareciendo una tarea más de senior.
Desde la perspectiva de alguien que ha usado hasta cierto punto herramientas como Copilot, ChatGPT y Cursor, funcionan bien para el papel de plantillas o snippets dentro de las herramientas de desarrollo, pero no al nivel de un agente o un compañero de trabajo.
Estoy usando
cursor.En el modo chat prefiero
askantes que agent, porque quiero revisar y luego aplicar a mi código, y en general coincido con las desventajas mencionadas en el texto.Aun así, pienso seguir usando la IA generativa, porque muchas veces genera ideas o código en los que yo no había pensado, así que considero que tiene suficiente valor como referencia.
Coincide bastante con lo que he sentido, por experiencia personal, sobre usar herramientas de programación generativa.
Opinión en Hacker News
A algunas personas les surgen dudas cada vez que aprenden un lenguaje o tecnología nueva; antes buscaban en Google o publicaban preguntas en Stack Overflow y esperaban respuestas. Ahora preguntan de inmediato a ChatGPT o Gemini, reciben respuestas mucho más rápido y su productividad mejora bastante. Vale la pena enfatizar que solo obtener respuestas rápidas ya acelera el proceso de aprendizaje.
La razón por la que ChatGPT y Gemini pueden dar respuestas correctas es que fueron entrenados con conocimiento que ya existía en la web, incluido Stack Overflow. Si todos los usuarios solo usan IA para hacer preguntas, eventualmente podrían agotarse las fuentes públicas de conocimiento confiable. Esto se parece a un regreso a la era de las enciclopedias, cuando recopilar y vender información tenía un costo alto. Además, lo que critica el autor son las herramientas de IA para escribir código directamente, no las herramientas que responden preguntas, así que conviene distinguirlas.
Antes, usando una API poco familiar, un programa se me llegó a caer. Puse el stack trace en Gemini y de inmediato obtuve una pista sobre la causa; corregí solo dos líneas y resolví el problema. Experiencias así bastan para sentir el valor de la IA. Una gran ventaja es dejar de perder tanto tiempo por errores tontos en áreas que uno no domina.
La búsqueda cada vez prioriza más el spam de blogs, pero es más formativo aprender desde la base con buena documentación oficial o guías de usuario bien hechas. Al leer una buena documentación de API, uno termina aprendiendo de forma natural el diseño completo y funciones adicionales. Con ejemplos de blogs o tutoriales quizá resuelves el problema inmediato, pero no mejoras de verdad. Es como si solo te hicieran la tarea, por eso no creo que ChatGPT fomente el aprendizaje autodidacta genuino.
En problemas difíciles, siempre hace falta verificar el resultado de la IA. También desactivé el autocompletado con IA porque en la práctica no me daba tanta eficiencia y más bien generaba muchas correcciones innecesarias. Curiosamente, incluso con modelos locales completamente offline se puede obtener bastante material útil de referencia. Los resultados de Gemini integrado en Google también son de baja calidad. Mi mayor preocupación es que, si la gente solo obtiene información a través de IA, podrían desaparecer verdaderos repositorios de conocimiento como Stack Overflow.
Para herramientas pequeñas y boilerplate, la IA es perfecta. Con cosas simples como extensiones de navegador o scripts de Tampermonkey, casi se puede empezar sin leer documentación. También es bastante útil para autocompletado de código no complejo o cambios menores. Permite resolver rápido proyectos pequeños que normalmente ni siquiera habría empezado.
Un beneficio potencial de escribir código directamente es que te deja un modelo mental fuerte del problema en la cabeza. Después, al resolver problemas o integrar funciones nuevas, ese aprendizaje “inconsciente” tiene un efecto enorme. La habilidad real mejora cuando acumulas la memoria de haberlo hecho con tus propias manos. En las organizaciones que he visto, incluso después de adoptar LLM, no experimentaron una multiplicación real de la productividad. Me pregunto si no estaremos confundiendo con productividad el hecho de pensar menos y buscar siempre el camino fácil.
Creo que eso resume muy bien el fenómeno de acostumbrarse a resolver problemas gastando menos energía mental y sentir esa ilusión como si fuera productividad. En un experimento de Google Research sobre el efecto de los LLM en la productividad en 2024, el grupo que usó LLM tardó más que el grupo que estudió con libros, y solo los principiantes, no quienes ya dominaban el contenido, mejoraron un poco su puntuación. Pero muchos participantes creían que eran más rápidos y precisos, y los investigadores interpretaron la razón como una “reducción de la carga cognitiva”. Enlace al artículo relacionado: https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Si uno puede gastar menos energía mental y trabajar durante más tiempo, ¿no podría entonces procesar más volumen real de trabajo? Incluso ahora, el trabajo de alta dificultad tiene un límite de 3 a 4 horas. La idea es que, si pudieras correr un maratón a ritmo de caminata, el resultado final podría ser una mayor producción total.
Estoy de acuerdo en que la programación tradicional y la programación con IA son habilidades separadas. Yo también soy muy escéptico ante la idea de que la IA vaya a reemplazar la programación. Pero creo que la “programación con IA” en sí, incluyendo manejo de prompts y mantenimiento del contexto, también tiene una curva de aprendizaje considerable, y siento que mucha gente subestima su valor en ese punto. Es una perspectiva parecida a comparar dibujo a mano con fotografía: quizá el propósito que persiguen es distinto desde el inicio. Mi forma preferida es: “la IA se encarga del trabajo pesado y yo me ocupo del diseño general y la coordinación”.
Programar con LLM se parece a subcontratar algo mediante un ciclo repetido de definición de tareas, retroalimentación e iteración, más que a simple autocompletado. La diferencia está en la velocidad de procesamiento (ventaja de los LLM) y la confiabilidad (ventaja humana), pero a largo plazo esa frontera probablemente se irá desdibujando. Lo importante es que yo, por naturaleza, soy del tipo que quiere tratar directamente con los detalles del trabajo. Elegí esta profesión porque me gusta aprender y profundizar en infraestructura y programación. Por eso evito el rol de gestor y, aunque gane menos, insisto en hacer cosas directamente. Tal vez vuelva a interesarme cuando AGI llegue al nivel de poder ser colega. Incluso el propio término IA podría dejar de parecer tan especial con el tiempo.
Aunque la curva de aprendizaje de la programación con IA sea más grande de lo que parece, no es lo mismo que un piano en el que hay que invertir años. Los programadores con IA más experimentados que existen hoy apenas tienen unos 3 años de experiencia, y los modelos además cambian todo el tiempo, así que mucha experiencia pasada ya no encaja con la generación actual. También hay una limitación: no existe una estructura clara para aprender de un maestro.
¿Las habilidades de programación con IA realmente tendrán valor a largo plazo? Tengo dudas sobre cuánto del conjunto de habilidades de las herramientas actuales de IA se transferirá a futuras generaciones. Aunque la eficiencia suba hoy, hay que tener presente que si cambian los modelos y las herramientas, todo eso podría volverse inútil.
Creo que para dominar la programación con IA bastan unos minutos o, como mucho, una hora. Metafóricamente, no se siente como GDB o UNIX, campos en los que uno se sumerge libro por libro. Así como no confundimos dibujo y fotografía porque sus principios y objetivos son completamente distintos, la programación con IA también es una actividad totalmente diferente de la programación tradicional.
No estoy de acuerdo con la seguridad con la que algunos asumen que preferir programar directamente solo se debe a falta de habilidad en programación con IA. Con el ROI de lo que he probado hasta ahora, entre pagos pequeños y pruebas gratis, ya me basta para sacar una conclusión.
En la práctica, en vez de hacer revisión de código con IA o validar resultados, ha surgido una cultura en la que se sube a PR el código generado por IA tal cual y se deja la revisión a otros. En ese contexto, GenAI no parece tan útil, sino más bien una herramienta que facilita patear el trabajo hacia adelante.
Yo también viví algo así. Cuando un gerente tiene poca capacidad, no puede distinguir quién está generando valor real. Yo sí obtengo muchísimo valor de los agentes de programación, pero creo que en organizaciones incompetentes es un problema serio que se recompensen entregables flojos.
Si quien envía el PR sigue presentando resultados de IA sin cambios, la postura correcta es que el líder del equipo acumule ese feedback y le plantee el problema directamente.
Como alguien que usa mucho Claude Code, estoy 100% de acuerdo con la idea de que, al revisar código escrito por otros, casi no hay diferencia de tiempo respecto a escribirlo uno mismo. Los LLM sirven más o menos, pero mientras más control les cedes, más se alarga el camino hasta el release real. Me ayudaron a aliviar síntomas de RSI, pero el ahorro de tiempo muchas veces está más exagerado de lo que parece.
Cuando me preguntan si de verdad hay que revisar el código, normalmente digo que suelo hacer solo revisiones puntuales del resultado de la IA, le hago escribir a la IA el documento de especificaciones, y luego yo hago una revisión final y pruebas muy cuidadosas. De hecho, la mayoría del código de bibliotecas open source tampoco lo revisamos completo desde cero.
Aquí existe la premisa de que “el código que yo mismo escribí no necesita revisión desde otro punto de vista”. Pero en realidad, mi yo del futuro también es un lector potencial del código. Programar con IA obliga a esa mentalidad: establecer criterios de aceptación claros y validar con pruebas y reglas consistentes. Como resultado, impulsa una cultura de desarrollo más sólida y con mejor registro.
Para depurar bugs con Claude Code, si primero escribes las pruebas, es normal que la IA lo arregle en minutos. Desde que añadieron la nueva función de búsqueda, incluso tareas complejas pueden resolverse en 5 minutos; en esa parte, el ahorro de tiempo se siente muy claro.
Como solución para los síntomas de RSI, también recomiendo mantener siempre los brazos calientes.
Surge la duda de si existen casos de UI híbrida para quienes no quieren manejar todo mediante una interfaz conversacional.
Las herramientas de programación con IA generativa solo aceleran la parte fácil del trabajo y, en cambio, vuelven más difícil la parte complicada. En realidad, el tiempo que toma escribir código como tal no es tan grande, así que aunque solo esa parte se volviera 100 veces más rápida, la productividad total no cambiaría demasiado. Por eso no quiero dedicarle tiempo de más.
Si ya eres un ingeniero que domina por completo un stack y un dominio de problemas específicos, entonces no necesitas realmente ninguna herramienta ni aprendizaje adicional. Pero en la práctica esa lógica no tiene mucho sentido. Al final, elegir herramientas es una optimización personal.
Yo le pido a la IA que escriba algoritmos, explique causas del código, haga llamadas a APIs o implemente funciones específicas. Tal vez no le dejo el código completo de punta a punta, pero cada vez la uso más junto con el depurador.
Una pregunta en tono de broma: ¿serás plomero?
La parte donde el autor dice que “revisar código escrito por otros puede tomar tanto tiempo como escribirlo uno mismo, o incluso más” me resonó, porque yo también tengo experiencia en revisiones de código detalladas, como auditorías de seguridad. Pero si la IA se especializa en tareas rutinarias extremadamente simples, quizá baste con una validación amplia, como un verificador de eBPF, sin necesidad de mirar el código en detalle. Si hay problemas demasiado complejos, simplemente se rechaza el PR. En código simple y repetitivo, hace menos falta que una persona lo revise minuciosamente.
Aun así, dudo que eso sea realmente eficiente. Si vas a abrir decenas de PR para aprobar solo uno, mejor confiar en el código de un colega. Una estructura que solo desperdicia tiempo, dinero y recursos del entorno no me parece deseable.
Si de verdad es una “función repetitiva de Go”, dudo que valiera la pena escribir ese código en primer lugar. Si es código ineficiente y poco reutilizable, y todo se resolvería con una o dos líneas de una biblioteca común, no le veo sentido a generarlo con IA.
Para la gente que lee código más rápido de lo que lo escribe, GenAI es útil; para quienes escriben más rápido de lo que leen, no hace mucha falta.
Surge la duda de por qué el código escrito por IA debería revisarse de forma distinta al escrito por humanos.
Se enfatiza que, para tareas repetitivas y simples, también bastan los templates del IDE y el autocompletado de variables, con la ventaja de que ese método es gratis.
En la discusión que compara a los interns con asistentes de programación por IA, el intern aprende el código real, el negocio y la historia del sistema, mientras que a la IA hay que explicarle repetidamente el contexto. Esa limitación sigue ahí.
Desde otra perspectiva, si el contexto importante se guarda en archivos mdc, la siguiente persona responsable también podrá consultarlo, y eso incluso mejora la documentación y la continuidad del conocimiento.
En algunos LLM, eso termina siendo la razón por la que el system prompt se alarga hasta 14k.
Un intern muchas veces realmente CARE.
También es posible simplemente meter el contexto de negocio importante dentro del system prompt.
Los modelos actuales de IA, en esencia, solo aprenden patrones de datos existentes. Lo que hacen es combinar plantillas de casos exitosos, no inducir soluciones verdaderamente nuevas desde la raíz. Cuando ven un problema, intentan encontrar una respuesta en la experiencia más parecida, no abordarlo de manera principista desde cero. Los expertos humanos son hábiles en first principles, es decir, en el enfoque lógico basado en principios fundamentales que a la IA se le dificulta. La IA prioriza la similitud y propone soluciones estereotipadas, y sus límites se vuelven especialmente evidentes en áreas que requieren innovación o donde las convenciones no aplican. Además, los humanos responden con mucha más eficiencia al context poisoning.
Yo no espero mucho de la IA en el terreno de código generado, pero en tareas repetitivas y aburridas de boilerplate la IA es N veces más rápida, una diferencia que se siente enorme. Por experiencia real: le pedí a ChatGPT un ejemplo de estructura de modal basada en React Context y enseguida me generó hooks, provider y toda la estructura relacionada. Me ahorró unos 30 minutos, y para trabajo repetitivo así, pagar 20 dólares al mes definitivamente vale la pena.
En casos así, muchas veces también se puede traer algo de ejemplos en la documentación de una biblioteca, y en 5 minutos uno mismo puede terminar la implementación básica mínima que realmente necesita. Pero el código generado suele ofrecer una solución completa adaptada al contexto actual, y luego eso a veces resulta incómodo para mejorar la estructura o refactorizar de manera gradual.
Yo también uso IA sobre todo para boilerplate o scripts ad-hoc. Todavía me parece difícil dejarle por completo los problemas complejos del mundo real. En especial, cuando hay que meterse a fondo en un sistema, prefiero que lo haga una persona, porque la comprensión que se obtiene en el proceso es importante. Siento que cuanto más grande es el proyecto y más elementos integrados tiene, más claras se vuelven las limitaciones de la IA.