Hoy hay una idea que se repite mucho: la IA ya lo hace todo. Genera el código, lo testea, lo despliega y hasta responde los pull requests. Entonces, ¿para qué estudiar desarrollo de software? En este artículo te cuento de dónde sale esa percepción, qué está pasando de verdad con el vibe coding en estas semanas y por qué creo que sí vale la pena aprender, aunque no de la misma forma que antes.

El post viral: "nadie está pensando"

Todo empieza con un post de @v0xium del 20 de septiembre de 2026. Cuenta que lleva medio mes en un nuevo rol dentro de una gran empresa y que allí las especificaciones, el código, los tests, los PRD, los tickets y los reportes los hace Claude Code. La gente trabaja de 12 a 13 horas al día "solo para presionar Enter", nadie lee nada y, en sus palabras, en realidad ya nadie está pensando. El objetivo es producir, pase lo que pase.

El post superó los 8 millones de vistas y llegó también a Reddit. Según Business Insider, Elon Musk respondió con un "Yikes" y Chamath Palihapitiya lo comparó con tener a expertos técnicos apretando el botón de una tragamonedas.

¿Por qué se volvió tan popular? Porque resume muy bien lo que siente mucha gente que lleva años programando: los modelos producen mucho más código y hacen el trabajo pesado, pero se está trabajando más, pidiendo cambio tras cambio y confiando en que el modelo lo resuelva. Y eso no afecta solo a escribir código: también a la planificación, el despliegue y la revisión.

Vibe coding: clonar la suite de Adobe ya es posible

El ejemplo perfecto de esta semana es ArtCraft, un proyecto que quiere ser una alternativa completa a la suite de Adobe. Sus "Crafting Apps" incluyen PhotoCraft (Photoshop), LightCraft (Lightroom), FilmCraft (Premiere), VectorCraft (Illustrator) y PdfCraft (Acrobat), escritas en Rust y con commits firmados como coautor por Claude Opus 5.5. Lo cuenta muy bien este post de Vox, y Chris Titus lo celebró con un "Goodbye Photoshop".

Se llegó a decir que habían descompilado el código de Adobe, pero no: es una reescritura que toma como referencia las aplicaciones originales. El repositorio de PhotoCraft pasó en pocos días de unos miles a casi 30.000 estrellas. El problema es la usabilidad: su propio README dice que está en alfa temprana y que no reemplaza a Photoshop para el trabajo profesional del día a día, y muchas de las personas que lo probaron lo describen directamente como AI slop. Puedes ver todas las apps en getartcraft.com/apps.

Generar código ya no es el trabajo

Aquí está el primer punto importante: generar código ya no es el problema. Si mañana se te ocurre una idea, cualquiera puede pedirle a Claude que la genere y no va a tener ningún problema en hacerlo. Con el máximo nivel de esfuerzo y algo de conocimiento, una aplicación así se genera en unas horas.

El verdadero trabajo está en mantenerla. Un proyecto que promete ser "la alternativa compatible con Adobe" tiene que seguir cada actualización, corregir errores y no romperse. Eso es lo que el open source lleva años intentando, y no se resuelve generando un binario inicial.

Un matiz sobre lo que conté en el video: dije que este tipo de proyectos acaban buscando financiación. En el caso de ArtCraft no hay confirmación de que busquen inversión; según la prensa, su creador, Brandon Thomas, dice que el proyecto se paga con el negocio de ArtCraft.

Un compilador de TypeScript hecho con IA… que nadie va a mantener

El segundo ejemplo es de Theo, creador de contenido y de T3 Code. Publicó tsc-rs, un port a Rust del compilador de TypeScript 7 (el que Microsoft reescribió en Go), generado con IA. Según sus propios benchmarks, en algunos proyectos es más rápido que tsc 7, y Theo reconoció que no ha leído ni una línea del código.

Lo interesante vino después. Cuando le preguntaron si lo iba a mantener, dejó claro que no tenía intención, y en otro post dijo que no nos preocupáramos: Claude se encargaría de revisar los issues de GitHub y lanzar flujos de trabajo para resolverlos. Es el vibe coding del vibe coding: ni siquiera el mantenimiento queda en manos de una persona. Kyle Mistele se burló resumiéndolo como "anunciamos que reescribimos TypeScript en Rust y es 400 % más rápido, pero no lo mantenemos".

bun check: cuando sí sabes lo que haces

En la misma semana, Bun presentó bun check, un type checker de TypeScript integrado en Bun y escrito en Rust. Jarred Sumner, su creador, lo ve como un paso para que JavaScript y TypeScript compilados compitan en rendimiento con Go.

Según las cifras de Bun, es entre 3 y 7 veces más rápido que tsc 7, y en el propio README de tsc-rs aparece por delante del proyecto de Theo. Recuerda además que Bun forma parte de Anthropic desde diciembre de 2025 y es lo que usa Claude Code.

¿La diferencia? Jarred se dedica a construir compiladores e intérpretes desde antes de la IA. Ambos usan IA, por supuesto, pero cuando una persona técnica sabe lo que está pidiendo, el resultado es otro. Si vas a ciegas, eso es vibe coding; si sabes lo que estás haciendo y lo que estás pidiendo, eso es ingeniería estos días.

El testing también está cambiando

No todo es escribir código: también está la revisión, y eso cambia muy rápido. Están apareciendo frameworks de testing pensados para agentes, como e2e de TesterArmy, donde el test se parece mucho a uno de Jest o Vitest, pero algunos pasos se escriben en lenguaje natural ("actualiza el plan") y los ejecuta un agente.

La idea es combinar un resultado determinista (abrir esta página siempre es lo mismo) con uno no determinista (una acción que puede variar). En el fondo sigue siendo código por debajo, solo que una parte del test la escribes como texto.

