Cómo programar con IA sin volverte dependiente de ella
Escuchar el artículo (experimental) · 08:16

Se ha convertido, casi sin ruido, en una de las preguntas que más a menudo se hace un desarrollador en voz alta: ¿cómo programo sin volverme completamente dependiente de la IA? Quienes la hacen suelen ser los que menos esperarías. Un estudiante de informática que aprueba los exámenes de teoría pero que ha construido todos sus proyectos reales con un modelo al lado, y que ahora no es capaz de escribir una función sin recurrir a él. Un ingeniero en activo que se da cuenta, una tarde cualquiera, de que lleva semanas sin teclear una sola línea por su cuenta. La respuesta de siempre llega rápida y casi unánime, y acierta con exactamente un tipo de persona y se equivoca con casi todos los que preguntan.
La respuesta es: quitar la muleta.
Cancela la suscripción. Desinstálala. Programa sin conexión, como si fuera 2010. Las metáforas llegan puntuales, y algunas son buenas. Ruedines atornillados a la única bici que tienes. Copiar en un examen. Una calculadora. La versión más afilada: la IA era una silla de ruedas que nunca necesitaste, tus músculos de programador se han atrofiado, y la única forma de volver a fortalecerlos es cargar tú con el peso.
Si eres estudiante y estás aprendiendo los fundamentos, ese consejo es correcto y no pienso suavizarlo. No puedes construir un modelo mental de un problema si una máquina te construye la solución cada vez. La versión más cuidadosa de esa advertencia señala el peligro real con precisión: no está en usar la IA, está en dejar que la IA se salte la parte en la que tu cerebro construye el modelo del problema. Para esa persona, la muleta tiene que caer, porque lo importante del ejercicio nunca fue el programa que funciona. Eran las conexiones que desarrollas mientras lo construyes.
Pero la mayoría de quienes hacen esta pregunta no van a convertirse en personas que jamás tocan la IA. Van a convertirse en profesionales cuyo trabajo consiste, cada vez más, en dirigirla. Y para ellos, «usa menos IA» no es una respuesta. Es una táctica dilatoria que aplaza la verdadera pregunta un año.
La verdadera causa
Esto es lo que se les escapa a las metáforas de la muleta.
La dependencia no la provoca que la IA escriba tu código. La provoca que la IA escriba código que tú nunca convertiste en comprensión.
Conviene que diga desde dónde hablo, porque no es desde el bando de la abstinencia. He pasado los últimos meses construyendo herramientas de IA: un pipeline que convierte una frase en un plan y abre sus propios pull requests, un plano de control que gobierna flotas de agentes. Uso estas herramientas todos los días y no voy a darle a nadie una lección sobre pureza. Pero todas ellas se sostienen sobre una sola regla que no tiene nada que ver con cuánta IA uses: nadie hace merge de lo que no sabe explicar.
Esa regla es toda la diferencia entre usar una herramienta y depender de ella. Por debajo de las metáforas no deja de aflorar un argumento más duro. Imagina al desarrollador que solo usa IA llevando código generado a un sistema de producción real, viéndolo romperse y teniendo que arreglar un código que nunca entendió. Y el alarde tan popular de que puedes hacer que la IA «construya la aplicación entera sin que yo aporte nada» se cae en cuanto lo tocas: sigues aportando las restricciones y revisando el resultado, así que sí estás aportando, y si de verdad no lo estás revisando, eres tú quien está enviando a producción los agujeros de seguridad. El coste de la dependencia no es haber usado la IA. Es que no puedes arreglar, a las dos de la madrugada, eso que lleva tu nombre en el commit.
Por qué falla la analogía de la calculadora
La comparación a la que recurre la gente es la calculadora. Las calculadoras no impidieron que nadie aprendiera aritmética, así que ¿por qué iba la IA a impedir que alguien aprenda a programar?
Porque una calculadora devuelve una respuesta en la que puedes confiar. Siete por ocho son cincuenta y seis, la entiendas o no. Un LLM devuelve una respuesta que tienes que verificar. Esa es toda la diferencia, y apunta justo en dirección contraria al consuelo que se ofrece: significa que comprender importa más en la era de la IA, no menos. La calculadora te permitió dejar de entender la aritmética porque nunca se equivocaba. El modelo de lenguaje no puede permitirte dejar de entender el código, porque tú eres su revisor, y un revisor que no entiende lo que lee no está revisando nada en absoluto.
La disciplina que de verdad funciona
Así que el objetivo no es menos IA. Es conservar la posesión de aquello que la dependencia te arrebata. En la práctica se reduce a una lista corta, y casi toda ella hace eco de los mejores consejos que cualquiera daría.
Escribe a mano la primera versión. Construye tú la versión fea y lenta, y luego deja que la IA la compare, la critique o la refactorice. Pelearte con el problema no es una fricción que estorba al aprendizaje. Es el lugar donde se forma el modelo del problema.
Úsala como el sénior que se sienta a tu lado, no como tus manos. La forma más útil de decirlo es un mentor, no un programador becario: cuestiona lo que te da, exígele los enlaces y luego ve a leerte tú la documentación. En el momento en que se convierte en tus manos en lugar de en tu consejero, has dejado de ser dueño de la habilidad y has empezado a alquilar el resultado.
Nunca hagas merge de lo que no sabes explicar. Esa es toda la regla, y se puede hacer cumplir. Si no eres capaz de explicarle a un compañero por qué funciona el código generado, todavía no es tuyo. Es un riesgo que has firmado con tu nombre.
Haz que la revisión sea real. Escribí en otra entrada que, después de suficientes aprobaciones, dejas de leer, y una puerta que no atraviesas leyendo no es una puerta. Lo mismo vale para una sola persona frente al teclado: el diff que aceptas sin entender es exactamente la línea donde empieza la dependencia.
La solución de compromiso más lúcida que he oído describir a nadie es una barra de pesas: escribir y depurar todo a mano, salvo con una fecha límite encima o para scripts desechables, donde echas mano de la IA sabiendo perfectamente que genera deuda técnica y te vuelve un poco más tonto. Esa postura me gusta más que cualquier pureza. El objetivo nunca fue fingir que la IA no existe. Es saber exactamente qué has canjeado y poder recomprarlo.
Qué es en realidad ese músculo
Quienes te dicen que canceles la suscripción están protegiendo algo real: la fuerza que solo se construye haciendo tú mismo la parte difícil. Tienen razón en que se construye a mano, y razón en que se atrofia cuando una máquina carga con el peso por ti.
Pero el músculo que impide que un desarrollador en activo se vuelva dependiente no es la capacidad de producir código sin ayuda. Es el criterio para saber cuándo la ayuda se equivoca. Ese criterio se gana igual que se gana cualquier otro: entendiendo lo que escribió la máquina, cada vez, sin excepción, antes de que pase a ser tuyo.
Así que usa toda la IA que quieras. Solo que nunca envíes una línea que no habrías sido capaz de detectar.
Preguntas que responde este artículo
¿Cómo programo con IA sin volverme dependiente de ella?
No usándola menos, sino conservando la posesión de la comprensión: escribe a mano la primera versión fea, porque ahí es donde se forma el modelo del problema, usa la herramienta como el sénior que se sienta a tu lado y no como tus manos, y nunca hagas merge de lo que no sabes explicar. La dependencia empieza en el diff que aceptas sin entender, no en el momento en que abres el chat.
¿Cómo sé si ya soy dependiente de la IA o solo la estoy usando bien?
La prueba es si podrías arreglarlo a las dos de la madrugada, cuando se rompe eso que lleva tu nombre en el commit. Si no eres capaz de explicarle a un compañero por qué funciona el código generado, todavía no es tuyo, es un riesgo que has firmado con tu nombre. La medida no es producir código sin ayuda. Es detectarlo cuando está mal.
¿No es la IA la calculadora de nuestra época?
No, y la diferencia apunta justo en dirección contraria al consuelo. Una calculadora devuelve una respuesta en la que puedes confiar, porque siete por ocho son cincuenta y seis la entiendas o no, mientras que un modelo de lenguaje devuelve una respuesta que tienes que verificar. Eso te convierte en su revisor, y un revisor que no entiende lo que lee no está revisando nada en absoluto.
¿Está bien dejar que el modelo lo escriba todo y enviarlo tal cual?
Con una fecha límite encima o en scripts desechables, sí, con una postura de barra de pesas: todo lo demás lo escribes y lo depuras a mano, y echas mano de la herramienta sabiendo perfectamente que genera deuda técnica. El alarde de que la IA construye la aplicación entera sin que tú aportes nada se cae en cuanto lo tocas, porque sigues aportando las restricciones y revisando el resultado, y si de verdad no lo revisas, eres tú quien está enviando a producción los agujeros de seguridad.
Leer a continuación
AIEstás persiguiendo herramientas. La habilidad está debajo.
La herramienta por la que discutes es la parte que puedes cambiar en un día. Nadie pregunta por la parte que llevó años.
AICuando la IA tiene que grabar su propia revisión
Cuando se abre una pull request, sea mía o una que me toca revisar, ahora le pido al agente que la ejecute en mi máquina, que intente romperla y que se grabe mientras lo hace. Un párrafo puede asegurar que se hizo una prueba. Una grabación tiene que enseñarla, y decidir qué significa sigue siendo cosa mía.