Sí, pero no todo. En 2026 un asistente de IA puede escribir la mayor parte del código de un servicio backend típico, y para el boilerplate, el andamiaje de los tests y los scripts de usar y tirar deberías dejar que lo haga. Escribirlo tú sigue siendo mejor cuando estás aprendiendo algo nuevo, cuando serás tú quien lo depure a las 2 de la madrugada, cuando un bug podría filtrar datos o dinero y cuando la lógica es lo que distingue a tu producto. Los estudios de 2025 y 2026 explican bastante bien por qué.
Resumen rápido
- Aprender con IA te cuesta comprensión. En el ensayo aleatorizado de Anthropic, los desarrolladores que aprendieron una biblioteca nueva con ayuda de IA obtuvieron un 50 % en un cuestionario posterior. Quienes programaron a mano obtuvieron un 67 %, y la mayor diferencia estuvo en las preguntas de depuración (Anthropic, 2026).
- «Casi bien» es el fallo por defecto. El 66 % de los desarrolladores dice que su mayor frustración es el código de IA que está casi bien, pero no del todo, y el 45,2 % afirma que depurar código generado por IA le lleva más tiempo (Stack Overflow Developer Survey, 2025).
- La seguridad no se ha puesto al día. El código generado por IA supera los controles de seguridad solo alrededor del 55 % de las veces, una tasa que se ha mantenido entre el 45 % y el 55 % incluso cuando la corrección sintáctica superó el 95 % (Veracode, 2026).
- No puedes percibir si la IA te está ayudando. Los desarrolladores con experiencia del ensayo de METR de 2025 tardaron un 19 % más con IA, pero creían que eran un 20 % más rápidos (METR, 2025).
- La regla: deja que la IA escriba el código que tú mismo podrías haber escrito. Escribe a mano todo lo que todavía no entiendes.
¿Qué dice la investigación sobre programar con IA?
La IA te hace más rápido escribiendo código y peor aprendiendo de él, y ninguno de los dos efectos se nota mientras te está pasando.
La evidencia más clara viene de un estudio de Anthropic de enero de 2026. Los investigadores dieron a 52 ingenieros, en su mayoría junior y todos usuarios semanales de Python, una tarea con Trio, una biblioteca async que ninguno conocía. La mitad podía usar un asistente de IA. Al terminar, todos hicieron un cuestionario sobre la biblioteca. El grupo con IA obtuvo una media del 50 %. El grupo que programó a mano obtuvo una media del 67 %, una diferencia que los investigadores describen como «casi dos notas de diferencia» (Anthropic, 2026). El grupo con IA terminó solo unos dos minutos antes, y esa diferencia no fue estadísticamente significativa.
La mayor diferencia estuvo en las preguntas de depuración. Depurar es la parte del trabajo que la IA te devuelve. Cuando el código generado se rompe, te toca a ti averiguar por qué.
Un estudio más grande, fuera de la programación, vio lo mismo. En un ensayo aleatorizado con unos 1.000 estudiantes de matemáticas de secundaria, quienes recibieron un asistente básico al estilo de ChatGPT mejoraron sus resultados en los ejercicios de práctica un 48 %. En el examen sin IA, sacaron un 17 % menos que los estudiantes que nunca lo tuvieron (Bastani et al., PNAS, 2025). Hicieron más trabajo y aprendieron menos de él.
Nada de esto sorprende a quienes estudian el aprendizaje. El efecto de generación, documentado por primera vez por Slamecka y Graf en 1978, muestra que las personas recuerdan mejor la información que producen ellas mismas que la que solo leen. La práctica de recuperación funciona igual: los estudiantes que practicaron recordar el material rindieron peor en un test inmediato que los que lo releyeron, pero mejor una semana después (Roediger & Karpicke, Psychological Science, 2006). Aceptar una sugerencia de la IA se parece mucho a releer. Escribir la solución de memoria se acerca más a recuperar.
¿Cuándo deberías seguir escribiendo código a mano?
Escribe código a mano cuando el coste de no entenderlo sea mayor que el tiempo que ahorrarías. En la práctica, eso se reduce a seis situaciones.
Cuando estás aprendiendo un lenguaje, una biblioteca o un patrón
Si estás aprendiendo Go, escribe tú las goroutines, el wrapping de errores y las definiciones de interfaces, aunque un asistente los genere más rápido. El estudio de Anthropic midió justo esta situación, y el grupo que programó a mano salió bastante por delante.
El mismo estudio vio que usar IA no tiene por qué perjudicarte. Los participantes que pidieron código y luego hicieron preguntas de seguimiento hasta entenderlo, o que solo hicieron preguntas conceptuales y corrigieron sus propios errores, mantuvieron resultados del 65 % o más en el cuestionario (Anthropic, 2026). Las notas bajaban en quienes dejaban que el asistente pensara por ellos.
Cuando serás tú quien lo depure
Si te van a llamar a ti cuando este código falle en producción, necesitas saber cómo funciona. Si lo escribiste tú, ya tienes una idea de cómo funciona. Si lo aceptaste sin más, tendrás que hacerte esa idea en plena incidencia. En la encuesta de Stack Overflow de 2025, el 45,2 % de los desarrolladores ya dice que depurar código generado por IA lleva más tiempo que depurar el suyo propio (Stack Overflow, 2025).
Cuando el código protege dinero, autenticación o datos de usuarios
Veracode probó código de más de 100 modelos y encontró que el 45 % de las muestras introducía una vulnerabilidad del OWASP Top 10 (Veracode, 2025). En su actualización de la primavera de 2026, el porcentaje de código que pasaba los controles de seguridad seguía atascado entre el 45 % y el 55 %. En cross-site scripting, solo el 15 % de las muestras era seguro (Veracode, 2026). Los modelos más nuevos y más grandes escriben una sintaxis más limpia, pero las cifras de seguridad no se han movido.
La confianza lo empeora. En un estudio de Stanford, los participantes con un asistente de IA escribieron código menos seguro y además tendían más a creer que era seguro (Perry et al., ACM CCS, 2023). Escribe a mano la autenticación, la autorización, la gestión de pagos, la validación de entradas y todo lo que construya SQL o HTML, o al menos lee cada línea generada como un revisor que espera encontrar un bug.
Cuando la lógica es el producto
El boilerplate es el mismo en todos los proyectos. Las reglas de precios, el algoritmo de planificación y la forma en que tu sistema gestiona un fallo parcial son propios del tuyo. En ese código están las decisiones de diseño, y al escribirlo descubres los casos límite que la especificación no contemplaba. Revisar una versión generada te dice qué supuso el modelo sobre esos casos límite, y eso puede ser la respuesta correcta o no serlo.
Cuando no sabes si la IA te está ayudando de verdad
En el ensayo aleatorizado de METR de 2025, 16 desarrolladores open source con experiencia trabajaron en 246 issues reales de sus propios repositorios. Con la IA permitida, las tareas tardaron un 19 % más. Antes de empezar esperaban ir un 24 % más rápido, y después seguían creyendo que la IA los había hecho un 20 % más rápidos (METR, 2025).
Para ser justos con las herramientas, el seguimiento de METR de febrero de 2026 con modelos más nuevos apunta en la dirección contraria. Estima que los desarrolladores con experiencia probablemente ahora sí van más rápido, aunque los intervalos de confianza siguen cruzando el cero (METR, 2026). Lo que sigue en pie es la brecha de percepción: sentir que vas más rápido dice muy poco sobre si de verdad vas más rápido. Si una tarea se queda dando vueltas entre prompts y correcciones, para y escríbela tú.
Cuando no hay IA a mano
Entrevistas técnicas, diseño de sistemas en una pizarra, una incidencia en producción en una máquina sin ningún asistente instalado, una sesión de pair programming en la que tienes que explicar tu razonamiento: en ninguna de estas situaciones puedes delegar. Si solo sabes sacar código a base de prompts, se nota enseguida.
Un ejemplo en Go: el bucle de reintentos que tu autocompletado escribe mal
Así es como se ve el «casi bien» en la práctica. Estás escribiendo una función auxiliar que reintenta una llamada poco fiable a un servicio downstream, y tu asistente completa el cuerpo:
example.gogofunc retry(ctx context.Context, fn func() error) error { var err error for i := 0; i < 5; i++ { if err = fn(); err == nil { return nil } time.Sleep(time.Second) } return err }
Compila y pasa un test en el que fn falla dos veces y luego tiene éxito. Y aun así está mal en tres cosas, que solo ves si sabes cómo se comportan los servicios de Go bajo carga:
- Recibe un
context.Contexty lo ignora. Si el cliente se desconecta o el servidor empieza a apagarse, esta función sigue durmiendo y llamando afndurante hasta cuatro segundos más. Bajo carga, esos reintentos huérfanos se acumulan. - La espera es fija. Cuando el servicio downstream ya tiene problemas, que todos los clientes reintenten al mismo ritmo de un segundo lo empeora. Lo que quieres es que la espera crezca.
- Duerme después del último intento. El último
time.Sleepretrasa el error un segundo sin ningún beneficio.
Esta es la versión que escribes cuando entiendes esos tres problemas:
example.gogofunc retry(ctx context.Context, fn func() error) error { const maxAttempts = 5 delay := 100 * time.Millisecond var err error for attempt := range maxAttempts { if err = fn(); err == nil { return nil } if attempt == maxAttempts-1 { break } timer := time.NewTimer(delay) select { case <-ctx.Done(): timer.Stop() return errors.Join(err, ctx.Err()) case <-timer.C: } delay *= 2 } return err }
Un asistente también puede generar la segunda versión, pero solo si sabes pedírsela. Ese conocimiento (la cancelación con context, el backoff, lo que pasa bajo carga) viene de haber escrito bucles como este y haberlos visto fallar. Si quieres esa práctica, el curso Go Concurrency Fundamentals cubre select, los timers y la cancelación con context con ejercicios que ejecutan Go real.
¿Cuándo está bien dejar que la IA escriba el código?
Deja que la IA escriba el código cuando tú mismo podrías haberlo escrito y revisarlo es más rápido que teclearlo. Los desarrolladores de Go ya coinciden bastante en la lista. En la Go Developer Survey 2025, los principales usos de la IA fueron los tests unitarios, el boilerplate, el autocompletado, el refactoring y la documentación (Go Developer Survey, 2026).
Buenos candidatos:
- Casos de tests basados en tablas, una vez que hayas escrito los dos primeros a mano
- Struct tags, mapeos JSON y otras traducciones mecánicas
- Parseo de flags de la CLI, carga de configuración y código de pegamento similar
- Migrar un proyecto a una API nueva cuando el patrón ya está claro
- Scripts de un solo uso que borrarás mañana
- Explicar un proyecto o un mensaje de error que no conoces antes de cambiar nada
La misma encuesta recuerda que hay que seguir revisando lo que genera. Solo el 55 % de los desarrolladores de Go estaba satisfecho con sus herramientas de IA, y la queja más común, con un 53 %, era el código que no funciona. Una cuarta parte de los encuestados dijo que preferiría que la IA no interviniera en absoluto en la escritura de código, la mayor resistencia a la IA de todas las tareas de la encuesta (Go Developer Survey, 2026).
Si estás eligiendo un lenguaje para trabajar con IA, Por qué Go es el mejor lenguaje para código escrito por IA explica por qué el lenguaje pequeño de Go, su compilador estricto y sus APIs estables encajan con el código generado. Y si quieres ver qué falla cuando los equipos dejan de revisar ese código, El lado oscuro de las herramientas de IA para programar repasa los datos de 2026 sobre fallos en producción, bases de datos borradas y la sobrecarga de revisiones.
Una regla sencilla: ¿podrías haberlo escrito tú?
Antes de aceptar una sugerencia, hazte una pregunta: ¿podría haber escrito esto yo mismo con un poco más de tiempo?
Si la respuesta es sí, acéptala, léela y sigue adelante. Estás usando la IA como un teclado más rápido, y detectarás lo que haga mal.
Si la respuesta es no, ese es el código que debes escribir a mano, o al menos reconstruir de memoria después de leer la sugerencia. Ahí es donde aprendes, y también donde menos probable es que pilles un bug.
Esto coincide con lo que Microsoft Research y Carnegie Mellon encontraron en una encuesta de 2025 a 319 trabajadores del conocimiento: «una mayor confianza en la IA generativa se asocia con menos pensamiento crítico, mientras que una mayor confianza en uno mismo se asocia con más pensamiento crítico» (Microsoft Research, 2025). Saber que podrías escribir el código tú mismo es lo que te hace seguir leyéndolo con ojo crítico. Si ya usas la IA a diario y quieres conservar esa capacidad, Cómo mantener tus habilidades de programación en forma cuando la IA escribe el código propone una rutina semanal de práctica sin IA.
Dónde encaja LevelUpGo
LevelUpGo gira en torno a la parte de escribir código a mano. Cada lección pone el concepto a la izquierda y un editor real a la derecha, y solo avanzas cuando tu código Go compila y pasa los tests. El editor no tiene autocompletado, así que los errores y los arreglos son tuyos. Empieza con el curso gratuito Go Fundamentals. Cuando te sientas con soltura, el Training Ground tiene ejercicios independientes para mantener la habilidad en forma mientras la IA se encarga del boilerplate en el trabajo.
Si todavía estás decidiendo por dónde empezar, Cómo aprender a programar en 2026 explica cómo usar la IA como tutor en lugar de como atajo, y 10 errores comunes en Go que debes evitar recoge los bugs que conviene saber detectar en el código generado. Para ver qué le pasa a tu aprendizaje cuando la IA piensa por ti, lee No delegues tu cerebro.
Preguntas frecuentes
¿Sigue valiendo la pena aprender a programar si la IA puede escribir código?
Sí. La IA escribe código que a menudo está casi bien, y el 66 % de los desarrolladores dice que esa es su mayor frustración con ella (Stack Overflow, 2025). Detectar y corregir la parte que está mal exige la misma comprensión que escribirlo tú. Hoy, aprender a programar significa saber juzgar el código, no solo producirlo.
¿Usar IA te convierte en peor programador?
Puede hacerlo, si la usas para saltarte el razonamiento. En el estudio de Anthropic de 2026, los desarrolladores que delegaron en la IA mientras aprendían obtuvieron 17 puntos porcentuales menos en comprensión. Los que usaron la IA para hacer preguntas conceptuales y corrigieron sus propios errores obtuvieron resultados casi tan buenos como los que programaron a mano (Anthropic, 2026).
¿Deberían los principiantes usar asistentes de IA para programar?
Úsalos como tutor, no como autocompletado. Pide a un asistente que te explique un error, que compare dos enfoques o que te haga preguntas sobre un concepto. Escribe la solución tú. Desactiva las sugerencias en línea mientras aprendes lo básico, porque aceptar una sugerencia parece progreso, pero se salta la parte que construye la memoria.
¿Qué código hay que revisar siempre línea por línea?
La autenticación, la autorización, los pagos, la validación de entradas y todo lo que construya consultas SQL, HTML o comandos de shell. El código generado por IA sigue fallando los controles de seguridad aproximadamente la mitad de las veces, y las defensas contra cross-site scripting solo los superan el 15 % de las veces (Veracode, 2026).
¿La IA hace realmente más rápidos a los desarrolladores con experiencia?
Probablemente, pero menos de lo que parece. El ensayo de METR de 2025 midió una ralentización del 19 % mientras los desarrolladores creían haber ido un 20 % más rápido. Su seguimiento de 2026 sugiere que las herramientas más nuevas ahora dan una mejora de velocidad modesta, con mucha incertidumbre (METR, 2026). Mide tus propias tareas en lugar de fiarte de la sensación.
Fuentes
- Anthropic, "How AI assistance impacts the formation of coding skills" (2026): https://www.anthropic.com/research/AI-assistance-coding-skills
- METR, "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" (2025): https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, actualización del estudio de mejora de productividad (2026): https://metr.org/blog/2026-02-24-uplift-update/
- Stack Overflow Developer Survey 2025, sección de IA: https://survey.stackoverflow.co/2025/ai
- Veracode, 2025 GenAI Code Security Report: https://www.veracode.com/blog/genai-code-security-report/
- Veracode, Spring 2026 GenAI Code Security update: https://www.veracode.com/blog/spring-2026-genai-code-security/
- Perry et al., "Do Users Write More Insecure Code with AI Assistants?" ACM CCS (2023): https://arxiv.org/abs/2211.03622
- Bastani et al., "Generative AI without guardrails can harm learning," PNAS (2025): https://www.pnas.org/doi/10.1073/pnas.2422633122
- Lee et al., "The Impact of Generative AI on Critical Thinking," CHI (2025): https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/
- Roediger & Karpicke, "Test-Enhanced Learning," Psychological Science (2006): https://journals.sagepub.com/doi/10.1111/j.1467-9280.2006.01693.x
- Slamecka & Graf, "The Generation Effect," Journal of Experimental Psychology: Human Learning and Memory (1978)
- Go Developer Survey 2025 results (2026): https://go.dev/blog/survey2025
