Corría el año 2021 cuando tuve mi primer momento de miedo con la IA, específicamente cuando realicé este video evaluando GitHub Copilot con Java
En este punto de la historia, la propuesta de valor era que la IA nos ayudara como un copiloto en el proceso tradicional de software, y en menos de 5 años pasó de ser un copiloto a un actor central.
Más allá del video y del guiño obvio a la pandemia, algo que me marcó en ese video fue enfrentarme al hecho de que la profesión nunca iba a volver a ser la misma. A partír de ahi ha sido un juego del gato y el ratón para intentar estar al día en el futuro de la profesión de programador Java y de la profesión de ingeniero de software en si misma, al día de hoy veo tres corrientes de pensamiento que estan definiendo como creamos software.
Los vibecoders
Llamémosles también los creyentes. Si vamos a la definición formal y aceptada de vibecoders, un vibecoder es aquella persona capaz de producir de principio a fin una aplicación en lenguaje natural sin saber programar. Entre otras cosas, hace que el lenguaje de programación sea irrelevante, dado que el inglés (o español) sería el reemplazo natural. En mi opinión, este es el futuro, pero aún no llegamos ahí.
Y creo que aún no llegamos aqui porque escribir el software no es ni de cerca la mayoria del trabajo, la mayoria del trabajo es el manteimiento del software porque el software es un ente vivo, software que no necesita mantenimiento es sinonimo de software que no tiene usuarios.
Sin embargo, esto no significa que el vibecoding no exista. Al día de hoy, reemplazó la creación de prototipos y yo mismo lo he visto como una herramienta que ha reemplazado el mocking de UIs, a decir verdad, es muy útil para esto.
Los promotores de SDD
Para quien lleva años en la profesión, el término specification driven development resuena y se parece bastante a una de las prácticas ágiles que siempre prometieron pero nunca cumplieron a cabalidad, que es Behaviour Driven Development.
En BDD original, la propuesta de valor es que el comportamiento de un sistema se «especifica» de antemano y su implementación depende tanto de las historias de usuario como de las especificaciones resultantes. La diferencia con SDD es que, ahora en lugar de que sea el instrumento guía de un humano programador, la especificación es la guía de trabajo de un coding agent, lo que se traduce en la colisión de dos profesiones
- Los actuales product owners, pueden tener una transición a «VibePMs», PMs que capturan el rumbo de un producto, lo especifican y luego lo entregan a un coding agent para crear la aplicación.
- Los actuales programadores, deben subir un nivel y por fin preocuparse más por la entrega de valor de negocio donde entregan a un coding agent las especificaciones y (de ser necesario) se preocupan por revisar el resultado, actuando como humans in the loop por si a la IA «se le va la moto».
Al día de hoy he visto más el escenario B que el escenario A, pero no dudo que A sea atractivo. Sin embargo, tampoco estamos 100% ahí, aunque no dudo que lleguemos a mediano plazo.
Acá el lenguaje de programación también es irrelevante, y es más una formalización del vibecoding, un vibecoding ingenieril si me lo permiten.
El AI T-shaped software engineer
En los últimos tres años mi carrera tomó este giro, y hablando desde la experiencia personal creo que este es el presente inmediato y no el futuro.
De nuevo, quien lleva suficientes años en la profesión sabe que el código no es ni de cerca la mayoría del trabajo y también (por haberlo intentado una y otra vez) sé que SDD tiene sus límites y el límite suele ser la responsabilidad. Al trabajar en sistemas criticos, un «mal» que padecemos los ingenieros de software es querer comer …. y para poder comer y no perder los trabajos necesitamos estar seguros de que el sistema va a funcionar, porque no son pocos los escenarios donde la IA ha fallado cuando se ha utilizado sin control.
El término T-Shaped viene de este tipo de gráficas
En pocas palabras, un ingeniero T-Shaped es aquel ingeniero que conoce diversos tópicos propios de la profesión y que además es especialista en una rama. Creo que con IA se «potenció» el eje broad y los ingenieros de software AI se ven así:
Desde el punto de vista antropológico, ha derivado en:
- Despidos masivos dado que esta tecnología es carísima, incluso más que muchos humanos
- Migración del trabajo a países con menor costo por persona. Una IA por si sola aún no hace el trabajo de un Staff Engineer de USA, pero una IA y un Dev en Latam si, y hasta más barato.
- Aumentos de carga de trabajo para ingenieros de software (se supone que la IA nos haría trabajar menos, pero en realidad trabajamos más)
- Estancamiento de salarios y hasta ganancias en la industria
- Oligopolios mundiales, dado que no son más de 10 proveedores de LLMs que realmente «sacan la tarea»
Y desde el punto de vista de desarrollo de software ahora nos preocupamos también por:
- Guardrails, cómo crearlos y cómo colocar determinismo en algo que es eminentemente no-determinista (los LLMs)
- Control de costos, especialmente porque no todos los programadores estamos en la misma realidad. Esto ha impactado mucho más a solo/indie/freelance developers y ha hecho que nos hagamos creativos con consumo de tokens, persistencia de memoria, routers a distintos LLMs
- Control de contextos y alucinaciones. Hacer software siempre es una suma de contextos, entre necesidades del usuario, capacidades de una herramienta y novedades de una herramienta. En mi experiencia no han sido pocas las veces que un LLM me sugiere soluciones que ya no estan vigentes o simplemente las halucinó.
Siendo así, al día de hoy programar sin ayuda de IAs dejó de ser una profesión y se ve ya como algo artesanal, algo que se hace solo cuando queremos divertirnos, pero algo que ninguna empresa puede permitirse dado que su competencia está en la misma situación.
Y esto qué tiene que ver con Java
Si resumimos mi párrafo anterior, para mí en 2026 la profesión está así
El marketing promueve el movimiento del vibecoding/prompt engineer, las unidades de negocio quisieran que BDD fuera perfecto para ya no tener devs y a los devs les pasó por encima un tren que exige que ahora sean super T-Shaped con ayuda de la IA
Y de nuevo por experiencia el abordaje que yo sugeriría si alguien me preguntara es
Vuelvete t-shaped para saber cuando a una IA se le va la moto
Que en el «entorno Java» se traduce en:
- Entender no solamente Java como lenguaje de programación sino como plataforma
- Aprender programación como una ciencia y no como un arte. Es decir entender como mínimo los conceptos computacionales que hay detrás de
- Programación orientada a objetos y programación funcional
- Lenguajes scripting, lenguajes tipados, lenguajes declarativos
- Por fin entender a fondo las convenciones de los frameworks que utilizan, ya que si ni yo mismo los entiendo, mucho menos voy a saber si una IA está o no alucinando
- Aceptar que mucho del trabajo de aquí en adelante ya no va a ser crear SaaS, también necesitamos aprender a crear los agentes/servidores MCP que atienden a otros agentes
- Abordar los problemas de software como problemas de ingeniería, con retos técnicos pero también con retos arquitecturales, de diseño y presupuestarios
- Aceptar que habilidades que solían ser complementarias (DevSecOps, Linux, Coding Agents) ahora son el mínimo de la profesión, lo mínimo que se espera
Y sobre todo
No perdernos de la realidad del mercado, aceptar que la profesión ya no va a volver a ser la misma
¿Es Java un buen lenguaje en la era de los coding agents?
Dejando de lado mi sombrero de Java Champion, es una pregunta que me he hecho varias veces en este último año y (de momento) tengo las siguientes conclusiones:
Java como lenguaje es bueno pero no es el único bueno y aceptarlo está bien
Los lenguajes de programación de alto nivel jamás han sido herramientas para comunicarnos con las computadoras. Las computadoras entienden lenguaje máquina.
Los lenguajes de programación son abstracciones para que los humanos podamos expresar nuestras ideas y heredar las ideas de otros cuando trabajamos en el mismo proyecto. Y ahora también son lenguajes que los coding agents usan para implementar requerimientos de negocios y que nosotros, los humanos, podemos entender. Nosotros brindamos lenguaje natural (no determinista) y los LLMs nos brindan equivalentes en código (determinista).
En este sentido lenguajes como Java, TypeScript, C#, Rust o Go, tienen ventaja, está demostrado que los lenguajes típados en si mismos funcionan como «guardrails» y reducen las alucinaciones de tipo type check. Tal y como pasaba con los humanos, los compiladores y sistemas de tipos funcionan como «trancas».
¿Vale entonces la pena aprender a programar Java en 2026?
La respuesta corta es si, pero ya no como profesión sino como una habilidad más y ya no para todos los trabajos.
Claro que existen entornos donde soluciones «vibecoded» ya sacan la tarea, y van a seguir aumentando. Pero es mentira decir que TODA la computación se puede resolver con vibecoding al día de hoy (puede que en 5-10 años sea diferente).
Ahora con mi sombrero de educador, los generadores de código no son nuevos, lo que son nuevos son los generadores de código basados en IA. Incluso dentro del mundo Java no son pocos los generadores de código que hemos tenido durante décadas (JHipster, Hilla, Spring Roo, Telosys, Cuba Platform, por mencionar algunos).
Pero hasta que el vibecoding llegue a un punto de desarrollo donde ya no sean necesarios los lenguajes de programación de alto nivel, lo segundo mejor que tenemos es saber programar para ser el human in the loop.
¿Y por qué Java?. Durante años observé como profesor que alguien que aprende POO con Java se pasa fácil a cualquier otro lenguaje tipado porque ofrece un buen balance entre verbosidad, presencia en el mercado y caminos de transición hacia otros lenguajes. Asimismo, creo que C# también tiene esta «virtud».
Lo que nadie menciona, la búsqueda de trabajo
Hasta que el vibecoding «nivele el campo» para todos, debemos recordar que conseguir trabajo es un proceso eminentemente competitivo. De nuevo, analizando la realidad como ella es y no como nos gustaría que fuera, una simple búsqueda en linkedin les va a revelar que la IA pasó a ser obligatoria y los requisitos de habilidades técnicas no bajaron; en realidad, subieron.
Aunque podamos debatir todo el día que ya no es necesario saber programar porque la IA lo hace, la verdad es que los mejores trabajos están reservados para las personas que mejor supervisan a las IAs y esas personas generalmente saben programar. No todas las empresas pueden pagar Opus o Astra, y el juicio humano especialista tiene valor, diferente, probablemente más barato, pero aún lo tiene.
Qué se espera entonces del programador Java moderno
- Que ya no sea programador Java, en realidad se espera que sea un ingeniero de software más completo donde Java se usa porque es muy buena plataforma (ejemplos hay un montón)
- Que tenga mentalidad T-Shaped, que ya no solo sepa Java, que sepa de sistemas operativos, infraestructura, operaciones, arquitectura, patrones de diseño. En fin que su conocimiento técnico aumente y además tenga conocimiento de dominio
- Que domine los coding agents. Aunque la IA en sí misma es un pay-to-win, difícilmente un programador hoy va a sobrevivir sin un mínimo de experiencia usando Claude Code/Github Copilot/OpenCode
¿Y si el vibecoding finalmente se perfecciona?
Para mí la pregunta ya no es si lo va a hacer, es cuándo. La respuesta no la tengo y es muy dificil discernir entre la paja y el trigo, incluso más que con los cryptoposts. Pero cuando eso pase, la preocupación ya no va a ser si se acaban los programadores o no, es qué va a pasar con la humanidad y ahí, finalmente, a todo computín nos va a llegar la factura de nunca habernos preocupado por la política. Material para otro post.
