Cómo mantener tus habilidades de programación en forma cuando la IA escribe el código

Q: ¿Cómo practico si mi equipo espera que produzca a la velocidad de la IA?

Practica fuera del camino crítico. Para el hábito de depurar primero, elige bugs y tickets que no estén bloqueando a nadie, y resuelve el problema a mano en tu tiempo libre o con el presupuesto de formación, si tu empresa tiene uno. Revisar diffs y escribir los tests tú mismo encaja en el trabajo normal y apenas te frena. Si tu equipo solo mide la producción, habla con tu responsable sobre la calidad de las revisiones y la preparación para las guardias. Las dos dependen de las mismas habilidades.

Q: ¿Los ingenieros sénior también pierden habilidades por la IA?

Sí. La experiencia no te protege. Los pilotos del estudio de aviación y los médicos del estudio de colonoscopias eran profesionales con experiencia, y los dos grupos mostraron habilidades más débiles allí donde la automatización había asumido parte del trabajo (Casner et al., 2014, Budzyń et al.00133-5), 2025). Los sénior parten con más habilidad que perder, y las habilidades de razonamiento son las que hay que vigilar.

Q: ¿Basta con revisar código de IA para mantener mis habilidades?

Por sí solo, no. Revisar se basa en el reconocimiento, que es más fácil que producir una solución tú mismo. Puedes reconocer una respuesta correcta mucho después de haber perdido la capacidad de escribirla. Combina la revisión con práctica regular escribiendo y depurando código desde cero.

Q: ¿Se pueden recuperar las habilidades perdidas por la IA?

La investigación sobre esto es escasa, así que nadie puede prometerlo. Los estudios anteriores midieron la habilidad en un momento concreto, no la recuperación. Lo que sí muestran es que las habilidades que la gente siguió usando se mantuvieron intactas, como el vuelo manual de los pilotos (Casner et al., 2014). La respuesta práctica es empezar con las comprobaciones de arriba, encontrar la habilidad más débil y practicar esa primero.

Para mantener tus habilidades de programación en forma, practica a propósito y sin asistente las partes del trabajo que ahora hace la IA por ti. Para la mayoría de los ingenieros eso significa depurar un problema antes de pedir ayuda, leer código que no escribiste, resolver un problema pequeño partiendo de un archivo en blanco y escribir los tests tú mismo. Yo empezaría con una o dos horas a la semana y lo mantendría con regularidad. El resto de la semana puedes usar la IA todo lo que quieras.

Resumen rápido

Las habilidades de razonamiento se pierden más que las manuales. Los pilotos acostumbrados a volar con automatización conservaban su capacidad de pilotar a mano, pero tenían más dificultades con la navegación y la detección de fallos (Casner et al., Human Factors, 2014). En programación, lo más parecido es depurar y leer código.
La pérdida de habilidades puede aparecer en cuestión de meses. En un estudio observacional, los médicos que usaban IA en las colonoscopias detectaron menos lesiones precancerosas cuando se apagaba la IA: un 22,4 %, frente al 28,4 % anterior (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025).
Ponte a prueba con regularidad. ¿Puedes explicar el último diff que fusionaste? ¿Puedes depurar un test que falla durante 20 minutos sin escribir un prompt? Si no, esas son las habilidades que tienes que practicar.
Basta con una rutina semanal. Resuelve a mano un problema pequeño, depura antes de preguntar a la IA, revisa los diffs de la IA como si los hubiera escrito un junior, lee código fuente de la biblioteca estándar y escribe los tests tú mismo.
Pregúntale a la IA «por qué», no «arréglalo». Primero predice la respuesta y luego compara. Los ingenieros que aprendían una biblioteca nueva y usaron la IA para hacer preguntas la aprendieron casi igual de bien que quienes programaron a mano. Los que le pasaron el problema entero fueron los que menos aprendieron (Anthropic, 2026).

¿Qué habilidades se pierden primero cuando la IA escribe tu código?

Las primeras en perderse son aquellas en las que tienes que razonar algo, como depurar, leer código y sopesar alternativas. Recordar la sintaxis se pierde mucho más despacio.

