Generar código no es lo mismo que construir un producto
15 de marzo de 2026
Hace unos días vi una imagen de una charla de Javi Velasco en la JSConf España 2026 que me quedó dando vueltas:
Models are now pretty good at generating code. But generating code is not the same as generating a software product.
Javi es Tech Lead en Vercel desde 2017, con contribuciones como Vercel Middleware y Vercel Fluid Compute. Alguien que lleva años en la trinchera de productos reales, no hablando desde la teoría. En un momento de tanto ruido alrededor de la IA, agradezco voces así en la comunidad: que cortan el hype y aterrizan lo que realmente importa. La charla completa vale mucho la pena, la tenéis aquí.
Y tiene razón. Y creo que muchos en la industria todavía no han terminado de procesar lo que eso implica.
La codificación dejó de ser el cuello de botella
No digo que programar ya no importa. Digo que ya no es el cuello de botella.
Hace tres o cuatro años, la pregunta era "¿sabes hacer esto?". Ahora esa pregunta la resuelve Cursor, Claude o Copilot en segundos. El que sabía más sintaxis, más patrones, más librerías, tenía una ventaja clara. Esa ventaja se está erosionando rápido, y creo que hay que ser honesto con eso en vez de ignorarlo.
He visto proyectos donde la IA genera componentes perfectamente estructurados, bien tipados, con tests incluidos. Y aun así el producto no funciona. No falla el código. Falla la comprensión de para qué existe ese código.
Lo que no puede hacer un modelo por ti
Un modelo puede escribirte el componente. No puede decirte si ese componente debería existir.
No puede entender que el usuario que vas a tener no es el usuario que imaginaste. No puede saber cuándo algo técnicamente correcto es un error estratégico. No puede priorizar cuando dos decisiones válidas chocan entre sí. No puede decirte "esto no tiene sentido para quien va a usarlo" antes de construirlo.
Y aquí hay algo que me parece relevante: los mejores prompts no los escribe el que sabe más TypeScript. Los escribe el que entiende mejor el problema.
El criterio como diferenciador
Lo que noto que empieza a distinguir a unas personas de otras no es cuánto saben de código, sino cuánto saben de lo que están construyendo y para quién.
Criterio de producto: saber qué construir, en qué orden y por qué. Capacidad de síntesis: convertir una necesidad vaga en algo concreto y accionable. Pensamiento en usuarios reales, no en casos de uso abstractos. Entender el negocio lo suficiente como para hacer las preguntas correctas antes de que lleguen al "cómo".
Todo eso sigue siendo tuyo. La IA no te lo quita, al contrario: lo amplifica si lo tienes, y lo deja al descubierto si no.
¿Esto asusta?
Sí, y es normal. A mí también me genera incomodidad. He dedicado años a mejorar como developer, a aprender patrones, arquitecturas, a entender el runtime, a escribir código que no avergüence. Y ahora me digo: ¿es suficiente con eso?
No creo que ya no sea suficiente. Creo que solo eso ya no es suficiente.
El conocimiento técnico sigue siendo la base. Lo necesitas para evaluar lo que genera la IA, para corregirlo, para entender sus limitaciones, para no publicar algo que parece que funciona pero que revienta en producción bajo condiciones reales. Pero por sí solo, sin contexto de producto, sin entendimiento del negocio, sin empatía con el usuario... ese conocimiento se está convirtiendo en commodity más rápido de lo que muchos quieren admitir.
Lo que haría si empezara ahora
Si empezara hoy, invertiría tiempo en entender cómo piensan los product managers y los diseñadores. Leería sobre estrategia de producto, no solo sobre frameworks. Intentaría estar en las conversaciones sobre el "por qué" antes de que lleguen al "cómo". Y sobre todo, practicaría tomar decisiones con información incompleta, que es exactamente lo que hace el trabajo de producto difícil e irreemplazable.
Porque el developer que entiende el producto puede dirigir a la IA. El que solo sabe código, cada vez más, es dirigido por ella.