Acabo de ver un artículo titulado "Un año de vibraciones", que es un resumen muy representativo de Vibe Coding durante el año pasado. Puede que muchas personas no estén familiarizadas con el autor Armin Ronacher, pero si alguna vez has usado Python, lo más probable es que hayas utilizado su trabajo: el framework Flask, que es su creación de hace más de una década. La primera frase del documento me resonó: En 2025, ya no escribiré código como solía hacerlo. Similar a su experiencia, una persona que lleva casi veinte años programando ahora convierte su trabajo principal en dirigir la IA para escribir código. Compara esto con pasar de ser un "programador que escribe personalmente en el teclado" a un "líder técnico de un becario virtual". Mi propio cambio hacia Vibe Coding surgió de Claude Code, y también el suyo. Alrededor de abril o mayo de este año, se enfrascó en el uso de Claude Code. En pocos meses, publicó 36 artículos en su blog, lo que representa el 18 % de todos los artículos publicados desde 2007. Esto no se debió a que tuviera más tiempo libre, sino a que la IA lo había liberado del tedioso trabajo de implementación. Actualmente usa tres herramientas de programación de IA simultáneamente: Amp, Claude Code y Pi. Comparó estas tres herramientas con Porsches: refinados y sofisticados; Claude Code es como un Volkswagen: asequible y potente; y Pi es un juguete de código abierto para hackers. Tres herramientas, tres estilos distintos, pero no sabría decir cuál es mejor. Personalmente, uso principalmente Codex, complementado con GitHub Copilot y Claude Code. Calculo que si se realizara una encuesta, cada uno elegiría herramientas de programación de IA diferentes, porque todos utilizan "vibras". La palabra "Vibraciones" aparece a lo largo del artículo y también es el origen del título. Literalmente, significa "atmósfera" o "sensación", pero aquí se refiere a un criterio de juicio que no se puede cuantificar y solo se puede sentir intuitivamente. Esto podría ser lo más extraño de la programación de IA en 2025: la experiencia de ingeniería acumulada durante cincuenta años en una industria de repente pierde eficacia. Los estándares de código y las mejores prácticas, al enfrentarse al código generado por IA, se basan en una especie de misticismo: este modelo se siente más cómodo, esa herramienta se siente más cómoda de usar. El grupo más racional de programadores ahora elige su pila tecnológica de la manera más emocional. Armin llevaba un año entero lidiando con el MCP (Protocolo de Contexto Modelo), pues lo consideraba poco fiable. Sin embargo, carecía de datos que lo respaldaran, y solo pudo decir: «De todas formas, no me funciona». Mientras tanto, otros lo usaban con entusiasmo. Su amigo Peter, quien le había presentado a Claude a principios de año, ahora usaba Codex y lo encontraba excelente. Armin lo probó, pero no le pareció tan atractivo. ¿Quién tiene razón y quién no? No hay respuesta. Todos andan a tientas en la oscuridad. Un sentimiento más profundo de malestar surge de la relación entre los humanos y las máquinas. Empezó a desarrollar una especie de "vínculo parasocial" con estas herramientas, lo que puede entenderse como una sensación de intimidad unidireccional. Es el tipo de proyección emocional que se tiene hacia cierto streamer o ídolo; aunque la otra persona no te conozca en realidad, siempre te sientes muy familiarizado con ella. ¿Por qué una herramienta de IA evocaría este sentimiento? Porque la IA moderna puede recordar cosas. Puede recordar cosas que ya has discutido con ella. Está empezando a mostrar signos de tener una "personalidad". Armin dice que se ha estado entrenando durante los últimos dos años, tratando estos modelos como "mezcladores de fichas": máquinas puramente probabilísticas. Pero esta perspectiva simplista ya no le funciona. Estos sistemas exhiben tendencias humanas, pero elevarlos a un nivel humano es un error. ¿Qué son exactamente? Nadie puede dar una buena definición. Armin incluso empezó a tener dificultades con la palabra "agente", ya que la agencia implica autonomía y responsabilidad, y estas dos cosas deberían permanecer en manos humanas. Esta confusión sobre "no saber cómo llamarlo" dice mucho. Al final del artículo, enumeró varios puntos críticos que esperaba que la industria pudiera abordar. El primero es el control de versiones. Git y GitHub son herramientas esenciales para los programadores, pero actualmente carecen de un dato crucial: las indicaciones. Cuando la IA genera código, no se puede juzgar la calidad de un cambio simplemente observando la versión final. Es necesario ver qué comandos generaron este código y qué desvíos se tomaron en el proceso. Aún más interesante es uno de sus hallazgos: los intentos fallidos son valiosos para la IA. Si se guía a la IA a un estado anterior, se busca que recuerde qué rutas fallaron. Pero nuestras herramientas actuales no están diseñadas con esta funcionalidad en mente. Si se borra el historial de una conversación, la IA repetirá los mismos errores. El segundo problema es la revisión de código. La interfaz actual de revisión de GitHub tiene un diseño ridículo: no se puede revisar formalmente el propio código, solo se pueden dejar comentarios. Pero en la programación de IA, los programadores a menudo necesitan dejar instrucciones para la IA en sus solicitudes de extracción. El proceso actual no contempla en absoluto este tipo de colaboración entre humanos y máquinas. El tercero es la observabilidad. Este es un tema un poco más técnico, pero la idea central es que muchas herramientas de monitorización y depuración no se utilizaban antes por su complejidad, pero la IA destaca en la gestión de problemas complejos. Es posible que sea necesario recuperar la visibilidad de aquellas soluciones que se han dejado de lado. Finalmente, abordó un tema un tanto delicado: algunas personas se han despreocupado por completo, dejando de revisar el código generado por IA y simplemente dejándolo funcionar. ¿Es una locura? Sí, una locura. Pero Armin ha visto a gente hacerlo con bastante éxito. Él mismo aún no puede hacerlo; sigue revisando cuidadosamente cada línea. La existencia de algo implica su razón de ser, y la existencia de este enfoque de no intervención indica que está tomando forma una forma de trabajar completamente nueva. Este enfoque es completamente diferente de los métodos de ingeniería de software con los que está familiarizado. Esto está causando problemas a la comunidad de código abierto. Cada vez más solicitudes de extracción (PR) son generadas por IA indiscriminadamente, sin filtro humano. Para los mantenedores que aún se adhieren a los procesos tradicionales, estas PR son prácticamente un insulto. La solución de Armin es escribir directrices de contribución detalladas y plantillas de PR, pero sabe que esto es como si Don Quijote luchara contra molinos de viento. Quizás la solución no sea conseguir que otros lo modifiquen, sino conseguir que esos usuarios ruidosos que apoyan la programación con IA den un paso al frente y demuestren lo que significa "escribir código con IA de manera responsable". Este artículo me impactó; se puede percibir la genuina confusión de un ingeniero sénior. No es el tipo de predicador que alaba la IA, ni es un intransigente que se niega a cambiar. Está atrapado en el medio, usando la IA con intensidad y al mismo tiempo albergando un profundo escepticismo. A medida que 2025 se acerca a su fin, ninguna de las preguntas que planteó ha recibido respuesta: ¿Cómo censuramos el código de la IA? ¿Cómo preservamos el recuerdo de sus fallos? ¿Cómo mantenemos una distancia prudencial con una herramienta que nos evoca emociones? Las respuestas a estas preguntas pueden ser la dirección para el próximo lote de productos exitosos.
Cargando el detalle del hilo
Obteniendo los tweets originales de X para ofrecer una lectura limpia.
Esto suele tardar solo unos segundos.