La aviación tiene un caso parecido. En un estudio de 2014, 16 pilotos de aerolínea volaron un simulador de Boeing 747-400 y se evaluó su capacidad de pilotarlo a mano. Sus habilidades de vuelo manual estaban «en su mayoría intactas». Los problemas aparecieron en las tareas de razonamiento: saber dónde estaba el avión sin la pantalla del mapa, decidir qué hacer a continuación y darse cuenta de cuándo había fallado un instrumento (Casner et al., Human Factors, 2014). Según los investigadores, los pilotos conservan esas habilidades si siguen supervisando activamente la automatización.

La medicina encontró algo parecido en 2025. En cuatro centros de endoscopia de Polonia, se midió a médicos que venían usando una herramienta de detección con IA en colonoscopias hechas sin ella. Su tasa de detección de adenomas bajó del 28,4 % antes de introducir la IA al 22,4 % después (Budzyń et al., Lancet Gastroenterology & Hepatology, 2025). Fue un estudio observacional, no un ensayo aleatorizado, pero la caída se produjo en cuestión de meses.

En el software, eso apunta a cinco habilidades.

Dos columnas. Se pierde sin práctica: depurar sin asistente, leer código desconocido, recordar APIs de memoria, sopesar alternativas de diseño de sistemas, estimar cuánto dura el trabajo. Importa más ahora: revisar diffs que no escribiste, escribir especificaciones claras, tests y casos límite, arquitectura y límites entre componentes.

Depurar

Depurar es la habilidad que más hay que vigilar. En el ensayo de Anthropic de 2026, el grupo que programó a mano se encontró con más errores que el grupo con IA, y los investigadores creen que resolver esos errores fue lo que desarrolló su capacidad de depuración (Anthropic, 2026). Si un asistente te arregla cada error, nunca haces esa práctica.

Leer código desconocido

Cuando un agente te explica un proyecto, no construyes tu propio mapa de él. Eso no es un problema hasta que la explicación está mal o el agente no está disponible durante una incidencia. El análisis de GitClear sobre 623 millones de cambios de código encontró que las llamadas a código existente bajaron de 343 a 223 por cada mil líneas modificadas entre 2023 y 2026 (GitClear, 2026). Reutilizar menos encaja con leer menos lo que ya existe.

Conocer las APIs de memoria

Recordar importa menos que las otras habilidades de esta lista, pero sigues necesitando algo de memoria. No hace falta que te sepas todas las funciones de strings. Sí necesitas saber que context.WithTimeout devuelve una función de cancelación que tienes que llamar, y que http.Error no hace que tu handler retorne. Sin eso, no vas a notar cuándo una sugerencia está mal.

Diseño de sistemas y compromisos

La IA te propondrá un diseño si se lo pides. Elegir entre dos diseños razonables requiere criterio, y el criterio se construye tomando decisiones y viviendo con sus consecuencias. Si el agente elige la cola, el esquema y la política de reintentos, nunca descubres cuáles de tus intuiciones eran acertadas.

Estimar

Si un asistente hace parte del trabajo, tu idea de cuánto tardan las cosas puede desviarse. En el ensayo de METR de 2025, los desarrolladores con experiencia tardaron un 19 % más con IA, pero después creían que los había hecho un 20 % más rápidos (METR, 2025). Si tu propia percepción de la velocidad puede equivocarse tanto, tus estimaciones también.

¿Cómo saber si tus habilidades se están oxidando?

Lo descubres poniéndote a prueba sin el asistente, porque mientras trabajas con él cuesta notarlo. Microsoft Research y Carnegie Mellon encontraron que los trabajadores del conocimiento que confiaban más en la IA decían pensar de forma menos crítica sobre sus resultados (Lee et al., CHI, 2025).

Haz estas comprobaciones una vez al mes:

