En pleno auge del ‘vibe coding’ y, en general, del uso de las herramientas de programación basadas en IA generativa, un desarrollador web ha relatado en su blog cómo su inmersión en el uso de las mismas le llevó desde una sensación inicial de «tener superpoderes» cuando se ponía a escribir código, hasta otra sensación, con el tiempo, muy diferente: la de haberse vuelto más perezoso y menos competente.
Su conclusión final es que el mayor riesgo no es que la IA nos reemplace por ser «mejor» que nosotros, sino que, si la usamos sin cuidado, acabemos deteriorando nuestras propias habilidades hasta volvernos prescindibles.
Punto de partida: contexto personal y laboral
El pasado mes de abril, el jefe de nuestro protagonista le pidió que probase a introducir la IA en su dinámica habitual de trabajo. No fue una imposición numérica tipo «que el 20 % del código sea hecho con IA», sino una forma de asegurarse de no perder una posible ventaja en un mercado difícil: que si aumentaba en cierto grado la productividad, valía la pena probar.
Aun así, él llegaba con recelos: en lo personal, había visto despidos en otros puestos de trabajo (relacionados con la redacción y/o la traducción) asociados al despliegue de LLMs; pero, además, desde el punto de vista ético, cuestionaba tanto el origen de los datos, como el impacto ambiental de la generación de contenidos.
Primeras pruebas: utilidad limitada en el día a día
El primer contacto con la IA no se dio en grandes proyectos, sino en pequeñas intervenciones dentro de tareas rutinarias. Así, las contribuciones del LLM se limitaron sobre todo a:
- Correcciones menores de sintaxis y errores tipográficos en TypeScript, especialmente en situaciones en las que el compilador marcaba errores poco claros y había que ajustar la definición de datos.
- Generación de código repetitivo o boilerplate, como fragmentos de HTML o componentes básicos. Si bien esto ahorraba algunos minutos, los resultados solían carecer de accesibilidad o buenas prácticas, lo que obligaba a una revisión manual exhaustiva.
- Revisiones genéricas de código con comentarios que, aunque bienintencionados, rara vez aportaban valor profundo. Frases como «podría optimizarse» o «esto puede modularizarse» no incluían sugerencias concretas adaptadas al contexto del proyecto, por lo que no aceleraban realmente el proceso de mejora.
En resumen, el producto final no era más estable, más seguro ni más innovador por el hecho de haber incorporado esos fragmentos generados por IA.
El experimento serio: construir un módulo real con IA
Después de varias interacciones modestas con la IA, el autor decidió someterla a una prueba más exigente: desarrollar la implementación del procesamiento de imágenes en su nuevo CMS. Esto es, una funcionalidad que no era trivial, pero tampoco de la complejidad de un motor de compilación o un sistema distribuido… y por lo tanto, aparentemente perfecta para evaluar la IA en un caso de uso tangible.
El autor integró el asistente de IA directamente en su editor de código, de modo que el modelo tuviera acceso tanto al prompt como a los archivos del proyecto, pudiendo contextualizar la generación.
El LLM respondió con rapidez: alrededor de 200 líneas de código, comentadas, que parecían cubrir todos los puntos de la lista. La implementación incluía funciones para leer el archivo, procesarlo con una librería de manipulación de imágenes, guardar las variantes y devolver un objeto con información útil para el CMS.
Tiempo total: unos 30 minutos, frente a las varias horas que el autor calculaba que le costaría hacerlo manualmente. La sensación fue casi mágica: era como delegar en un «compañero invisible» capaz de programar a velocidad de vértigo.
Ese impacto positivo inicial le llevó a pensar en el potencial multiplicador de productividad: si podía implementar una pieza entera del sistema así de rápido, ¿qué impediría que la mayor parte del CMS se construyera con este método?
En ese momento, parecía que la IA no solo le estaba ayudando: estaba redefiniendo sus expectativas sobre lo que podía lograr en una jornada laboral.
No obstante, pronto empezaron a aparecer detalles que le incomodaron:
- Algunas partes del código parecían genéricas, como sacadas de ejemplos de documentación, sin ajuste fino.
- Había funciones duplicadas con ligeras variaciones, señal de que el modelo no estaba optimizando el diseño.
- La gestión de errores era mínima o inexistente: mensajes de log vagos, ausencia de validación de entradas y salidas.
Estas «grietas» pasaron desapercibidas en medio del subidón inicial, pero se harían decisivas cuando llegara la fase de auditoría.
Pero así, lo que al principio parecía una victoria rotunda empezó a transformarse en una pregunta inquietante: ¿cuánto de este código era realmente seguro y mantenible?
La auditoría que destapó el problema: seguridad y calidad
Sospechando que la subida de archivos podía esconder riesgos, pidió al propio LLM auditar el módulo. El veredicto: varias vulnerabilidades críticas (falta de límites en tamaño de archivo, ausencia de comprobación del tipo de contenido, posibilidad de sobrescribir archivos del sistema, entre otras). Descubrió así que el mismo asistente que generó el código “rápido y funcional” omitió salvaguardas básicas.
Y se topó con un segundo problema: como no había sido él quien había escrito el código, y la lógica no era suya, carecía de visión global para arreglarlo con soltura: cada fallo encontrado se sentía ajeno, como si estuviera depurando el trabajo de otro programador desconocido… con la diferencia de que ese «otro» era una IA incapaz de responder por sus decisiones.
La salida «fácil» era volver a pedir más cambios al LLM… y de nuevo sin saber si ahora el código sí quedaba realmente bien. Ahí cortó el experimento, dándose cuenta de que estaba atrapado en una espiral improductiva.
No era solo un problema de seguridad técnica; era una cuestión de seguridad profesional: había perdido temporalmente la capacidad de auditar y mejorar de forma independiente una pieza central del sistema que, en teoría, había «desarrollado» él mismo.
La ilusión de productividad y el coste cognitivo
El autor describe la sensación inicial de trabajar con un LLM integrado en el flujo de desarrollo como «suave, sin fricción», una en la que una simple instrucción en lenguaje natural generaba en segundos bloques enteros de código funcional. Esa inmediatez crea una ilusión de estar avanzando a gran velocidad y resolviendo problemas con eficacia. Pero lo que parecía eficiencia pronto se reveló como dependencia.
En términos cognitivos, el problema no es solo que el desarrollador deje de escribir líneas de código; es que deja de recorrer el camino mental que da forma al entendimiento del sistema. Cuando uno programa desde cero, cada decisión —desde la elección de una estructura de datos hasta la validación de una entrada— es un punto de reflexión. Esas microdecisiones alimentan lo que podríamos llamar «mapa mental del proyecto»: una representación interna que permite anticipar errores, comprender interacciones y hacer ajustes con precisión.
Con el uso intensivo del LLM, ese mapa mental se vuelve borroso. Además, surge lo que algunos estudios llaman «deuda cognitiva»: la acumulación de decisiones no tomadas por el humano que, más adelante, deberán ser comprendidas para mantener o escalar el sistema. Esa pérdida de comprensión es peligrosa: no se nota de inmediato, pero erosiona la capacidad de intervenir con seguridad en el futuro.
Además, como el tiempo desde que tiene la idea hasta que tiene en pantalla el código que «funciona» es muy breve, la mente recibe una recompensa inmediata que refuerza el uso de la herramienta… incluso cuando la calidad, la seguridad o la mantenibilidad no están garantizadas.
El círculo vicioso es claro:
- El LLM produce código rápido.
- El desarrollador lo acepta porque “funciona” y ahorra tiempo.
- El mismo LLM detecta problemas en su propio código, generando más correcciones automáticas.
- El profesional dedica menos tiempo a pensar y más a pedir cambios, reforzando la pasividad.
El riesgo real no es la IA, sino usarla para autoboicotearnos
Su reflexión final se aparta del discurso habitual sobre la «amenaza» de la IA: para el autor, el escenario más preocupante no es un futuro en el que un LLM sea intrínsecamente más inteligente, rápido y preciso que él —un «enemigo externo» invencible—, sino un presente en el que, al delegar en exceso, pierda destreza y criterio, y él mismo se vuelva irrelevante.
Empieza con pequeños ahorros de tiempo, con líneas de código que ya no escribe ni revisa a fondo, con decisiones de arquitectura que deja que la máquina tome «porque es más rápido así». Poco a poco, el músculo cognitivo se atrofia: el conocimiento técnico se vuelve superficial, la intuición para detectar un bug se diluye, y la confianza en el propio juicio cede terreno a la dependencia.
En sus palabras, la situación es análoga a la de un piloto que, por confiar ciegamente en el piloto automático, pierde la pericia para volar en manual. El peligro no es solo técnico, sino psicológico: el flujo de trabajo asistido por IA puede ser tan cómodo que uno olvide por qué se hacían las cosas de cierto modo, o qué compromisos implicaba cada decisión. Esa «pérdida de fricción» es seductora, pero a la vez erosiona la comprensión del código.
Recomendaciones
- Delimita el papel de la IA. Úsala, si quieres, para tareas muy acotadas (p. ej., apuntes rápidos de tipos o esbozos de funciones), pero reclama para ti el diseño, las decisiones y las partes críticas. Si la herramienta actúa, audita tú.
- Exige auditoría y pruebas desde el minuto uno. Ante generación de código, planifica revisión de seguridad (inputs, límites, rutas, permisos) y cubre con tests los caminos sensibles
- Mantén la «propiedad mental» del módulo. Si un bloque lo generó el LLM, reescríbelo o documéntalo hasta comprenderlo por completo. Sin ese mapa, cada cambio futuro es un salto de fe.
- Sé capaz de decir «hasta aquí». Establece un límite: si tras X minutos sigues pidiendo parches al modelo sin entender el conjunto, paras y retomas el control manual. El autor “corta” justo al notar esa espiral.
Imagen | Marcos Merino mediante IA
En Genbeta | La IA ya ‘amenazó’ el empleo de los traductores como ahora a los programadores: Google Translate nos enseña que no es para tanto
–
La noticia
«Me volví perezoso y estúpido» programando con IA, afirma este desarrollador. Y ahora sabe quién es su peor enemigo
fue publicada originalmente en
Genbeta
por
Marcos Merino
.
