La generación que sabe pedir código, pero no necesariamente sabe programar
Durante décadas, aprender a programar significó enfrentarse a una realidad bastante incómoda.
El código no funcionaba.
Había que leer el error.
Buscar documentación.
Entender qué estaba pasando.
Cambiar una línea.
Volver a ejecutar.
Romper otra cosa.
Volver atrás.
Preguntar.
Leer código escrito por otras personas.
Aprender arquitectura.
Aprender patrones.
Aprender que una solución que funciona no necesariamente es una buena solución.
Y, con suficiente tiempo, aparecería algo mucho más importante que la capacidad de escribir código: la capacidad de reconocer cuándo el código estaba mal.
Ese último punto puede convertirse en una de las habilidades más importantes de la programación durante la era de la inteligencia artificial.
Porque la inteligencia artificial está cambiando radicalmente la primera parte del proceso.
Hoy ya no es necesario saber escribir cada línea para conseguir que una máquina produzca cientos o miles de líneas de código.
Se puede describir una funcionalidad.
Se puede pegar un error.
Se puede explicar una idea.
Se puede pedir una refactorización.
Se puede entregar un ticket.
Y un modelo puede producir una implementación completa.
La velocidad es impresionante.
Pero aparece una pregunta mucho más incómoda:
¿Qué ocurre cuando la persona que recibe ese código todavía no sabe reconocer que está mal?
El problema no es que la IA se equivoque
La inteligencia artificial se equivoca.
Eso ya no debería sorprender a nadie.
Puede inventar APIs.
Puede utilizar métodos que no existen.
Puede interpretar incorrectamente un requisito.
Puede modificar una parte del sistema que no debía tocar.
Puede cambiar el comportamiento de una función mientras intenta "mejorarla".
Puede generar código perfectamente válido desde el punto de vista sintáctico y completamente equivocado desde el punto de vista funcional.
Puede incluso explicar con enorme seguridad por qué una solución incorrecta supuestamente funciona.
Y este último problema es especialmente peligroso.
Porque un error evidente es relativamente fácil de detectar.
Un error convincente no.
La inteligencia artificial no necesita producir código absurdo para ser peligrosa.
Le basta con producir código razonable.
Código que compila.
Código que pasa algunos tests.
Código que parece limpio.
Código que utiliza patrones conocidos.
Código que tiene nombres perfectamente razonables.
Código que un programador con poca experiencia puede mirar y pensar:
"Esto tiene sentido."
Ahí empieza el verdadero problema.
El programador senior juega otro juego
Un programador con muchos años de experiencia no necesariamente escribe código perfecto.
Eso sería una fantasía.
Los seniors también cometen errores.
También olvidan cosas.
También introducen bugs.
También pueden hacer malas decisiones arquitectónicas.
La diferencia está en otra parte.
Un programador experimentado suele detectar muchas clases de problemas antes de ejecutar el código.
Puede leer una implementación y pensar:
- "Esto va a generar un problema de estado."
- "Esta consulta va a escalar mal."
- "Esta abstracción no corresponde aquí."
- "Este componente está haciendo demasiado."
- "Esta función tiene una responsabilidad que debería estar en otro sitio."
- "Este cambio rompe una dependencia que está tres capas más abajo."
- "Esto funciona para este caso, pero no para el caso que seguramente llegará después."
No necesita esperar necesariamente a que el sistema explote.
Su experiencia funciona como una especie de sistema de detección de errores.
No es magia.
Es memoria.
Es haber visto cientos de problemas anteriormente.
Es haber cometido esos errores.
Es haberlos solucionado.
Es haber mantenido sistemas durante años.
Es saber que ciertas soluciones aparentemente elegantes terminan siendo una pesadilla seis meses después.
El junior tiene otro problema
Un programador que está comenzando todavía está construyendo ese sistema de detección.
Y eso es completamente normal.
Un junior puede mirar:
const result = await fetchData();
y pensar:
"Perfecto."
Un senior puede mirar exactamente lo mismo y preguntarse:
- "¿Qué pasa si falla?"
- "¿Quién maneja el error?"
- "¿Qué devuelve?"
- "¿Qué pasa si devuelve null?"
- "¿Cuántas veces se ejecuta?"
- "¿Está dentro de un render?"
- "¿Puede generar una petición duplicada?"
- "¿Qué pasa cuando el usuario cambia de página?"
- "¿Quién cancela la petición?"
- "¿Qué pasa con una respuesta antigua que llega después?"
El código puede ser exactamente el mismo.
La diferencia está en todo lo que cada persona sabe que debería preguntarse.
La IA cambia completamente esta dinámica
Antes, el programador junior tenía una limitación muy evidente.
No sabía hacer determinadas cosas.
Si necesitaba construir un sistema de autenticación, tenía que aprender.
Si necesitaba implementar una API, tenía que investigar.
Si necesitaba utilizar React, tenía que estudiar React.
Si necesitaba trabajar con SQL, tenía que aprender SQL.
La dificultad técnica actuaba como una barrera.
La inteligencia artificial está reduciendo esa barrera.
Ahora alguien puede decir:
"Créame un sistema de autenticación con Google, Supabase y React."
Y recibir una implementación.
Puede pedir:
"Agrega recuperación de contraseña."
Y recibir más código.
Puede pedir:
"Refactoriza esto."
Y recibir una nueva versión.
Puede pedir:
"Soluciona este error."
Y recibir una solución.
El problema es que la barrera que desaparece no es solamente una barrera de productividad.
También es una barrera de aprendizaje.
Y ahí aparece una contradicción.
La IA puede permitir que una persona haga cosas mucho más complejas antes de comprender realmente cómo funcionan.
Eso es extraordinariamente poderoso.
Y también puede ser extraordinariamente peligroso.
El programador puede convertirse en supervisor del código
Hay una posibilidad interesante.
La IA podría terminar cambiando la profesión de manera similar a como las calculadoras cambiaron las matemáticas.
Nadie piensa que una persona que utiliza una calculadora sea menos matemática por utilizarla.
Pero existe una diferencia fundamental:
Una persona que entiende matemáticas puede comprobar si el resultado de una calculadora tiene sentido.
Si la calculadora dice:
2 + 2 = 7
hay un problema evidente.
Pero en programación las cosas no son tan simples.
Una implementación puede tener 2.000 líneas.
Puede compilar.
Puede funcionar en el escenario que se probó.
Y aun así estar arquitectónicamente equivocada.
La pregunta entonces deja de ser:
"¿Puede la IA escribir código?"
La respuesta ya es claramente sí.
La pregunta importante pasa a ser:
"¿Quién va a comprobar que ese código debería existir?"
La trampa del código que funciona
Una de las ideas más peligrosas en programación es:
"Pero funciona."
Que algo funcione no significa que esté bien diseñado.
Un código puede funcionar y:
- ser difícil de mantener;
- tener una vulnerabilidad;
- consumir demasiados recursos;
- tener una condición de carrera;
- generar deuda técnica;
- duplicar lógica;
- ocultar errores;
- romper otro flujo;
- depender accidentalmente de un comportamiento;
- fallar ante un caso límite;
- ser imposible de extender correctamente.
La IA es especialmente buena produciendo soluciones que parecen completas.
Eso puede generar una ilusión muy poderosa:
"Ya está hecho."
Pero una aplicación no está terminada simplemente porque el código exista.
La alucinación es solamente una parte del problema
Se habla mucho de las "alucinaciones" de los modelos.
Y con razón.
Pero probablemente el problema más interesante no sean las alucinaciones absurdas.
El problema son las respuestas plausibles.
Un modelo puede inventar una función inexistente.
Eso es relativamente fácil de descubrir.
Pero también puede utilizar una función real de una manera incorrecta.
Puede utilizar una API real con un parámetro incorrecto.
Puede aplicar correctamente un patrón en el lugar equivocado.
Puede modificar una función que realmente necesitaba permanecer intacta.
Puede interpretar un requisito de manera ligeramente diferente.
Puede eliminar contenido que considera innecesario.
Puede cambiar nombres.
Puede reorganizar archivos.
Puede "limpiar" código que tenía una razón para existir.
Puede incluso responder a una pregunta distinta de la que el programador hizo.
Y si quien revisa el resultado no tiene suficiente experiencia, probablemente no lo detectará.
La IA tampoco conoce necesariamente la intención
Existe otra diferencia importante entre código y lenguaje.
El código tiene contexto.
Una función puede parecer innecesaria.
Pero quizá existe porque una integración externa depende de ella.
Una variable puede parecer redundante.
Pero quizá representa una distinción de negocio.
Una validación puede parecer excesiva.
Pero quizá existe porque una vez hubo un incidente.
Un archivo puede parecer mal organizado.
Pero quizá existe para cumplir una arquitectura concreta.
Una IA que mira solamente una parte del repositorio puede no conocer esas razones.
Por eso el contexto es tan importante.
Y por eso los agentes de programación están intentando resolver precisamente este problema.
Los sistemas modernos ya no solamente reciben una pregunta y generan una respuesta.
Intentan leer repositorios.
Buscar archivos.
Construir contexto.
Analizar dependencias.
Leer documentación.
Ejecutar tests.
Modificar código.
Revisar cambios.
Crear commits.
Crear pull requests.
En otras palabras:
La industria está intentando convertir el modelo de lenguaje en un trabajador de software.
Y ahí la cuestión se vuelve todavía más interesante.
Las empresas están apostando muchísimo dinero
No estamos hablando de una pequeña tendencia.
La industria tecnológica está invirtiendo cantidades enormes de dinero en inteligencia artificial.
Infraestructura.
Centros de datos.
GPUs.
Modelos.
Agentes.
Herramientas para desarrolladores.
Automatización.
Copilotos.
Sistemas empresariales.
Y software construido alrededor de modelos.
La apuesta empresarial es sencilla de entender.
Si un desarrollador cuesta una determinada cantidad de dinero y una herramienta de IA puede aumentar significativamente su productividad, el retorno potencial es enorme.
Incluso una mejora relativamente pequeña puede representar millones de dólares para una organización grande.
Por eso las empresas tienen incentivos muy fuertes para adoptar estas herramientas.
Y la adopción ya está ocurriendo.
La encuesta 2025 de Stack Overflow, con más de 49.000 respuestas de 177 países, encontró que el 84% de los desarrolladores utilizaba o planeaba utilizar herramientas de IA en su proceso de desarrollo.
Pero aparece un dato mucho más interesante.
La confianza no está creciendo al mismo ritmo.
Según esa misma encuesta, el 46% de los desarrolladores decía desconfiar de la precisión de las respuestas de las herramientas de IA, frente a un 33% que confiaba en ellas. Solo un 3% declaraba confiar mucho en sus resultados.
Es una situación extraña.
Cada vez utilizamos más una herramienta en la que cada vez confiamos menos.
"Casi correcto" puede ser peor que incorrecto
Stack Overflow encontró otro dato especialmente interesante.
El 66% de los desarrolladores señaló como principal frustración las soluciones de IA que están "casi correctas, pero no del todo".
Y el 45% señaló que depurar código generado por IA puede consumir más tiempo.
Esto tiene una consecuencia importante.
La productividad no es simplemente:
código generado
=
trabajo terminado
La ecuación real puede parecerse más a:
código generado
+
revisión
+
tests
+
debugging
+
comprensión
+
correcciones
=
trabajo terminado
Si una persona tiene suficiente experiencia, esa revisión puede ser rápida.
Si no la tiene, puede convertirse en una cadena interminable de intentos.
El peligro del "funciona en mi máquina"
Imaginemos una empresa.
Antes tenía diez desarrolladores.
Ahora decide utilizar agentes de IA.
La empresa descubre que diez personas pueden producir aparentemente el trabajo de veinte.
Excelente.
Pero hay una pregunta que debería hacerse:
¿Quién está revisando el trabajo?
Si los diez desarrolladores originales tenían experiencia, quizá la respuesta sea razonable.
Pero imaginemos que la empresa reduce también la cantidad de desarrolladores senior.
Ahora tiene:
- muchos agentes;
- varios juniors;
- pocos seniors.
La cantidad de código producido puede aumentar.
La capacidad de comprender ese código puede disminuir.
Y aquí aparece una paradoja.
La empresa puede aumentar su velocidad de producción mientras reduce su capacidad de detectar errores.
Eso puede funcionar durante bastante tiempo.
Hasta que deja de funcionar.
La deuda técnica puede volverse deuda técnica generada por IA
La deuda técnica ya existe.
Todo equipo de software tiene cierta cantidad.
Pero la IA puede cambiar la velocidad a la que se acumula.
Antes, escribir una mala abstracción costaba tiempo.
Ahora puede generarse una abstracción incorrecta en segundos.
Antes, duplicar código requería trabajo.
Ahora un agente puede duplicarlo accidentalmente mientras implementa cinco funcionalidades.
Antes, una mala arquitectura podía ser limitada por la capacidad humana del equipo.
Ahora podemos generar código a una velocidad muy superior a nuestra capacidad de revisarlo.
Ese es un concepto importante:
la velocidad de generación puede superar la velocidad de comprensión.
Y cuando eso sucede, la deuda técnica puede crecer más rápido que la capacidad del equipo para pagarla.
El cuello de botella puede dejar de ser escribir
Durante décadas, buena parte de la programación consistió en transformar una especificación en código.
La IA está reduciendo el coste de esa transformación.
Entonces el cuello de botella se mueve.
Puede pasar a ser:
- definir correctamente el problema;
- comprender el dominio;
- diseñar la arquitectura;
- revisar las decisiones;
- probar el comportamiento;
- garantizar seguridad;
- mantener el sistema;
- entender las consecuencias.
Es decir:
el código puede volverse barato mientras que el conocimiento se vuelve caro.
Esta podría ser una de las transformaciones más importantes de la profesión.
¿Y qué pasa con los nuevos programadores?
Aquí tengo una opinión bastante concreta.
Creo que la profesión no va a desaparecer.
Pero creo que la forma tradicional de entrar en ella puede cambiar muchísimo.
Durante años, una empresa podía contratar un grupo de juniors porque necesitaba capacidad de implementación.
Los juniors podían comenzar haciendo tareas pequeñas.
Corregir estilos.
Modificar componentes.
Crear endpoints.
Escribir tests.
Hacer pequeñas funcionalidades.
Con el tiempo aprendían.
El problema es que muchas de esas tareas son precisamente las que la IA puede automatizar primero.
Eso puede crear un problema de entrada.
Si las tareas sencillas desaparecen, ¿dónde adquiere experiencia el nuevo programador?
Esta es una pregunta mucho más importante que:
"¿La IA reemplazará a los programadores?"
Porque incluso si la respuesta fuera "no", podríamos terminar con un problema diferente:
menos puestos de entrada y una exigencia mayor de experiencia para conseguirlos.
El paradojal junior
Podríamos terminar con una situación bastante extraña.
Las empresas dirán:
"Necesitamos programadores que sepan utilizar IA."
Los nuevos programadores aprenderán a utilizar IA.
Pero las empresas también necesitarán personas capaces de revisar el trabajo producido por la IA.
Y para eso necesitarán experiencia.
Pero esa experiencia tradicionalmente se obtenía haciendo precisamente el trabajo que ahora automatizamos.
Ahí existe una tensión real.
Podría ser uno de los mayores problemas educativos de la programación durante los próximos años.
¿Los seniors ganarán valor?
Probablemente algunas habilidades senior sí aumentarán de valor.
No necesariamente porque los seniors escriban más código.
De hecho, quizá escriban menos.
Pero pueden convertirse en quienes:
- diseñan sistemas;
- definen límites;
- revisan arquitectura;
- validan resultados;
- identifican riesgos;
- diseñan tests;
- entienden el negocio;
- revisan seguridad;
- toman decisiones técnicas.
Un senior con una herramienta de IA puede convertirse en un multiplicador enorme.
Pero hay una condición.
Tiene que seguir siendo capaz de juzgar lo que produce la herramienta.
Si deja de entender el código, pierde precisamente la ventaja que le daba su experiencia.
El senior tampoco está a salvo
Esto es importante.
No deberíamos convertir esto en:
"Los seniors saben y los juniors no."
Eso sería demasiado simplista.
La IA también puede engañar a un senior.
Un sistema suficientemente grande puede contener problemas que ninguna persona pueda comprender completamente.
Además, un senior puede confiar demasiado en su propia experiencia.
Puede pensar:
"Ya he visto esto antes."
Y equivocarse.
Por eso el futuro probablemente no será:
IA vs programador
sino:
IA + programador + tests + observabilidad + revisión
La ingeniería seguirá necesitando mecanismos externos de verificación.
El software tendrá que demostrar que funciona
Esta podría ser una consecuencia positiva de toda esta revolución.
Si producir código se vuelve extremadamente barato, tendremos que invertir mucho más en demostrar que ese código funciona.
Tests.
Tipos.
Linting.
Análisis estático.
CI/CD.
Revisión automática.
Observabilidad.
Pruebas de integración.
Pruebas de seguridad.
Checks de arquitectura.
Property-based testing.
Canary deployments.
Rollbacks.
Sistemas de evaluación.
Todo eso puede volverse todavía más importante.
La IA puede escribir el código.
Pero el sistema necesita demostrar que el código hace lo que debería hacer.
El futuro no será "sin humanos"
Probablemente veremos una evolución hacia equipos mucho más pequeños capaces de producir sistemas mucho más grandes.
Un equipo que antes necesitaba diez personas podría necesitar cinco.
Uno que necesitaba cinco podría necesitar tres.
Y un desarrollador independiente podría construir productos que anteriormente requerían un pequeño equipo.
Eso ya está empezando a ocurrir.
Pero reducir el número de personas necesarias no significa eliminar la necesidad de conocimiento.
De hecho, podría ocurrir lo contrario.
Una sola persona responsable de un sistema enorme necesita comprender muchísimo más.
La concentración de responsabilidad aumenta.
Y aquí aparece un riesgo empresarial
Las empresas pueden mirar las métricas equivocadas.
Por ejemplo:
líneas de código generadas
tickets cerrados
features entregadas
pull requests creados
Todas pueden aumentar.
Pero eso no significa necesariamente que el producto esté mejor.
Podría ocurrir:
+300% código
+200% funcionalidades
+150% velocidad
pero también:
+250% deuda técnica
+100% bugs
+200% complejidad
La métrica correcta no será cuánto código genera la IA.
Será cuánto valor confiable puede producir el equipo.
La burbuja
Aquí llegamos a la parte más especulativa.
Creo que existe una posibilidad real de que haya una burbuja alrededor de determinadas empresas de IA.
Eso no significa que la IA sea una burbuja.
Son cosas diferentes.
Internet no era una mentira porque muchas empresas puntocom quebraran.
Los smartphones no eran una mentira porque algunas empresas de teléfonos desaparecieran.
La computación en la nube no era una mentira porque algunos proyectos fracasaran.
Una tecnología puede ser transformadora y, al mismo tiempo, producir una enorme cantidad de inversiones equivocadas.
La IA puede estar pasando por algo similar.
Hay empresas que probablemente tienen productos extraordinarios.
Hay empresas que probablemente tienen modelos de negocio sólidos.
Y también hay empresas cuyo principal producto puede ser simplemente la narrativa de que utilizan IA.
El dinero no garantiza el éxito
Cuando una tecnología recibe cantidades enormes de capital, se crea una presión particular.
Los inversores quieren crecimiento.
Las empresas quieren adopción.
Los ejecutivos quieren demostrar productividad.
Los empleados quieren utilizar las herramientas.
Los medios quieren hablar del cambio.
Todo el sistema crea presión para que la tecnología parezca inevitable.
Pero la economía real tiene una pregunta mucho más sencilla:
¿Genera suficiente valor para justificar su coste?
Esa pregunta tardará más en responderse.
Y puede haber una corrección
Mi predicción no es que "todo va a explotar".
Es más interesante que eso.
Creo que probablemente veremos una separación.
Algunas empresas de IA van a convertirse en infraestructura fundamental.
Otras van a desaparecer.
Algunas herramientas de programación van a convertirse en estándar.
Otras serán absorbidas.
Algunos agentes demostrarán una productividad extraordinaria.
Otros terminarán siendo simplemente interfaces caras para modelos similares.
Y muchas empresas descubrirán que automatizar una tarea no es lo mismo que automatizar un proceso completo.
El mercado podría aprender una lección incómoda
Una empresa puede comprar cien licencias de IA.
Eso es fácil.
Lo difícil es cambiar el proceso de trabajo.
Una empresa puede decir:
"Ahora todos usamos agentes."
Pero si los empleados siguen revisando manualmente todo, la productividad puede no cambiar demasiado.
También puede ocurrir lo contrario.
La empresa puede automatizar demasiado.
Y descubrir seis meses después que nadie entiende el sistema que construyeron.
Entonces tendrá que pagar la factura.
Y esa factura no será solamente económica.
Será conocimiento perdido.
La gran paradoja
Aquí está, para mí, la paradoja central:
Cuanto mejor sea la IA escribiendo código, más importante será saber programar.
Parece contradictorio.
Pero no lo es.
Si la IA es mala, puedes detectar fácilmente sus errores.
Si la IA es excelente, sus errores serán más difíciles de detectar.
Y cuanto más convincente sea el código generado, mayor será el valor de quien pueda cuestionarlo.
Un programador que sabe únicamente producir código pierde ventaja.
Un programador que sabe evaluar sistemas gana ventaja.
Entonces, ¿qué debería aprender un nuevo programador?
Probablemente no debería competir con la IA en escribir código rápido.
La IA siempre tendrá ventaja en determinadas tareas mecánicas.
El nuevo programador debería aprender:
- cómo funciona realmente un lenguaje;
- cómo funcionan las redes;
- cómo funcionan las bases de datos;
- cómo funciona HTTP;
- cómo funciona un navegador;
- cómo funciona la memoria;
- cómo funciona un sistema operativo;
- cómo diseñar APIs;
- cómo diseñar sistemas;
- cómo leer código;
- cómo hacer debugging;
- cómo escribir tests;
- cómo identificar estados inválidos;
- cómo investigar documentación;
- cómo razonar sobre errores;
- cómo evaluar trade-offs;
- cómo entender un requisito ambiguo;
- cómo detectar una mala abstracción;
- cómo revisar código generado por otra persona;
- y, especialmente, cómo saber cuándo no confiar en la respuesta de una IA.
Quizá aprender a programar se vuelva más importante, no menos
Esta es probablemente la conclusión que más contradice algunas narrativas actuales.
Hay gente que dice:
"Ya no necesitas aprender a programar porque la IA programa por ti."
Yo creo que eso puede ser cierto para construir cosas pequeñas.
Puedes crear una aplicación sencilla sin comprender profundamente todos sus componentes.
Pero a medida que aumenta la complejidad, aumenta la necesidad de comprensión.
Es parecido a conducir.
Puedes conducir un automóvil sin saber reconstruir un motor.
Pero si eres responsable de diseñar el automóvil, necesitas conocimientos muy diferentes.
La IA puede permitir que más personas construyan software.
Eso es fantástico.
Pero construir software y ser ingeniero de software no necesariamente serán la misma cosa.
El peligro educativo
Si las universidades, bootcamps y cursos empiezan a enseñar:
"Aprende a utilizar Cursor."
"Aprende a utilizar Claude Code."
"Aprende a escribir prompts."
"Aprende vibe coding."
sin enseñar fundamentos, podemos crear una generación extraordinariamente eficiente para producir software que no entiende.
Eso sería una mala combinación.
Porque el problema no aparece mientras todo funciona.
Aparece cuando algo deja de funcionar.
Y los sistemas reales eventualmente dejan de funcionar.
La prueba definitiva llega cuando algo falla
Puedes medir a un programador por la velocidad con la que crea una funcionalidad.
Pero existe otra métrica mucho más reveladora:
¿Qué hace cuando el sistema falla y nadie sabe por qué?
Ahí desaparece el brillo de la demo.
No importa que el agente haya generado 20.000 líneas.
No importa que haya creado diez componentes.
No importa que el README sea perfecto.
Alguien tiene que encontrar el problema.
Alguien tiene que formular hipótesis.
Alguien tiene que leer logs.
Alguien tiene que reproducir el bug.
Alguien tiene que entender el flujo.
Alguien tiene que decidir dónde está realmente la causa.
Y alguien tiene que saber si la solución propuesta por la IA realmente arregla el problema.
Ese podría ser el nuevo diferencial profesional
No:
"Escribo código muy rápido."
Sino:
"Puedo mirar un sistema complejo y entender qué está pasando."
Eso es mucho más difícil de automatizar.
Y probablemente mucho más valioso.
¿Qué creo que va a pasar?
Creo que durante los próximos años veremos cinco cosas simultáneamente.
Primero: la productividad individual aumentará
Sería absurdo negar esto.
Los desarrolladores que utilizan bien IA pueden hacer muchas tareas más rápido.
La encuesta de Stack Overflow muestra que alrededor del 69% de quienes utilizan agentes de IA están de acuerdo en que estos aumentaron su productividad, aunque los impactos reportados son mucho menores en colaboración y otras dimensiones.
Eso no significa que la IA sea perfecta.
Significa que ya es útil.
Segundo: habrá menos trabajo puramente mecánico
Tareas sencillas de implementación serán cada vez más automatizables.
CRUD.
Componentes.
Transformaciones.
Tests básicos.
Documentación.
Migraciones relativamente simples.
Refactors pequeños.
Código repetitivo.
Eso no significa que desaparezca la profesión.
Significa que el tipo de trabajo que genera experiencia puede cambiar.
Tercero: aumentará el valor de la experiencia real
Los programadores capaces de revisar, diseñar y diagnosticar sistemas complejos probablemente serán especialmente importantes.
Porque producir código será cada vez más barato.
Entender las consecuencias de ese código seguirá siendo difícil.
Cuarto: habrá una crisis de formación
Creo que este puede ser el problema más silencioso.
Durante varios años podríamos tener muchos desarrolladores capaces de producir software con IA, pero menos desarrolladores capaces de explicar profundamente por qué ese software funciona.
Y cuando los sistemas se vuelvan grandes, esa diferencia será evidente.
Quinto: habrá una corrección empresarial
Muchas empresas van a descubrir que:
"Tenemos IA"
no es una estrategia.
Es una herramienta.
La estrategia tiene que ser:
"Tenemos un proceso que utiliza IA para producir software confiable."
Eso es completamente diferente.
¿Y la burbuja?
Creo que sí veremos empresas quebrar.
No necesariamente porque la IA no funcione.
Sino porque algunas expectativas económicas serán imposibles de cumplir.
Habrá productos que no tengan suficiente diferenciación.
Habrá startups construidas sobre modelos que otros podrán copiar.
Habrá empresas que gasten demasiado en infraestructura.
Habrá compañías que prometan automatización completa y descubran que necesitan humanos.
Habrá inversiones basadas más en expectativas que en ingresos.
Y habrá una selección bastante brutal.
Pero eso no significa que la tecnología desaparezca.
Probablemente ocurra lo contrario.
Después de la corrección, quedarán las empresas que realmente resuelvan problemas.
La ironía final
Puede que la inteligencia artificial termine produciendo una situación bastante inesperada.
La industria empezó diciendo:
"Vamos a automatizar la programación."
Y podría terminar descubriendo:
"Lo que realmente necesitamos automatizar es la parte repetitiva de escribir código, mientras hacemos todavía más importante la capacidad humana de comprenderlo."
Eso cambia completamente la discusión.
La pregunta no será:
"¿Puede la IA programar?"
Ya puede.
La pregunta será:
"¿Quién puede saber si lo que la IA programó está bien?"
Y ahí aparecerá una diferencia enorme entre dos generaciones.
Una persona puede aprender a pedir:
"Créame esta aplicación."
Otra puede pedir lo mismo.
Pero cuando la aplicación falle, una de ellas solamente tendrá una segunda pregunta:
"IA, ¿cómo arreglo esto?"
Mientras que la otra podrá abrir el proyecto y empezar a razonar.
Esa diferencia puede convertirse en una de las divisiones profesionales más importantes de la próxima década.
Y quizá esa sea la verdadera revolución
La IA no necesariamente va a eliminar al programador.
Puede eliminar una parte del trabajo que hacía el programador.
Y eso es distinto.
La profesión puede hacerse más pequeña en algunas áreas, más grande en otras y mucho más exigente en las capas superiores.
Los nuevos programadores tendrán herramientas que nosotros nunca tuvimos.
Podrán construir cosas extraordinarias con muy poca experiencia.
Eso es bueno.
Pero también tendrán una tentación que ninguna generación anterior tuvo a esta escala:
confundir la capacidad de producir una respuesta con la capacidad de comprenderla.
Ahí estará la diferencia.
El programador que use IA como sustituto de su conocimiento probablemente terminará dependiendo de ella.
El programador que use IA como multiplicador de su conocimiento probablemente será mucho más productivo.
Y las empresas tendrán que aprender exactamente la misma lección.
No se trata de decidir entre humanos o inteligencia artificial.
Se trata de decidir qué parte del proceso puede automatizarse y qué parte necesita todavía juicio humano.
Porque una máquina puede escribir diez mil líneas en unos minutos.
Pero si esas diez mil líneas están equivocadas, alguien tendrá que descubrirlo.
Y ese alguien todavía necesita saber programar.
Quizá más que nunca.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.