Explica tu último diff fusionado. Elige un pull request reciente que haya escrito sobre todo la IA. Explica a un compañero, o en voz alta, por qué está ahí cada cambio. Si no puedes explicar un cambio, en realidad no lo conoces.
Depura durante 20 minutos sin escribir un prompt. Toma el siguiente test que falle o el siguiente informe de bug y trabaja en él solo con logs, un depurador y el código fuente. Fíjate en si recurres al asistente en los dos primeros minutos.
Escribe una función pequeña partiendo de un archivo en blanco. Parsea un archivo de configuración, reintenta una llamada HTTP con backoff o elimina duplicados de un slice manteniendo el orden. Comprueba si recuerdas las llamadas de la biblioteca estándar o si tienes que buscar cada una.
Predice antes de ejecutar. Antes de ejecutar un test, apunta si va a pasar. Si falla, apunta qué dirá el error. Si te equivocas a menudo, tu modelo mental del código se ha alejado del código real.
Estima y luego mide. Estima cuánto va a durar una tarea y compáralo con lo que tardaste de verdad. Si la diferencia crece, probablemente has perdido la noción de en qué se va el tiempo.

Ninguna de estas comprobaciones lleva mucho tiempo. La que te resulte incómoda te indica qué habilidad tienes que practicar.

¿Qué diferencia hay entre delegar trabajo y delegar tu forma de pensar?

Delegar trabajo es pasarle a la IA tareas que ya entiendes, para poder dedicar tu atención a otra cosa. Delegar tu forma de pensar es pasarle tareas que no entiendes, para no tener que entenderlas nunca. Lo primero es una parte normal de la ingeniería. Lo segundo es donde se pierden las habilidades.

El ensayo de Anthropic encontró que la forma en que la gente usaba el asistente importaba más que el hecho de usarlo, y los investigadores concluyeron que el esfuerzo cognitivo, «e incluso quedarse atascado de forma dolorosa», probablemente es importante para dominar algo (Anthropic, 2026). ¿Todavía deberías escribir código a mano? repasa qué patrones de uso obtuvieron buenos resultados.

La investigación sobre el aprendizaje explica por qué. Robert y Elizabeth Bjork llaman a este tipo de esfuerzo una «dificultad deseable»: en el momento parece más lento, pero produce un mejor aprendizaje a largo plazo (Bjork & Bjork, 2011). Uno de sus ejemplos es el espaciado. La práctica repartida a lo largo de semanas se fija mejor que la misma cantidad concentrada en una sola sesión, y por eso la rutina de abajo es semanal. Recordar algo también funciona mejor que releerlo (APS Observer on Roediger & Karpicke, 2006), un estudio que ¿Todavía deberías escribir código a mano? trata con más detalle.

Para saber cuál de las dos hiciste, pregúntate una semana después: ¿podría reescribir este código sin mirarlo? Si puedes, delegaste trabajo que entiendes. Si no, vuelve atrás y apréndelo antes de construir nada encima.

Una rutina semanal de práctica sin IA

La rutina de abajo lleva entre una y dos horas a la semana. Puedes repartirla o hacerla de una sola vez. Lo difícil es mantenerla durante meses.

Resuelve a mano un problema pequeño

Una vez a la semana, abre un archivo en blanco con el asistente desactivado y resuelve un problema pequeño y real. Elige algo cercano a tu trabajo: un rate limiter, un parser de CSV que maneje campos entre comillas, un worker pool que se detenga en el primer error. Limítalo a entre 30 y 45 minutos. Lo que practicas es pasar de un archivo en blanco a código que funciona, así que el problema puede ser pequeño.

Si quieres problemas que vengan con tests, el Training Ground de LevelUpGo tiene ejercicios de Go independientes pensados justo para esto.

Depura antes de preguntar a la IA

Cuando algo se rompa, date un tiempo fijo, por ejemplo 20 minutos, antes de preguntar al asistente. Formula una hipótesis, reproduce el bug, mide y solo entonces pregunta.

Aquí tienes un bug para practicar. Un servicio obtiene tipos de cambio de una API externa lenta y se rinde a los 10 milisegundos:

example.gogo
package main

import (
	"context"
	"errors"
	"fmt"
	"os"
	"runtime"
	"runtime/pprof"
	"time"
)

type Rate struct {
	Currency string
	Value    float64
}

