En 2013 publicamos aquí diez consejos para programadores que empiezan. Casi todos siguen valiendo: lee mucho, prueba tu código, no acumules malas prácticas, diviértete. Lo que ha cambiado en estos trece años no es la lista, es una cosa concreta: ahora puedes producir código que funciona sin haber entendido nada. Eso es nuevo, y cambia por dónde hay que tener cuidado.
El problema de fondo, en cuatro cifras
No hace falta opinar sobre si la IA es buena o mala para aprender. Hay datos, y apuntan todos en la misma dirección: la herramienta se ha vuelto universal y la confianza en ella ha bajado.
| Dato | Cifra | De dónde sale |
|---|---|---|
| Programadores que usan o van a usar IA | 84 % | Encuesta de Stack Overflow, 2025 |
| Que confían en que acierta | 33 % | Solo un 3,1 % confía «mucho» |
| Que se topan con respuestas «casi bien, pero no» | 66 % | Su queja número uno |
| Que tardan más en depurar código generado | 45 % | Su queja número dos |
Y hay un dato más incómodo. En 2025, METR hizo un experimento con dieciséis programadores veteranos trabajando sobre sus propios proyectos, 246 tareas reales repartidas al azar entre «con IA» y «sin IA». Esperaban ir un 24 % más rápido con ella. Tardaron un 19 % más. Y lo más llamativo: al terminar seguían creyendo que habían ido un 20 % más rápido.
Los dos bucles
Aquí está todo el asunto. Los dos bucles producen código que funciona. En el primero el proyecto avanza y tú no; en el segundo avanzan los dos. La diferencia no es usar o no usar la IA, sino si llegas a ella con una pregunta formada o sin ella.
Diez consejos
1. Escribe a mano hasta que el patrón te salga solo
Un bucle, una condición, abrir un archivo, recorrer una lista. Mientras eso no te salga sin pensar, escríbelo tú aunque tardes diez veces más. No es masoquismo: es que lo que no has escrito nunca tampoco sabrás leerlo después, y vas a pasarte la vida leyendo código. Cuando el patrón ya sea aburrido, delégalo sin remordimiento.
2. Pide explicaciones, no soluciones
«Escríbeme una función que ordene esta lista» te deja donde estabas. «Explícame por qué mi función devuelve la lista vacía» te deja mejor. Es la misma herramienta y el mismo minuto, y el resultado para ti es completamente distinto.
Un truco que funciona muy bien: pídele que critique tu código en lugar de escribirlo. «¿Qué le ves mal a esto?» suele dar más que cualquier cosa que te genere de cero.
3. Ejecuta todo. Siempre. Sin excepción
Que el código tenga buen aspecto no significa nada. Esta guía misma sale de un sitio donde todo lo que se publica se compila y se ejecuta antes, y esa costumbre ha pillado cosas que ninguna lectura habría pillado.
4. Desconfía de las versiones y de los nombres
Es el fallo más frecuente y el más silencioso: la IA te da una versión de biblioteca o un nombre de función que suena perfectamente razonable y no existe, o existía hace dos años. No miente a propósito; reproduce lo que vio.
Otro caso de aquí: en una lección de Rust apareció una dependencia con la versión 0.9.2. Parecía correcta. La versión real era la 0.10.3, y en medio había una función que se había mudado de sitio, así que el ejemplo no compilaba. La regla que salió de ahí es sencilla: las versiones se preguntan a la herramienta del lenguaje —cargo add, npm view, pip index—, nunca de memoria. Ni de la tuya ni de la suya.
5. Aprende a depurar, que es lo que peor hace
Un 45 % de los programadores dice que depurar código generado le lleva más tiempo, y tiene sentido: para arreglar algo hay que tener un modelo mental de cómo funciona, y si el código no lo escribiste tú, no lo tienes.
Depurar no es pedirle a la IA que arregle el error. Es leer el mensaje entero —entero, no la primera línea—, reducir el problema hasta el caso más pequeño que falla, e imprimir valores hasta encontrar dónde deja de ser lo que creías. Esa habilidad es la que separa a quien avanza de quien se queda bloqueado, y es la única de esta lista que no se puede delegar.
6. Aprende la terminal y Git antes que ningún framework
Toda herramienta de IA da por hecho que sabes moverte por un sistema de archivos, leer un error en una consola y deshacer un cambio. Si no, cada sugerencia te deja más perdido que antes. Son dos tardes de inversión y valen para el resto de tu carrera: aquí tienes los comandos de Linux que de verdad se usan y las órdenes de Git.
Lo de Git tiene un motivo extra ahora: si vas a aceptar código que no escribiste, más te vale poder volver atrás con una orden.
7. El contexto lo pones tú
La IA sabe de código; de tu problema no sabe nada. No sabe qué datos vas a recibir de verdad, qué pasa si el usuario deja el campo vacío, ni por qué en tu empresa las fechas se guardan así. Cuando le pides algo sin contarle eso, rellena los huecos con lo más común, que casi nunca es tu caso.
De ahí sale el consejo práctico: antes de pedir nada, escribe en una frase qué entra, qué tiene que salir y qué pasa cuando algo va mal. Si no sabes escribir esa frase, el problema no es la herramienta.
8. No aceptes nada que no sabrías defender
La prueba es sencilla: si alguien te preguntara por qué esa línea está ahí, ¿sabrías contestar? Si no, no la publiques. No porque esté mal —puede estar perfecta—, sino porque el día que falle vas a estar tú delante y no vas a tener por dónde empezar.
9. Termina cosas, aunque sean pequeñas
Con la IA es facilísimo empezar diez proyectos ambiciosos y no acabar ninguno, porque los primeros pasos salen gratis y los últimos no. Y lo que de verdad enseña está al final: el caso raro, el despliegue, el error que solo aparece con datos reales, la parte aburrida de dejarlo presentable.
Un programa pequeño y terminado enseña más que tres grandes a medias. Esto no es nuevo: ya estaba en la lista de 2013 y sigue siendo verdad.
10. Lee código que no sea tuyo
Entra en un proyecto de código abierto que uses y lee cómo está hecho. Verás decisiones que no se te habrían ocurrido y, sobre todo, verás cómo se organiza algo que lleva años vivo, que es exactamente lo que ninguna herramienta te va a enseñar de un tirón.
Aquí la IA sí ayuda mucho, y de la forma correcta: como lector infinito al que puedes preguntarle «¿qué hace este archivo?» sin que se canse.
Lo que está pasando con el código de todos
Hay una razón para insistir tanto en entender lo que se acepta, y no es moral: se está midiendo en los repositorios reales. La empresa GitClear analizó 623 millones de cambios de código entre 2023 y 2026, y el patrón es consistente.
| Qué mide | 2023 | 2026 |
|---|---|---|
| Bloques de código duplicados (por millón de líneas) | 40,3 | 73,0 |
| Copiar y pegar dentro de un mismo commit | 9,4 % | 15,7 % |
| Líneas movidas, es decir, refactorizadas | 13 % | 3,8 % |
| Llamadas a funciones de otros archivos (reutilización) | 343 | 223 |
Se duplica más y se reordena mucho menos. Los propios autores piden no leerlo como «la IA escribe mal»: lo que dicen es que el flujo de trabajo habitual con IA premia lo inmediato y lo visible, mientras «grava en silencio lo invisible y lo aplazado». Reordenar código que ya funciona es trabajo invisible, y es el primero que desaparece cuando generar una versión nueva cuesta diez segundos.
Para alguien que empieza esto se traduce en algo muy concreto: la habilidad que va a escasear no es escribir código, es ordenarlo.
Lo que no ha cambiado
Conviene cerrar por donde empezamos. De aquella lista de 2013, lo que sigue intacto es casi todo: leer mucho, no adoptar una tecnología solo porque es nueva pero probarlas igualmente, compartir lo que aprendes, cuidarte y pasarlo bien. Nada de eso depende de qué herramienta tengas abierta.
Y hay algo que la irrupción de la IA ha puesto más claro todavía: el trabajo nunca fue teclear. Era entender un problema lo bastante bien como para explicárselo a una máquina sin ambigüedades. Eso es lo que estás aprendiendo cuando aprendes a programar, y es exactamente lo que no se delega, porque es lo único que hay que saber para poder delegar el resto.
Sobre la imagen de portada. Es un montaje sobre la fotografía «Learning to Code», de Preply.com Images, bajo licencia CC BY 2.0, vía Wikimedia Commons.
Las cifras de este artículo están comprobadas contra sus fuentes originales: la encuesta a desarrolladores de Stack Overflow de 2025 (33 662 respuestas en la pregunta sobre confianza), el experimento de METR con programadores veteranos y el informe de GitClear sobre mantenibilidad. Los dos ejemplos de errores reales salen de artículos publicados en este sitio, donde todo el código se ejecuta antes de publicarse. Si quieres el otro lado del asunto, está qué cambia en el oficio cuando escribir código deja de ser el centro.