- Recientemente, una declaración de Andrej Karpathy se volvió tema de conversación: "Déjate llevar por la vibra, acepta el crecimiento exponencial y olvida incluso que el código existe."
- "Vibe Coding" se refiere a la tendencia de delegar la resolución de problemas a herramientas de IA sin una planificación clara ni escritura directa de código
- A través de agentes LLM (modelos de lenguaje de gran tamaño), ahora es posible dar instrucciones en lenguaje natural para generar y modificar código
- 2022: en ChatGPT se podía copiar y modificar código
- 2023: en Copilot integrado con el IDE se podía revisar y modificar código
- 2024~2025: se pueden modificar varios archivos de un proyecto y hacer pruebas y correcciones por cuenta propia
Cómo funciona "Vibe Coding"
- Tanto usuarios técnicos como no técnicos pueden configurar proyectos mediante agentes basados en LLM
- Es posible crear sitios web o apps con instrucciones simples (por ejemplo: "crear un sitio web para un resort de esquí")
- Después de la configuración inicial, puede hacer correcciones y pruebas automáticas
-
Ejemplos:
- Cursor, GitHub Copilot Agent Mode y otros pueden modificar archivos y ejecutar comandos
- Realizan correcciones y pruebas automáticas → pueden producirse errores por falta de consistencia
El problema de la autonomía de los agentes
- Los agentes pueden realizar tareas automáticamente, pero no tienen autonomía completa
- Si se ejecutan sin aprobación del usuario, pueden surgir riesgos (por ejemplo, ejecutar comandos en modo YOLO)
- Pueden aparecer problemas de calidad y precisión del código
-
Problemas principales:
- Falla al reutilizar código existente → crea repetidamente el mismo componente
- Intenta ejecutar lógica del lado del servidor en el cliente
- Corrige mal el código y luego genera errores → falla al intentar corregirlos
- Falla al escribir pruebas unitarias o incluso rompe el código
Limitaciones reales
- Modelos como Claude 3.7 Sonnet no pueden superar los límites de sus datos de entrenamiento
- Si pierden el contexto dentro de una base de código, no pueden hacer cambios consistentes
- Cuando el código crece, el rendimiento baja y ya no se puede mantener el contexto
- Si se supera el tamaño de la ventana de contexto del LLM, aparecen problemas de consistencia
-
Casos concretos de problemas:
- Duplicación de interfaces TypeScript
- Ejecutar lógica de servidor en el cliente
- Falla al corregir componentes duplicados
- Falla al escribir pruebas unitarias
- Falla al corregir errores después de refactorizar el código
Intentos de resolver el problema
- Claude Plays Pokémon: el agente juega interactuando en tiempo real
- Falla al mantener memoria y al corregir errores repetitivos
- No logra construir memoria de largo plazo → se producen errores de forma continua
-
Posibilidades de mejora:
- Hace falta mejorar MCP(Model Context Protocol) y la gestión de memoria
- Al modificar código, el LLM debe reflejar con precisión los cambios anteriores
- Es necesario conservar memoria por dominio e historial de tareas
Conclusión
- "Vibe Coding" puede llegar hasta un 80% en la implementación de conceptos funcionales, pero para crear productos confiables y seguros sigue siendo necesario el esfuerzo de personas con experiencia
- Los agentes de IA permiten que personas capacitadas creen más cosas por su cuenta, pero no pueden reemplazar a quienes resuelven problemas difíciles que requieren experiencia e intuición.
- En el nivel actual, es difícil que "Vibe Coding" conduzca realmente a productos útiles, y la ayuda de desarrolladores con experiencia es indispensable
- "Vibe Coding" es solo un medio de apoyo para escribir código, no un reemplazo total
9 comentarios
Me llama la atención la parte de "nivel actual". ¿No estaremos viendo a los LLM con una concepción humana del tiempo?
Lo que siento al programar con IA es que, si terminas dividiendo en unidades con una sensación de principio de responsabilidad única + TDD para que la IA pueda entender el contexto incluso si solo le das una parte del código, entonces hay que hacer que lo capte lo suficiente solo con el contexto de esa parte, sin necesidad de leer el contexto completo.
Lo que más uso la IA para mis hobbies es para crear juegos web, y coincido. Cuando el proyecto supera cierta escala, llega un punto en el que la IA baja notablemente en algo que podría llamar nivel de concentración. Yo la uso de la siguiente manera: junto todo el árbol del juego y el código fuente en un solo archivo, incluyendo el TOC, luego creo un hilo nuevo, subo ese archivo y continúo el trabajo. Y cuando hago preguntas, siempre le pido explícitamente que responda indicando claramente el nombre del proyecto actual. Aun así, todavía hay partes que no me dejan satisfecho... pero me resulta muy satisfactorio poder completar en relativamente poco tiempo hobbies que antes, por estar ocupado con la vida diaria, ni siquiera me animaba a empezar.
El patrón de construir algo rápido y luego pulir el resto de los detalles me gusta mucho.
Estoy probando varias cosas, pero los límites de la memoria son claros. Está bien a nivel de PoC. Es bueno para evaluar rápidamente la viabilidad y la usabilidad.
El problema es que se necesita aún más a gente con experiencia.
Si consideramos que la mayor parte del tiempo en programación se va en depurar y leer código, me parece que esto está bastante exagerado. Quienes hacen IA hablan todos con ese tono, pero al menos viendo la situación actual, no parece ser así. Si se llega a un punto en el que ya no se necesiten manos humanas, ¿realmente haría falta programar? Mejor sería simplemente poner la documentación de la API y usar el LLM como backend.
En la práctica, se suele usar mucho así, configurando el esquema y recibiéndolo de esa manera.
Estoy de acuerdo. Al principio muestra una velocidad de desarrollo casi mística, pero a medida que crece la escala y aumenta la cantidad de archivos, si el responsable de administrarlo (en este caso, una persona) no puede gestionarlo de forma efectiva, lo único que termina recibiendo es un resultado cada vez más grande y lleno de errores. Si ya llega a un punto en el que no hay forma de arreglarlo, solo se terminan desperdiciando créditos (Windsurf) o solicitudes (Cursor). Seguirá mejorando poco a poco, pero por ahora no hay que confiar al 100% en el código generado por IA.
Opiniones en Hacker News
La gran diferencia entre "la exageración de la IA vs. la realidad" está en las cifras de productividad que la gente suele mencionar. Por ejemplo, socios de YC citaron a una empresa que afirmaba una "mejora de velocidad de 100x" en desempeño de programación. Una afirmación así sería claramente visible para observadores externos, por lo que no haría falta que fuera autorreportada.
En este momento estamos siguiendo la fiebre de la subcontratación. Con todas las afirmaciones exageradas, la realidad es distinta. Es difícil distinguirlo de la discusión sobre agentes de programación con LLM.
Es como cuando la comunidad de Go decía que las computadoras no podían vencer a jugadores humanos de Go. Ya existen ejemplos de modelos que encuentran algoritmos de ordenamiento de mejor rendimiento. Si se les da el incentivo y el tiempo adecuados, las computadoras nos superarán.
Se comparte un nuevo problema con los LLM para programación. Los desarrolladores offshore están completamente integrados en el equipo. Pero el uso de LLM es indiscriminado y disperso, así que los pull requests enviados se vuelven una pesadilla.
El "Vibe Coding" puede implementar el 80% de un concepto. Pero para crear algo confiable, seguro y valioso, se necesita un humano con experiencia.
Hace poco intenté usar Claude y OpenAI o3-mini para convertir código de Matlab a Python, pero el rendimiento fue muy malo. Había errores en casi todas las líneas importantes. Era una tarea que necesitaba automatización, pero falló.
Hacer "Vibe-TDDing" es mejor que no tener pruebas en absoluto. Si se entiende de programación y de testing, se puede usar un LLM para reducir los efectos externos negativos.
Después de compartir cómo construir un SaaS, empezó a pasar algo raro. El uso de las API keys llegó al máximo, se eludían las suscripciones y se generaban cosas aleatorias en la base de datos. Esto podría ser una broma.
Al ver que muchos ingenieros subestiman la capacidad y la productividad de las herramientas de programación con IA, uno siente seguridad sobre su trabajo. No voy a soltar Cursor.