func fetchRate(currency string) Rate {
	time.Sleep(50 * time.Millisecond) // a slow upstream API
	return Rate{Currency: currency, Value: 1.08}
}

func rateWithTimeout(ctx context.Context, currency string) (Rate, error) {
	ctx, cancel := context.WithTimeout(ctx, 10*time.Millisecond)
	defer cancel()

	result := make(chan Rate)
	go func() {
		result <- fetchRate(currency)
	}()

	select {
	case r := <-result:
		return r, nil
	case <-ctx.Done():
		return Rate{}, errors.New("rate lookup timed out")
	}
}

func main() {
	timeouts := 0
	for range 100 {
		if _, err := rateWithTimeout(context.Background(), "EUR"); err != nil {
			timeouts++
		}
	}
	fmt.Println("timeouts:", timeouts)
	time.Sleep(100 * time.Millisecond)
	runtime.GC()
	fmt.Println("goroutines:", runtime.NumGoroutine())
	pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
}

En producción el síntoma es un crecimiento lento de la memoria, no un fallo. Lo primero que hay que medir es el número de goroutines. Go 1.27 dejó disponible para todos el perfil goroutineleak (notas de la versión de Go 1.27), así que el runtime puede señalarte la fuga. Al ejecutar el programa con Go 1.27 se imprime:

example.texttext
timeouts: 100
goroutines: 101
goroutineleak profile: total 100
100 @ 0x1048c59a8 0x10485e854 0x10485e468 0x10491c5ac 0x1048cbc74
#	0x10491c5ab	main.rateWithTimeout.func1+0x5b	./main.go:29

Las 100 consultas agotaron el tiempo, y siguen vivas 100 goroutines además de main. La línea 29 es result <- fetchRate(currency). Cada consulta que agota el tiempo deja atrás una goroutine bloqueada en un envío que nadie va a recibir nunca, porque rateWithTimeout ya ha retornado. La solución es un buffer de uno, para que el envío siempre se complete:

example.gogo
result := make(chan Rate, 1)

Con ese cambio, el mismo programa imprime goroutines: 1 y goroutineleak profile: total 0. Probablemente un asistente encontraría este bug enseguida. La práctica está en encontrarlo tú, porque la próxima fuga puede estar en una biblioteca que el asistente nunca ha visto, durante una incidencia en la que estás solo. La palabra clave chan en Go explica con más detalle las reglas de los channels que hay detrás de este bug.

Revisa el diff de la IA como si lo hubiera escrito un junior

Cuando un agente abra un pull request, léelo como leerías uno de un compañero nuevo que es listo pero no conoce tu sistema. No te preguntes solo si parece correcto. Pregúntate qué ha supuesto. Revisa los caminos de error, el manejo del context, los bloqueos y lo que pasa en la segunda llamada.

La confianza en estas herramientas ya es baja. En la encuesta de Stack Overflow de 2025, el 84 % de los encuestados usaba o pensaba usar herramientas de IA, pero solo el 3,1 % confiaba mucho en su precisión (Stack Overflow, 2025). El equipo DORA de Google encontró que la IA no arregla un equipo. «Amplifica lo que ya existe» (DORA 2025, 2025). Si quieres ver qué pasa cuando la revisión falla, El lado oscuro de las herramientas de IA para programar repasa los datos de 2026.

Lee código fuente de la biblioteca estándar

Una vez a la semana, lee una función de la biblioteca estándar de Go. Está escrita con cuidado, y los comentarios de documentación suelen explicar las decisiones de diseño. No hace falta instalar nada:

example.bashbash
go doc -src net/http.Error

example.gogo
// Error replies to the request with the specified error message and HTTP code.
// It does not otherwise end the request; the caller should ensure no further
// writes are done to w.
// The error message should be plain text.
//
// Error deletes the Content-Length header,
// sets Content-Type to “text/plain; charset=utf-8”,
// and sets X-Content-Type-Options to “nosniff”.
// This configures the header properly for the error message,
// in case the caller had set it up expecting a successful output.
func Error(w ResponseWriter, error string, code int) {
	h := w.Header()
	// ...
	h.Del("Content-Length")
	h.Set("Content-Type", "text/plain; charset=utf-8")
	h.Set("X-Content-Type-Options", "nosniff")
	w.WriteHeader(code)
	fmt.Fprintln(w, error)
}

