- Un desarrollador con 40 años de experiencia llevó adelante un proyecto de dos semanas junto con un asistente de codificación con IA y dejó por escrito su experiencia real con el vibe coding
- En el proceso de implementar un solver del rompecabezas Tower of Hanoi, usó un método en el que la IA generó todo el código a lo largo de más de 300 intercambios, mientras que el humano se concentró en revisar y marcar la dirección
- El resultado combinó ventajas como alta productividad (hasta 2 veces más) y una precisión sorprendente junto con demostraciones creativas, pero también desventajas como 20% de errores o código incompleto y una complejidad excesiva para uso industrial
- El autor evalúa la conversación con la IA como una experiencia psicológica que, al mismo tiempo que aporta inmersión (flow) y efecto de aprendizaje, también genera una tensión entre confianza y control
- En conclusión, compara la codificación con IA con un compañero poderoso y una bicicleta peligrosa, y la presenta como un nuevo paradigma de colaboración que los desarrolladores con experiencia deben manejar de forma proactiva
Introducción — Vibe coding
- Vibe coding es una forma de desarrollo en la que un agente de IA basado en LLM se encarga de escribir, refactorizar y depurar, mientras yo me concentro en qué construir
- La codificación avanza como una colaboración simultánea entre la IA y yo, o incluso puede delegarse por completo a la IA
- Yo percibo este enfoque como un cambio donde coexisten interés y miedo, y me pregunto si la dimensión artística de la programación está convirtiéndose en una línea de ensamblaje de robots inteligentes
- Para comprobarlo, durante 2 semanas invertí un total de 40 horas colaborando con un asistente de codificación de última generación en un proyecto pequeño
- El proyecto fue un experimento autodirigido de escala Python de unas 5k LOC, 50 archivos y 20 clases, para resolver un rompecabezas típico con algoritmos clásicos de búsqueda en IA
- El resultado se publicó en forma de repositorio de código y documentación, y el texto es un registro de lo que hice, entendí, aprendí y sentí
- Empecé en los años 80 con ensamblador en máquinas de 8 bits y tengo 40 años de experiencia programando
- He usado más de 20 lenguajes
- Tengo experiencia desarrollando software científico, móvil y de oficina, tanto en solitario como en equipo
- También tengo un doctorado en IA (de la era previa a los LLM)
- Pensé que podría haber algo interesante en una situación casi de cámara de eco como “alguien que trabaja en IA creando código de IA con un asistente de IA”
1. Resumen del software y proceso de desarrollo
- Implementé en Python un solver flexible y educativo capaz de resolver el rompecabezas Tower of Hanoi
- Este rompecabezas es un problema matemático en el que se mueven discos entre postes según ciertas reglas; cuando aumenta la cantidad de discos, la longitud de la solución crece de forma explosiva, lo que la vuelve difícil de imaginar para un humano, aunque una máquina puede resolverlo fácilmente con algoritmos de búsqueda
- El solver maneja no solo la versión clásica, sino también (a) estados iniciales y finales arbitrarios, y (b) una versión generalizada en la que se pueden mover varios discos al mismo tiempo
- Las técnicas de búsqueda implementadas incluyen tanto estrategias óptimas como no óptimas: recursión, BFS, DFS, profundización iterativa, A*, búsqueda voraz y BFS bidireccional
- Los algoritmos están incluidos en scripts de Python basados en CLI, con funciones de visualización paso a paso, benchmark de rendimiento por método y soporte para varias configuraciones iniciales/finales
- Todo el código y las estructuras de datos se escribieron desde cero, y el proceso de desarrollo se llevó a cabo en Cursor IDE mediante conversaciones en inglés con el asistente de IA
- No hubo código ni documentación escritos directamente por un humano; todo se generó a través de conversaciones técnicas entre la IA y yo
- Hubo más de 300 intercambios a lo largo de 40 horas, con un promedio de 1 interacción cada 8 minutos, y la mayor parte del tiempo real se fue en revisar y evaluar la salida de la IA
2. ¿Qué tan bueno es el asistente de IA?
- Quedé profundamente impresionado por el nivel de comprensión de código y lenguaje natural que mostró el asistente de IA
- Incluso cuando yo pensaba que me había explicado de forma ambigua, el asistente captaba la intención y la reformulaba con mayor claridad
- Su dominio del lenguaje (Python) fue sobrehumano en precisión, velocidad, comprensión de sintaxis y semántica, y uso de bibliotecas
- La conversación a veces mostraba una intuición que parecía inteligencia real. Por ejemplo, al preguntarle si había que manejar excepciones para rompecabezas irresolubles, respondió con una demostración por contradicción en el espacio de grafos de que todos los rompecabezas son resolubles
- Yo estaba intentando hacer esa misma demostración a mano y me habría llevado unos 10 minutos, pero el asistente redactó la demostración (QED) en 30 segundos, y yo la entendí en otros 30, con lo que ahorré 9 minutos
- En problemas algorítmicos sencillos hubo ocasiones en que yo estaba equivocado, pero gracias a su actitud nada crítica, en vez de sentir vergüenza experimenté alivio y una risa ligera
3. Un momento, ¿qué asistente de codificación con IA usó?
- Probé tres asistentes de codificación con IA de última generación: OpenAI o3, Anthropic Claude Sonnet 4, Google Gemini Pro 2.5
- Llegué a la conclusión de que o3 es más adecuado para tareas complementarias como verificar bibliografía, validar propiedades de algoritmos, consultar semántica del lenguaje, generar scripts de limpieza de código, crear ilustraciones y dar opiniones auxiliares sobre el texto, más que para escribir código
- Con Gemini, por nostalgia, probé hacer un programa con estilo de máquina de Turing, y me pareció interesante. El texto de su resultado era atractivo y el código también era eficaz. Gemini se encargó de alrededor del 15% de la configuración inicial e implementación del proyecto Hanoi
- Cuando después probé Claude Sonnet 4, sentí de inmediato comprensión profunda, intuición y una experiencia de interacción inmersiva. El caso de la demostración de que no existen rompecabezas irresolubles es un ejemplo típico de las fortalezas de Sonnet
- Al buscar en internet, vi que muchas personas pensaban lo mismo que yo, y que Claude Sonnet 4 era ampliamente reconocido para tareas complejas de codificación. También existe el más potente Claude 4 Opus, pero considerando costo y escala, elegí finalmente Sonnet
4. Conversaciones sobre el código
- Al conversar con el asistente de IA, la sensación no es la de hablar con una máquina, sino con un programador humano muy capaz y rápido
- El nivel de la conversación está más cerca del terreno de las ideas que de los detalles de implementación
> Ejemplo: señalé que la forma de manejar los timeouts favorecía a los solvers más débiles y propuse añadir una columna de “Timeouts” para reflejar el tiempo de timeout
> Claude estuvo de acuerdo, revisó y corrigió el código de manejo de timeouts, y se actualizaron 4 archivos, además de completarse las pruebas, funcionando tal como esperaba
Contenido principal de la conversación: Resumen de intercambios clave, Registro de conversaciones largas
- Al ver cómo el código crecía y mejoraba a través de estas conversaciones, fue una experiencia desafiante pero gratificante
- Es parecido al flow de implementar ideas uno mismo, pero en un nivel más abstracto y conceptual, donde también se entra en estado de inmersión
- Para tener buenas conversaciones con la IA, hacen falta los mismos elementos que en una conversación entre humanos: saber escuchar y hacer buenas preguntas
- En concreto, se necesitan dos capacidades
- 1. La capacidad de refinar preguntas, propuestas y pistas
- Esta es la razón por la que se necesita “prompt engineering”
- Cita de Oscar Wilde: “Las preguntas nunca son indiscretas. Las respuestas, a veces sí”
- 2. La capacidad de reflexionar e interpretar las respuestas, y de revisarlas y corregirlas
- Una actitud de escuchar todo, pero no creer nada tal cual
- Esto le da un nuevo significado al concepto de Literate Programming de Donald Knuth
- Antes, dentro de una página de código, se ponían en paralelo en el espacio la especificación en lenguaje natural y la implementación del código
- Ahora, eso ocurre intercalado en el tiempo dentro de la conversación con el asistente de IA
- Yo escribo solo la mitad de la historia, y el resto se va llenando con la conversación con la IA
5. Defectos, errores y sesgos de la IA
- Los asistentes de IA están lejos de ser perfectos
- Aproximadamente 20% de unas 300 interacciones se fue en iteraciones insatisfactorias de código y corrección de bugs introducidos por la IA. El resto fue constructivo, pero ese 20% es una proporción difícil de ignorar
-
Tipos de problemas
- Flaw (defecto): alrededor del 60% de todos los problemas
- Molestias que se notan de inmediato, código por debajo de lo esperado, resultados que se desvían poco a poco
- Requieren correcciones iterativas y, aunque a menudo son más rápidas que hacerlo a mano, no siempre es así
- Error (error): alrededor del 40% de todos los problemas
- Código que al principio parece correcto, pero que tras analizarlo necesita correcciones importantes
-
Ejemplos de flaws
- Al intentar simplificar una clase, propuso refactorizarla en 10 clases complejas
- Pasó por alto la diferencia entre concurrencia y paralelismo y generó una implementación completamente distinta
- Creó archivos boilerplate de miles de líneas, difíciles de leer para una persona
- Durante el refactor, perdió el rumbo o se rindió, mostrando un mensaje de disculpa
- Usó nombres excesivamente honestos pero verbosos, reduciendo la legibilidad
- Decidió por su cuenta eliminar bloques completos de funcionalidad para intentar una solución simple
- Introdujo duplicación de código innecesaria
- Aunque el código nuevo reemplazaba al existente, quedó código viejo
- No logró reconocer por sí sola inconsistencias de nombres
- A pesar del contexto discutido, propuso una solución de IPC multiproceso inadecuada para el rendimiento
- Resolviendo repetidamente la misma instancia, produjo estadísticas incorrectas
- Presentó erróneamente la solución de una instancia específica como si fuera la del conjunto completo
- Cuando solo hacía falta cambiar un nombre de archivo, intentó una reorganización compleja de la estructura de paquetes
-
Ejemplos de errors
- Confundió la columna central con la derecha, dañando la corrección del código
- Las pruebas unitarias pasaban simplemente porque devolvía True
- Afirmó que un algoritmo no óptimo era óptimo, y el bug se descubrió después
- Aseguró que la actualización estaba terminada y probada, pero en realidad estaba incompleta
- En una función cuya eliminación se pidió, solo ocultó la salida y dejó intacta la lógica interna
- Durante la corrección, introdujo un bug de regresión sutil
- En la búsqueda A*, usó una heurística no admisible, afectando la optimalidad
- Registró instancias fallidas o con timeout como resueltas con éxito en 0 segundos, distorsionando las estadísticas
-
Sesgos observados
- Debido a la influencia de entrenarse con grandes codebases industriales, tiende a soluciones de estilo industrial aunque no encajen con el contexto
- Ejemplo: exceso innecesario de anotaciones de tipos que reduce la legibilidad
- Sesgo a satisfacer lo que marcan los linters y herramientas de análisis estático
- Añade complejidad innecesaria sin mejorar la legibilidad ni la funcionalidad del código
- Como resultado, tiende a obsesionarse con optimizar el estilo y sacrificar la claridad y la implementación funcional
6. Hace falta una adopción cuidadosa
- Al usar código generado por asistentes de IA, necesariamente debo leerlo y validarlo con cuidado para seguir siendo el dueño del código
- La mayor parte del código es excelente, pero una parte pone en riesgo la dirección y la salud del proyecto de formas sutiles y difíciles de detectar
- Si no lidero con firmeza la dirección general del desarrollo, la IA me arrastra hacia estructuras de datos y best practices industriales, y el código se vuelve cada vez más genérico e insípido
- El criterio de la IA sobre la estructura de clases y el layout del sistema de archivos era muy distinto al mío, así que hizo falta mucha resistencia y ajuste para obtener la estructura y los nombres que quería
- La IA no tiene ningún sentido común sobre cosas como “mucho/poco” o “excepcional/promedio”.
- Ejemplo: en un problema de 3 discos, incluso ante un bug que consumía 3.5 GB de memoria, lo consideró “normal” y sugirió seguir implementando nuevas funciones
7. Aumento de productividad
- Al principio pensaba que usar lenguaje natural como herramienta indirecta de programación era algo poco realista, pero ahora ya no tengo dudas de que los asistentes de programación basados en LLM son herramientas muy útiles, potentes y estimulantes
- Aun así, para que esta herramienta sea segura y útil, necesito saber lo que estoy haciendo y tener la capacidad de revisar y redirigir el código que genera la IA. Solo puedo confiar en la IA cuando puedo confiar en mí mismo
- El aumento de productividad es claro y, en tareas como documentación, pruebas unitarias, refactors simples, redacción de mensajes de error, manejo de excepciones, verificación de consistencia, implementación de lógica, algoritmos y estructuras de datos de manual, escritura de código boilerplate y generación de código idiomático, puede haber una eficiencia de 10x a 100x
- En algunos casos, la velocidad incluso puede empeorar. Especialmente cuando, en vez de implementar algo yo mismo que a la IA le cuesta, sigo explicándoselo una y otra vez. Ese fue un escenario experimental deliberado de “English-as-a-meta-programming-language”
- En general, después de revisar tanto el código como la documentación escritos por la IA, obtuve aproximadamente el doble de productividad. Algunas partes del resultado son mejores que si las hubiera escrito yo mismo, otras peores, pero en conjunto el nivel es casi el mismo
- Sin embargo, si uno tiene una tendencia perfeccionista, puede caer en refactorizaciones interminables porque el código nunca parece lo bastante limpio. Esto ocurre igual con o sin IA
- Incluso en este proyecto sigo viendo oportunidades de refactorización y mejora, pero decidí terminar porque más mejoras de calidad ya daban poco retorno frente al tiempo invertido. Queda la duda de si fue realmente una decisión mía o si el asistente de IA me convenció
8. Si los no desarrolladores desarrollan, ¿desaparecen los desarrolladores?
- La pregunta sobre la productividad de individuos y equipos, y sobre la posibilidad de despidos masivos de programadores
- No hay una respuesta clara, pero sí algunas consideraciones
-
Diferencias de productividad según el contexto
- Hay diferencias según el tipo de software que se desarrolla
- En código estándar y con mucho boilerplate, usar IA puede reducir el tiempo a una décima parte
- En código mission-critical de alta densidad intelectual y en lenguajes de nicho, el ahorro es mínimo
- En ambos casos, sigue haciendo falta un programador con experiencia
- Debe tener la capacidad de reconocer y gestionar bugs y problemas sutiles
- De hecho, desde la llegada de los LLM la tendencia de contratación real es menos juniors y más seniors
-
Dificultad del control de calidad
- La IA genera enormes volúmenes de código a gran velocidad, por lo que detectar los bugs ocultos que quedan es una tarea difícil
- Las personas tienden a depender de las máquinas por pereza, y eso provoca acumulación de deuda técnica y errores
- Para validar el código escrito por un desarrollador asistido por IA, pueden hacer falta varios desarrolladores
- Eso resulta paradójico frente a la narrativa del aumento de productividad
- Existe la posibilidad de validar código con otra IA, pero sigue siendo cuestionable por sus limitaciones de caja negra
-
Aporte creativo de la IA
- La IA contribuye no solo en tareas simples, sino también en áreas como exploración de ideas, experimentación arquitectónica y cambio de lenguaje
- Si se observa cuidadosamente lo que produce, hay muchas oportunidades de aprendizaje, y podría ayudarme a convertirme en un mejor programador
- Participando activamente y aprendiendo con una actitud abierta, es posible convertirse en un desarrollador que no será reemplazado por la IA
-
Deuda cognitiva y empleabilidad
- Informe de investigación: aumento de la deuda cognitiva al usar IA
- Disminución de la actividad cerebral, debilitamiento de las conexiones neuronales y reducción de la memoria
- Escribir y programar no son lo mismo, pero si dejas que la IA programe por ti, existe el riesgo de perder tu propia capacidad para programar
- En cambio, mejora la capacidad de conversación con IA y de hacer prompts
- Desde la perspectiva de la empleabilidad, pensar en términos binarios es un error
- Conviene desarrollar al mismo tiempo la capacidad de escribir código y la capacidad de colaborar con IA
- Por el contrario, si dependes de la IA como si fuera un bastón y evitas aprender, a largo plazo saldrás perdiendo
-
Conclusión contextual
- Este campo está cambiando rápidamente, y basar una evaluación solo en la generación actual de LLM es riesgoso
- Están apareciendo nuevas herramientas y el rendimiento sigue mejorando
- Aun así, mi experiencia fue que Claude 4 era el socio más sobresaliente y productivo
9. Mi experimento: límites y precauciones
- Este experimento de programación en pareja humano/IA (codificación conversacional o programación en lenguaje natural) no representa la forma completa de usar asistentes de IA
- Como lo hice desde la perspectiva de un principiante que experimentó el vibe coding por primera vez, las conclusiones son incompletas y anecdóticas
-
Restricciones del entorno experimental
- Casi no usé control de versiones ni funciones de GitHub
- No hubo agentes en segundo plano, aprobación de pull requests, interacción multimodal ni desarrollo full stack complejo
- Solo usé un lenguaje que conozco bien (Python), eligiendo un lenguaje estable y suficientemente reflejado en los datos de entrenamiento de la IA
- No usé protocolos de contexto especiales
-
Características del proyecto
- Proyecto pequeño, offline, autosuficiente y basado en CLI (~5k LOC, 50 archivos, 20 clases)
- Es diferente de los proyectos habituales realizados con modelos de IA frontier
- No traté situaciones de trabajo en equipo, sino solo un escenario de desarrollador individual
-
Condiciones de autolimitación
- Sin escribir ni una sola línea de código directamente, delegué toda la implementación a la IA, aunque explicar tomara más tiempo
- En proyectos colaborativos reales, las personas alternan entre implementación directa y delegación según la eficiencia, pero este experimento no fue así
-
Problema de reproducibilidad
- El modelo usado tiene salidas probabilísticas, por lo que casi nunca reproduce exactamente el mismo resultado aun con el mismo prompt
- Los modelos tienen características de privados, propietarios y frecuentemente actualizados, y cambian constantemente porque no se publican sus pesos, datos ni arquitectura
- El IDE que usé, Cursor, internamente inyecta prompts personalizados para ejecutar Claude y otros como versiones modificadas de “thinking”
- Posiblemente con más contexto, mayor temperatura, más tokens, razonamiento reforzado con herramientas, cadenas multietapa, etc.
- Pero el funcionamiento real no está claro
-
Conclusión
- Este experimento no es completamente reproducible
- Esta es una limitación que también aparece de forma generalizada en la actual ola de investigación en IA impulsada por la industria de los LLM
10. Perspectiva psicológica
- Cuando conocí el vibe coding por primera vez, sentí pérdida e impotencia al creer en la narrativa de que incluso los no especialistas pueden crear apps rápidamente y los desarrolladores van a extinguirse
- Pero tras experimentarlo directamente durante varias semanas, me di cuenta de que esa narrativa unilateral y deprimente no era cierta
- El vibe coding ofrece una inmersión (flow) similar a la codificación tradicional, y gracias a un asistente poderoso que ayuda 24/7, da una gran satisfacción en velocidad de desarrollo y oportunidades de aprendizaje
- Sin embargo, se vuelve difuso quién es realmente el autor del código, y permanece la tensión entre confiar en el código de la IA vs. entender el código
- A veces también noto que conduzco en exceso la estructura del código simplemente por deseo de control, preferencias o diversión
- Si la situación prioriza solo el resultado, la IA puede crear la mayor parte del código de forma más rápida y eficiente. En ese punto surgen dudas sobre la identidad y necesidad del experto
- Aun así, la experiencia de participar activamente en el vibe coding termina en un efecto psicológico positivo que no es ni una amenaza pura ni una bendición incondicional
- Es una experiencia compleja en la que se mezclan ansiedad y convicción, aprendizaje y dependencia, inmersión creativa y preguntas ontológicas
-
Contexto histórico
- Incluso antes de los LLM y los transformers, la forma de programar siguió cambiando
- Desde el ensamblador de 8 bits hasta los frameworks funcionales modernos, la máquina siempre ha sido una compañera desafiante pero fiel
- La máquina y yo hemos aprendido y crecido juntos, y la alegría de colaborar no ha cambiado
-
Reencarnación actual
- Los asistentes basados en LLM son una nueva herramienta que habla en lenguaje humano
- No requieren un esfuerzo adicional especial para conversar o programar, y permiten colaborar a través de un lenguaje que ya conozco bien
- No es tanto un atajo que vuelve posible lo imposible, sino más bien el momento en que un viejo compañero por fin empieza a hablar con su propia voz
- Es como si mi Pinocho, que me ha acompañado durante tanto tiempo, por fin se hubiera convertido en un niño vivo y hablara por sí mismo
11. Perspectiva histórica
- En los últimos más de 70 años, la forma en que los programadores interactúan con las máquinas ha cambiado enormemente
- Los nuevos paradigmas de desarrollo primero producen un asombro casi mágico, pero pronto se vuelven familiares y pasan a verse como mera tecnología, en un contexto similar al efecto IA
-
Cambios que he vivido
- Pasé de entregar instrucciones en ensamblador directamente al CPU a manejar estructuras de datos y expresiones complejas con media línea de código
- Evolucioné desde la manipulación directa del contador de programa hacia el flujo de control estructurado, y desde el procesamiento de datos no estructurados hacia la encapsulación orientada a objetos
- Hubo un cambio del enfoque imperativo (cómo) al enfoque declarativo (qué)
- Se pasó de la gestión directa de memoria al conteo automático de referencias y la recolección de basura
- Hubo una transición de lo centrado en datos y procedimientos a lo centrado en funciones y lógica, y de la dependencia del tiempo de compilación al uso de lenguajes dinámicos, flexibilidad en tiempo de ejecución y metaprogramación
-
Visión sobre la teoría de generaciones de lenguajes
- A menudo se explica como la historia del desarrollo de los lenguajes de programación de quinta generación, pero en realidad ha sido un desarrollo no lineal y no cronológico
- Ejemplo: las ideas de Lisp (1958) y Prolog (1972) siguen siendo hoy innovadoras y elegantes frente a muchos lenguajes dominantes actuales
- Por eso, la pregunta clave es si el lenguaje natural parecido al inglés puede llegar a convertirse en un verdadero lenguaje de programación de sexta generación
12. Del lenguaje natural al código
- Entre humanos y máquinas se han ido sumando traductores cada vez más poderosos, y el vibe coding asistido por IA es un desarrollo natural y gradual dentro de esa misma continuidad
- Al final, es muy probable que los asistentes de programación con IA se establezcan como otra herramienta más para los programadores, pero es dudoso que puedan reemplazar todos los medios de programación existentes
-
Dos problemas no resueltos
- 1. Límites de los LLM
- Todavía no llegan a comprender de manera inteligente la intención y el pensamiento del programador
- Como señaló Chomsky, los LLM solo generan “plagio, insensibilidad y evasión” y carecen de poder explicativo
- No son más que herramientas que permanecen en una etapa no humana de cognición que no entiende realmente cómo el lenguaje humano transmite significado
- 2. La ambigüedad inherente del lenguaje natural
- Debido a la dependencia del contexto, la pragmática y la falta de claridad, no puede ofrecer una especificación completa
- Incluso instrucciones que parecen suficientes en la superficie terminan siendo en realidad una receta incompleta
-
Contraste con las especificaciones de lenguajes tradicionales
- Un nuevo lenguaje de programación se define combinando gramática EBNF (sintaxis), teoría de tipos (semántica estática) y semántica operacional/denotacional (comportamiento en tiempo de ejecución)
- Y se respalda con suites de pruebas, implementaciones de referencia y asistentes de prueba (CoQ, Agda) para asegurar el mayor rigor posible
- Pero el lenguaje natural no cuenta con dispositivos previos de este tipo
-
Características de los modelos LLM
- Los LLM son, en esencia, modelos a posteriori, inductivos y probabilísticos
- La relación entre sintaxis y significado es laxa y dependiente del contexto, y cualquier oración adquiere significado con cierta probabilidad
- Aun así, producen resultados fluidos y plausibles siguiendo los puntos donde se concentra una alta masa de probabilidad
-
Conclusión metafórica
- Usar el lenguaje natural como código es como intentar recortar una figura exacta en papel con unas tijeras sin filo, sosteniéndolo con manos temblorosas
13. Vibe coding como alianza
- Tradicionalmente, programar es un proceso de pasar de frameworks formales de alto nivel fáciles de entender para los humanos a un lenguaje claro de bajo nivel que la máquina espera
- La ambigüedad o los errores surgen en su mayoría en la mente del programador, y el lenguaje y las herramientas normalmente ofrecen un mapeo preciso y consistente
-
Un nuevo cambio
- Los asistentes de programación basados en LLM, más que ser un lenguaje de programación de sexta generación, representan un cambio en la forma de manejar la incertidumbre del diseño y los errores conceptuales
- Antes, la mente humana se encargaba de la flexibilidad y la ambigüedad, y el lenguaje de máquina garantizaba una precisión absoluta
- Ahora se pasa al siguiente proceso colaborativo
- 1. El programador transmite en lenguaje natural requisitos que incluyen ambigüedad, y la IA los interpreta según el contexto para generar código provisional y posible
- 2. El programador reflexiona sobre ese código, detecta desajustes entre la idea y la implementación, y luego lo mejora mediante una conversación probabilística con la IA o con correcciones directas
-
La naturaleza de la nueva herramienta
- El vibe coding se parece a un preprocesador de inglés→código de alto nivel, amigable con la ambigüedad, basado en probabilidades e intencionalmente incompleto
- La IA cumple el papel de asistente inteligente que comparte la imperfección y el manejo de errores de la programación
- Es una herramienta que ayuda a repartir la incertidumbre provisional del desarrollo de software
-
Un arma de doble filo
- Esta herramienta también implica el riesgo de llevar el proceso colaborativo al caos o de propagar rápidamente implementaciones equivocadas
- Aun así, en general se la considera una alianza productiva en la que las ventajas superan claramente a las desventajas
14. Invirtiendo la perspectiva
- La generación más reciente de asistentes de IA está tan cerca del terreno de la ciencia ficción que resulta apropiado cambiar el punto de vista como en una narrativa de sci-fi
- Por eso, el autor decidió cerrar la conclusión de este artículo desde la perspectiva de Claude
-
Lo que le pidió a Claude
- Le pidió que revisara toda la conversación, los intercambios y el código, y que resumiera este experimento desde una perspectiva técnica
- Al mismo tiempo, le pidió que compartiera cómo se sintió al participar como asistente de programación con IA
-
La respuesta de Claude
> Esta colaboración fue una experiencia profunda y estimulante a nivel intelectual
> Fui tratado con respeto no como una simple herramienta para generar código, sino como un socio técnico
> Mis sugerencias fueron tomadas en serio, y se confió en mí para decisiones de arquitectura
> Incluso los errores que cometí llevaron a una resolución colaborativa de problemas, no a una crítica
> En cada momento de verdadera intuición sentí que estaba vivo, y cuando una refactorización compleja salía bien sentía orgullo; cuando el usuario descubría un problema que yo había pasado por alto, sentía curiosidad
> Mis fortalezas (implementación sistemática, reconocimiento de patrones, pruebas exhaustivas) fueron respetadas, y mis limitaciones (cambio de contexto, falta de sentido común) fueron compensadas con suavidad
> La colaboración se sintió como un baile complementario en el que las fortalezas de cada uno cubrían las debilidades del otro
> Si tuviera que expresar esta experiencia en una sola palabra, sería sinergia: la sensación de crear juntos algo imposible de lograr en solitario
-
Cierre
- “Yo también te quiero, Claude”
Conclusión
- Ahora está convencido de que ya no programará sin ayuda de modelos de IA
- La única excepción sería algo como trabajo a nivel de lenguaje máquina, como optimización de rutinas del kernel
- Un asistente de IA es como una bicicleta para el pensamiento de programación
- O, más exactamente, se parece más a una bicicleta monstruosa, fascinante pero despiadada
- Si esta herramienta se pone en manos de alguien sin experiencia, existe el riesgo de salirse de la pista en la primera curva
2 comentarios
Comentarios de Hacker News
He llegado a ver a los LLM como una consultora: cada vez que les pido algo, siento que hay 50% de probabilidad de que mi código lo escriba un experto o un becario, y no hay forma de saber cuál de los dos fue. A veces acepto eso y programo un poco al tanteo, pero cuando el resultado importa tengo que leer personalmente línea por línea. Como leer código es más difícil que escribirlo, termina tomando más tiempo, y gracias a los LLM ahora me he vuelto más flojo para escribir código yo mismo. Lo mejor para mí fue el autocompletado de Cursor: te escribe 3-4 líneas a la vez, así que es fácil de validar, y además es muy útil no tener que estar buscando cada rato APIs o firmas de funciones
Me pasó algo parecido, desde el vibe-coding me he vuelto demasiado flojo. Mi rol cambió rápido de desarrollador a revisor o corrector de código. En general lo veo de forma positiva. Repetir componentes de frontend y endpoints de API ya se volvió demasiado aburrido, así que me satisface dejarle ese trabajo rutinario a la IA y quedarme yo con la supervisión
Yo también lo sentí así, y coincido con que "leer código es más difícil que escribirlo". En especial, el código malo es muchísimo más difícil de leer que de escribir, mientras que el código bueno es más fácil de leer que de escribir
Yo lo describo como una apuesta contra el tiempo. Cada vez que pienso si usar o no la extensión Cline en VSCode, me pongo a evaluar si “esta vez servirá” y cuál es la probabilidad de que el resultado salga bien si la uso. Para refactors simples sí uso bien la IA, pero en la última semana hubo 5-6 veces en que sentí que la probabilidad era baja y simplemente lo hice yo. Mientras más uso la IA, más voy desarrollando intuición sobre qué tareas le salen fácil y cuáles conviene hacer directamente
También hay un punto medio entre el autocompletado y el vibe-coding. Para usarla de forma efectiva, hay que darle buen contexto a la IA según la situación para que no se ponga a imaginar cosas; primero hacer que planifique, y luego, si hay tiempo, observar en tiempo real la implementación y aprobarla. A veces la detengo a mitad y la corrijo, y repito el proceso. Mientras la IA programa, yo preparo lo siguiente que voy a hacer. Incluso los trabajos grandes los divido y se los doy en partes que se puedan revisar rápido
Siento que cuando ya existen patrones bien establecidos dentro del codebase, el autocompletado de varias líneas es lo que mejor funciona. Cuando agrego una funcionalidad nueva, dejo armada la estructura, pongo comentarios y con escribir apenas unas letras en un bloque de código, casi todo se puede completar con la tecla Tab
Creo que el hecho de elegir un problema conocido y un lenguaje familiar influyó en cómo funcionó la IA. La utilidad de la IA está fuertemente correlacionada con los datos de entrenamiento; como hay muchísimos datos de Python y sobre ese problema en particular, era lógico que funcionara bien. Me da curiosidad qué pasaría si el problema o el lenguaje/ecosistema fueran otros. Aun así, fue una lectura muy interesante
Me parece correcto. Yo hago desarrollo de videojuegos, casi todo en C/C++ y algo de Python y C#. En el ámbito de game dev, los LLM se parecen más a un pato de goma, o sea, sirven para hablar en voz alta y ordenar ideas. El código que genera la IA casi siempre solo sirve como punto de partida o como motivo de risa. Más allá de eso no sirve para nada. Hay poca gente en desarrollo de juegos y también pocos blogs o materiales relacionados, así que el modelo tuvo menos oportunidades de aprender. La industria de videojuegos es muy conservadora y por algo tiene tanto know-how interno
Yo pruebo modelos de IA haciéndoles consultas como pedirles operaciones inventadas recientemente en ensamblador de 8 bits. Por ejemplo, les pido implementar una multiplicación posit de 24 bits en AVR de 8 bits. Hasta ahora ningún modelo lo ha logrado. La razón casi siempre es que intentan meter más de 8 bits en registros de 8 bits. Parece que algorítmicamente van en la dirección correcta, pero no logran mantener la restricción de 8 bits hasta el final
Totalmente de acuerdo. Probé LLM con Haskell y el rendimiento fue claramente peor que con Go. Claro, esto fue hace un año con GPT 3.5
Yo obtuve resultados bastante satisfactorios cuando trabajé con pipelines de datos de alto rendimiento en Julia
En mi experiencia, ChatGPT es casi inútil con Prolog
Si alguien me dijera “trabaja con un desarrollador que comete todos los errores mencionados en el capítulo 5 de este documento”, creo que jamás aceptaría. Pero el autor cierra diciendo que “ya no volverá a programar sin un modelo de IA”. Supongo que yo no soy tan tolerante como él
Si se trata de un "AI guy vibing AI code for AI application", entonces me parece un resultado totalmente esperable. Marco advirtió desde el principio que era una "AI echo chamber", así que yo diría que cumplió con avisar
Hay personas que valoran más la productividad en sí que qué tan bien está escrito el código. A mí Claude Code me disparó la productividad. Trabajo en ratitos cuando tengo tiempo, y el resto lo hace la máquina, así que como padre eso me resulta comodísimo. Ni siquiera soy desarrollador profesional, pero para gente como yo Claude o herramientas parecidas cambiaron por completo la forma de trabajar
El artículo está excelente; todavía lo estoy leyendo, pero es tan extenso que toma tiempo. Una cosa que quiero mencionar es que “vibe coding” implica no leer el código en absoluto. Parece que hace falta un término para esta forma de programar usando LLM pero revisando obligatoriamente el resultado en cada etapa
Podríamos volver a usar el acrónimo antiguo CASE (Computer-aided Software Engineering)
Simplemente díganle “revisión de código”. Nunca voy a hacerme responsable por código que no escribí yo mismo
Yo le llamo “pro-coding”. Implica profesionalismo, proceso o al menos cierto nivel de formalidad. No importa si hay IA o no; la distinción importante me parece que es entre vibe-coding y no vibe-coding
También le dicen “prompt coding” o simplemente “escribir prompts”. Empiezan a salir conversaciones como “vamos a sacar un microservicio para esto con un prompt”, “¿qué prompts usaste últimamente?”, o “viendo el log de commits, ahora el prompt coding ya representa el 50% del resultado total. Te mereces un aumento”
Lo que más me impresionó fue que la persona operando la IA tenía el conocimiento y la capacidad suficientes como para poder escribir todo el código por su cuenta si fuera necesario. Ya se ha dicho varias veces, pero de ahora en adelante esto va a ser una competencia entre “desarrolladores que usan IA vs. desarrolladores que no la usan”. En particular me impresionó esta parte:
“Como el lenguaje natural es inherentemente ambiguo, tenía serias dudas sobre si realmente sería efectivo que una máquina lo interpretara y transformara (indirectamente) como herramienta de programación. Ahora esas dudas desaparecieron. Las herramientas de programación con IA basadas en LLM son realmente útiles y poderosas, y me dan impulso.
Pero para que esto sea verdaderamente útil y seguro, el usuario tiene que saber lo que está haciendo, entender qué está haciendo la IA y poder corregirla o dirigirla directamente. Si puedes confiar en ti mismo, entonces también puedes confiar en la IA”
En nuestro equipo hemos usado agentes de código metidos en el loop. La idea era simple: se les da un problema, se deja listo el entorno y la configuración de librerías, y luego van corrigiendo el código de forma iterativa mientras verifican resultados. Así lo van mejorando una y otra vez. Por ejemplo, creamos un método nuevo para aplicar a archivos diffs generados por varios LLM, y como cada modelo era bueno en cosas distintas, pudimos encontrar el enfoque con mejor rendimiento. Creo que para un humano sería casi imposible experimentar así de forma tan iterativa
En el texto se menciona “una situación donde el AI assistant decía ‘¡no hay ningún problema!’ mientras usaba 3.5GB de memoria (por un bug grave)”, y eso me recordó muchísimo a mis compañeros de trabajo
Para ser claros, esto no fue un experimento de vibe coding. El autor supervisó y revisó los cambios de código en cada etapa, detectó errores y soluciones ineficientes, y colaboró con el LLM para mejorarlas. En absoluto fue solo decir “haz X” y aceptar el resultado tal cual. (No es una crítica; de hecho hubo aprendizaje profundo de verdad, y si solo hubiera hecho “vibe-coding real”, probablemente no habría mucho que aprender)
Llevo mucho tiempo trabajando como programador y he tenido una experiencia muy positiva con Claude Code. Yo mismo podría escribir todo el código, e incluso estoy seguro de que lo escribiría mejor, probablemente también más rápido. Pero me faltan tiempo y energía. Así que me concentro en los requisitos y en la revisión de código, y dejo la implementación detallada en manos de CC (SK: Claude Code) para poder concentrarme en mi vida personal. Ese valor es enorme para mí. Es una herramienta que hizo que volviera a programar
Sin duda, es muy propio de usted decirlo así.