Contribuciones con IA: System76 dice que no

Antes, si encontrabas un error en un proyecto, abrías un issue o mandabas un pull request. Hoy tu agente lo puede hacer por ti, y no a todos los proyectos les gusta.

System76, la empresa que vende equipos con Linux (Pop!_OS) y desarrolla el escritorio COSMIC, cambió el 30 de septiembre su plantilla de pull requests: quien contribuya debe confirmar que no incluyó contenido generado por un LLM, ni código, ni comentarios, ni descripciones. Lo difundió The Lunduke Journal. El motivo es la carga de revisión: cualquiera puede pedirle a Claude que mande un PR, aunque el problema ya esté resuelto, y los mantenedores tienen que revisarlo igual.

IA que revisa lo que escribe la IA

Del otro lado, cada vez más proyectos usan IA para recibir esas contribuciones: herramientas como CodeRabbit o la revisión de código de GitHub Copilot leen el PR, categorizan el error y responden antes de que llegue a una persona. Al final, tú envías un PR con IA y otra IA te lo recibe.

Omarchy: el sistema operativo financiado con tokens

DHH, el creador de Ruby on Rails, es de los que abrazan este cambio. Su proyecto Omarchy es open source, pero está financiado: usa un bot, Omabot, para revisar la avalancha de PR que recibe, y en octubre SpaceXAI se sumó como patrocinador con 1,5 millones de dólares en tokens de Grok, después de que Meta aportara otro tanto.

Así como se están vibe-codeando aplicaciones web y de sistema, lo siguiente es el sistema operativo. Si a eso le sumas que las contribuciones también las procesa la IA, se cumple justo lo que decía el primer post: todo se está haciendo con IA.

¿El software está muerto?

Si llevas años desarrollando, es probable que pienses que el software está muerto. Si acabas de empezar, puede que creas que ya no tiene sentido aprender. Las dos percepciones están bastante mal.

DHH lo explicó con las etapas del duelo: habló de programadores en plena "etapa de la ira" frente a la máquina. Negación, ira, negociación, depresión y aceptación: muchos estamos en alguna de ellas. Hasta Notch, el creador de Minecraft, que durante meses rechazó la IA, admitió el 22 de septiembre que está disfrutando del vibe coding y que puede que se haya equivocado "un poquito".

Mi recomendación es llegar a la aceptación, porque estos modelos no se van a ir. Opus 5.5 o GPT-6 Astra ya generan software bastante complejo.

Escribir código a mano ya murió (entenderlo, no)

Escribir código a mano era algo que tarde o temprano iba a dejar de ser necesario, y pasó antes de lo esperado. No importa si lo escribes tú o lo genera la IA: importan los resultados. ¿Es rápida la aplicación? ¿Resuelve el problema? ¿Escala? ¿Se puede extender con el tiempo?

Para responder eso necesitas entender lo que hace el modelo: redes, diseño de sistemas, algoritmos, seguridad. Ya no lo hacemos todo a mano, lo delegamos, pero para delegar bien tienes que saber lo que estás haciendo. Eso es lo que te diferencia de alguien que abre un agente y pide una aplicación.

Los buenos modelos cuestan

Otro motivo por el que mucha gente no usa todo esto es el precio. Con las suscripciones de 20 dólares sueles quedarte corto para un proyecto completo: esperas horas a que se recarguen los límites o no tienes los mejores modelos. En la práctica, los modelos de frontera de Anthropic y OpenAI empiezan en unos 100 dólares al mes, y siguen por delante de los modelos chinos. Eventualmente podrás ejecutar modelos muy buenos en local, pero para entonces los grandes estarán haciendo cosas todavía más complejas. Si quieres ver qué importa de verdad en todo esto, te dejo mi video sobre modelos, harnesses y orquestadores.

Entonces, ¿vale la pena aprender a programar?

Yo diría que sí, pero no como antes. No se trata de escribir todo el código continuamente, sino de entender las bases. Es como aprender a escribir: aunque existan herramientas que generan artículos, igual pasas por el aprendizaje, la repetición y la escritura para tener esa habilidad. Con el código pasa lo mismo: necesitas las bases de un lenguaje para entender lo que hace un modelo por debajo.

Yo mismo tengo la IA conectada a casi todo: correos, pull requests, corrección de errores, facturas. Pero igual hay trabajo, porque alguien tiene que revisar que todo salga bien. Un mensaje mal redactado te puede costar un cliente, un error puede costarte usuarios y una factura mal hecha, dinero.

Qué estudiar: diseño de sistemas

Si de verdad te quieres dedicar a esto, estudia código, y después diseño de sistemas: cómo construir sistemas complejos que se puedan desplegar, lo que implica conocer redes, nube, lenguajes y frameworks. El vibe coding está muy bien para llevar una idea a cabo o para apps pequeñas (seguimiento de gastos, notas, una tienda simple), pero cuando hablamos de sistemas para gobiernos, clínicas o bancos, necesitas desarrollo de software real y procesos de ingeniería. Y hoy aprenderlo es más fácil que nunca, porque tienes modelos que te lo pueden explicar a tu ritmo.

Conclusión

  • Generar código ya no es el trabajo: mantenerlo, revisarlo y entenderlo, sí.
  • Los proyectos vibe-codeados como ArtCraft o tsc-rs muestran que lanzar es fácil; lo difícil es sostenerlos.
  • Aprender a programar sigue valiendo la pena, pero enfocado en las bases y en el diseño de sistemas.

¿Crees que esto es una exageración o ya lo estás viendo en tu trabajo? Cuéntamelo en los comentarios del video.

Fuentes