La segunda línea del comentario explica un bug habitual: http.Error escribe una respuesta, pero no detiene tu handler. Si te olvidas del return después, el handler sigue ejecutándose. Este handler tiene exactamente ese error en la rama que decodifica el JSON:

example.gogo
type Order struct {
	ID       string `json:"id"`
	Quantity int    `json:"quantity"`
}

func createOrder(w http.ResponseWriter, r *http.Request) {
	var o Order
	if err := json.NewDecoder(r.Body).Decode(&o); err != nil {
		http.Error(w, "invalid JSON", http.StatusBadRequest)
	}
	if o.Quantity <= 0 {
		http.Error(w, "quantity must be positive", http.StatusBadRequest)
		return
	}
	w.WriteHeader(http.StatusCreated)
	json.NewEncoder(w).Encode(o)
}

Sugerencias como esta pasan una revisión rápida porque la segunda rama parece correcta. Cuando ya has leído el código fuente, el return que falta salta a la vista. Para seguir, prueba con sync.Once.Do, errors.Is, context.WithCancel y http.MaxBytesReader.

Escribe los tests tú mismo

Deja que el asistente escriba la implementación si quieres, pero escribe tú los casos de test. Decidir qué cuenta como correcto es la parte del trabajo que no deberías delegar. Este es un test basado en tablas para el handler anterior:

example.gogo
func TestCreateOrder(t *testing.T) {
	tests := []struct {
		name     string
		body     string
		wantCode int
		wantBody string
	}{
		{"valid order", `{"id":"A1","quantity":2}`, http.StatusCreated, `{"id":"A1","quantity":2}` + "\n"},
		{"zero quantity", `{"id":"A1","quantity":0}`, http.StatusBadRequest, "quantity must be positive\n"},
		{"malformed JSON", `{"id":`, http.StatusBadRequest, "invalid JSON\n"},
	}
	for _, tt := range tests {
		t.Run(tt.name, func(t *testing.T) {
			req := httptest.NewRequest(http.MethodPost, "/orders", strings.NewReader(tt.body))
			rec := httptest.NewRecorder()

			createOrder(rec, req)

			res := rec.Result()
			body, _ := io.ReadAll(res.Body)
			if res.StatusCode != tt.wantCode {
				t.Errorf("status = %d, want %d", res.StatusCode, tt.wantCode)
			}
			if string(body) != tt.wantBody {
				t.Errorf("body = %q, want %q", body, tt.wantBody)
			}
		})
	}
}

example.texttext
--- FAIL: TestCreateOrder (0.00s)
    --- FAIL: TestCreateOrder/malformed_JSON (0.00s)
        handler_test.go:35: body = "invalid JSON\nquantity must be positive\n", want "invalid JSON\n"
FAIL

La comprobación del código de estado pasa, porque gana la primera llamada a WriteHeader y la respuesta sigue siendo un 400. Solo la comprobación del cuerpo detecta el bug. Un servidor real también registraría http: superfluous response.WriteHeader call, pero solo si alguien lee los logs. Escribir esa aserción sobre el cuerpo es una decisión sobre lo que podría salir mal, y ese criterio es la habilidad que estás practicando. Con el return añadido, los tres casos pasan.

¿Cómo usar la IA para que te enseñe en lugar de sustituirte?

Usa la IA para poner a prueba y explicar tu razonamiento, y piensa tú primero. Cinco hábitos ayudan con eso:

Predice primero y luego compara. Antes de pedir una solución, escribe tu propio enfoque en una o dos frases, o haz un boceto del código. Después pregunta al asistente y compara. Las diferencias te muestran lo que no sabías.
Pregunta «por qué» en vez de «arréglalo». «¿Por qué esta goroutine no termina nunca?» te da una explicación que puedes comprobar. «Arregla esto» te da un parche que aceptarás sin aprender nada.
Pide pistas. Dile al asistente que estás practicando y que quieres una pista cada vez. La mayoría te seguirá el juego.
Pídele que te examine. Después de una sesión, pídele tres preguntas sobre el código que acabas de cambiar. Si no sabes responderlas, vuelve a leer el código.
Reescribe de memoria. Cuando aceptes código generado que no entendiste del todo, ciérralo y vuelve a escribirlo más tarde ese mismo día. Los puntos donde te atascas son justo lo que no aprendiste.

La misma idea se aplica cuando aprendes desde cero. Cómo aprender a programar en 2026 explica cómo usar la IA como tutor si estás empezando.

¿Qué habilidades importan más ahora, y no menos?

Las habilidades que necesitas para dirigir a la IA y comprobar su trabajo valen ahora más que antes.

La más evidente es revisar. Los agentes pueden abrir pull requests más rápido de lo que un equipo puede leerlos, y alguien tiene que seguir revisando cada uno y decidir cuáles se fusionan.

Otra es escribir especificaciones. Una descripción clara del problema, las restricciones y los casos límite te da mejores resultados de un agente, y escribirla te obliga a pensar el problema a fondo.

Los tests importan más cuando no escribiste tú el código. Con ellos le dices a un agente qué significa correcto y lo pillas cuando se equivoca, así que los tests basados en tablas, el fuzzing (Go fuzzing tutorial) y el race detector se usan más.

La última es la arquitectura. Los agentes trabajan bien dentro de límites claros, pero decidir dónde van esos límites, qué paquete es responsable de qué y qué interfaces se mantienen estables sigue siendo tu trabajo.

La elección del lenguaje ayuda con las cuatro. El compilador estricto de Go, su lenguaje pequeño y sus herramientas integradas detectan muchos errores del código generado antes de la revisión, algo que Por qué Go es el mejor lenguaje para código escrito por IA explica en detalle. ¿Vale la pena aprender Go en 2026? trata el lado profesional de esa elección.

Dónde encaja LevelUpGo

LevelUpGo es un lugar donde hacer la parte de la rutina sin IA. Cada lección pone el concepto a la izquierda y un editor real a la derecha, sin autocompletado, y solo avanzas cuando tu código Go compila y pasa los tests. El curso Go Basics, que puedes empezar gratis, arranca desde los fundamentos. En Professional Go Testing practicas escribir tú mismo tests basados en tablas, y Concurrency Fundamentals cubre goroutines, channels y cancelación, el código que más merece la pena saber depurar a mano.

Preguntas frecuentes

¿Cuánto tiempo debería programar sin IA cada semana?

Yo empezaría con una o dos horas a la semana y lo mantendría durante meses. La investigación sobre el aprendizaje favorece las sesiones cortas y espaciadas frente a las largas y ocasionales (Bjork & Bjork, 2011). Resolver a mano un problema pequeño, depurar un bug antes de preguntar a la IA y leer una función de la biblioteca estándar cada semana cubre las habilidades más expuestas.

¿Cómo practico si mi equipo espera que produzca a la velocidad de la IA?

Practica fuera del camino crítico. Para el hábito de depurar primero, elige bugs y tickets que no estén bloqueando a nadie, y resuelve el problema a mano en tu tiempo libre o con el presupuesto de formación, si tu empresa tiene uno. Revisar diffs y escribir los tests tú mismo encaja en el trabajo normal y apenas te frena. Si tu equipo solo mide la producción, habla con tu responsable sobre la calidad de las revisiones y la preparación para las guardias. Las dos dependen de las mismas habilidades.

¿Los ingenieros sénior también pierden habilidades por la IA?

Sí. La experiencia no te protege. Los pilotos del estudio de aviación y los médicos del estudio de colonoscopias eran profesionales con experiencia, y los dos grupos mostraron habilidades más débiles allí donde la automatización había asumido parte del trabajo (Casner et al., 2014, Budzyń et al., 2025). Los sénior parten con más habilidad que perder, y las habilidades de razonamiento son las que hay que vigilar.

¿Basta con revisar código de IA para mantener mis habilidades?