- Al usar herramientas de programación con IA y confiarles tareas cada vez más grandes, sintió asombro, pero confirmó que a los resultados les faltaban consistencia y solidez estructural
- Incluso escribiendo especificaciones detalladas, los agentes de IA no logran mantener el contexto a largo plazo ni evolucionar el diseño, y al final toda la base de código se convierte en un conjunto de fragmentos heterogéneos
- Los fragmentos de código pueden parecer completos por separado, pero en conjunto aparece un desorden estructural (sloppy) y un colapso del contexto
- Tras esta experiencia, el autor concluyó que el código generado por IA no puede garantizar la confianza del usuario ni la protección de los datos, y volvió a escribir el código directamente
- La programación con IA sigue siendo útil, pero puede provocar deuda técnica y pérdida de control por parte del desarrollador, por lo que requiere un uso cuidadoso
La emoción inicial por la programación con IA y el reconocimiento de sus límites
- La mayoría de los usuarios empieza a programar con IA en tareas simples y poco a poco le delega retos más complejos, maravillándose con su desempeño
- Sin embargo, después de cierto punto empiezan a aparecer errores e inconsistencias de la IA, y surge una brecha entre la expectativa y la realidad
- Cuando el resultado no es satisfactorio, los usuarios suelen atribuirlo a problemas en sus prompts e intentan redactar especificaciones más concretas
- Usan herramientas como Obsidian para crear documentos de especificación detallados, pero la IA no logra desarrollarlos a largo plazo
El fracaso del enfoque basado en especificaciones
- En el desarrollo real, los documentos de diseño son documentos vivos que cambian constantemente durante el proceso de descubrimiento e implementación
- Sin embargo, los agentes de IA quedan fijados a la especificación inicial y no pueden modificarla ni reinterpretarla con flexibilidad
- Mientras lidian con estructuras complejas, los agentes tienden a perder el contexto general del problema o avanzar de forma forzada
- Como resultado, aunque el código parezca completo por fuera, le faltan consistencia interna e integridad estructural
El deterioro de la calidad del código y los límites del ‘vibecoding’
- El código escrito por IA puede verse excelente en partes, pero en conjunto termina siendo una combinación sin sentido
- Tras revisar toda la base de código, el autor descubrió que dentro había “puro desorden (slop)”
- La IA es fiel al prompt y a su propia consistencia, pero no considera la armonía del sistema completo ni la consistencia de los patrones adyacentes
- Es un fenómeno parecido al ‘vibewriting’, donde algunos párrafos de una novela son excelentes, pero el capítulo entero es un desastre
El regreso al desarrollo centrado en las personas
- El autor concluyó que no podía desplegar como producto el código generado por IA ni usarlo para proteger los datos de los usuarios
- Con la decisión de “no mentirle al usuario con este código”, volvió a programar directamente
- Al escribir por su cuenta, sintió que mejoraron incluso la velocidad, la precisión, la creatividad y la productividad
- Al evaluar no solo la velocidad de generación de código sino la eficiencia total del desarrollo, comprobó la ventaja humana
Uso continuo de la programación con IA y precauciones
- El autor todavía usa LLM de forma limitada en algunas tareas (aprox. 40%)
- Son útiles para tareas repetitivas o generación de código simple, pero se acumulan la deuda técnica y la pérdida de comprensión del código
- A largo plazo, existe el riesgo de que el desarrollador pierda el modelo mental de la base de código y ya no pueda resolver problemas sin la IA
- En movimiento (tren, avión, etc.), también se dan situaciones en las que la dependencia de la IA hace que la productividad caiga a 0%
- Otros desarrolladores señalan que la idea de que “basta con escribir bien la especificación” es una reproducción del modelo waterfall, y que el desarrollo real exige exploración improvisada e interacción
Conclusión
- La programación con IA sigue siendo una herramienta poderosa, pero carece de la capacidad de mantener el contexto del sistema completo y la consistencia estructural
- La capacidad humana de juicio intuitivo y ajuste improvisado sigue siendo esencial, y
la IA debe usarse como apoyo, de forma cuidadosamente controlada
9 comentarios
Ni siquiera ha pasado un año completo desde que se creó el concepto de vibe coding, pero qué pose de SNS más ridícula, jajaja
Sí, vale la pena dedicarle esfuerzo a pulir las especificaciones... Si haces las especificaciones de verdad, siguiendo el método formal que aprendiste en ingeniería de software, y luego las vas refinando, actualizando y trabajando con gestión de trazabilidad, queda muy bien.
Mientras avanzaba en proyectos, siempre iba subiendo versiones tanto de las plantillas de especificaciones como de los prompts, pero últimamente me he estado preguntando si ya toca estudiar ingeniería de software de manera más profunda.
El autor sigue aprovechando los LLM de forma limitada en algunas tareas (aprox. 40%)
Por cómo está escrito arriba, no parece que el autor opine que haya que abandonar por completo la IA.
Parece que es momento de seguir pensando en cómo aprovecharlo bien. Creo que desarrollar dejando de lado la IA es ir quedándose atrás poco a poco.
El autor de este artículo ya estaba usando una buena forma de aprovecharla, pero aun así creo que habría que pensar en cómo usar mejor la IA.
(Todavía hay mucho ensayo y error...)
Actualiza las especificaciones.
Así es. Puedes engancharlo para que, cuando termine la implementación, también actualice la especificación; y si no, también podrías agregar un comando o una skill para actualizar la especificación manualmente jaja
Ah, no quiero envejecer.
Opiniones en Hacker News
Creo que el hecho de que la IA haga demasiado bien las cosas básicas es precisamente lo peligroso
Los estudiantes dejan de escribir código por sí mismos porque “la IA lo hace por ellos”, y como resultado no llegan a aprender con el cuerpo las etapas intermedias ni los conceptos difíciles
Como profesor de CS, les recalco a mis estudiantes que “no debe escribir el código la máquina, debes escribirlo tú”
Levantar peso con un montacargas es fácil, pero así no desarrollas músculo
El dolor del proceso de aprendizaje es justamente la clave del crecimiento
Claro, en el trabajo importa más el resultado, pero aun así se necesita gente capaz de pensar en niveles altos
El candidato tenía conocimientos teóricos perfectos, pero no pudo explicar en absoluto cómo funcionaba el código que había escrito
Al final confesó que “GenAI escribió la mayor parte”, y la brecha entre “lo aprendido” y “lo que realmente hizo con sus manos” era demasiado grande
Es más importante enseñar “cómo funciona el código” que “cómo se escribe”
Antes hubo una época en la que se programaba directamente en ensamblador, pero ahora vale más entender los principios del compilador
En la práctica, casi nadie va a construir un compilador o un OS por su cuenta, pero conocer esos principios ayuda a entender los límites de los lenguajes de programación
Cuando aparecieron los compiladores surgió la misma discusión, y al final simplemente subimos a un nivel más alto de abstracción
Solo implementar cosas no profundiza el pensamiento
Si dejas la implementación a la IA, al final es como “personas con los ojos vendados tratando de encontrar el camino”
El proceso de pensar mientras manipulas directamente el código es indispensable
No comparto la idea de que “la IA hace bien las cosas simples, pero hace todavía mejor las grandes”
En la práctica, siempre he obtenido resultados decepcionantes
El código no funciona bien o hace falta darle instrucciones correctivas una y otra vez
Si el ciclo de retroalimentación es difícil, al final tú mismo te conviertes en la única fuente de feedback, y ahí es cuando se siente con claridad el límite de la IA
Por ejemplo, si explico con claridad la estructura de un TaskManager o las reglas de ownership de memoria, genera código que incluso pasa las pruebas
Hay gente como Ryan Dahl que dice “ya no escribo código directamente”, pero eso se debe a que lo va puliendo como una colaboración mediante feedback repetido
A la IA hay que tratarla como si estuvieras enseñándole a un niño
Describiendo con claridad entrada, salida y errores esperados, y corrigiéndolos mediante experimentación iterativa
Claude hace preguntas, investiga e incluso revisa el código
Se siente como estar mentoreando a un junior muy capaz
Al principio probé el “vibe coding” con una mente abierta, pero poco a poco me volví más escéptico
Sirve para código repetitivo y claro, pero no es adecuado para la lógica central del negocio
Claude a menudo ignora las especificaciones, repite la misma lógica varias veces o dice que corrigió algo y en realidad lo deja igual
Incluso da la impresión de que el modelo se ha vuelto más torpe
Ahora solo lo uso para discutir diseño o para depuración
Si hay muchas “partes aburridas” para que la IA las rellene, puede que desde el inicio la estructura del código esté mal planteada
En esa parte los LLM todavía ayudan
Muchos desarrolladores de todos modos reciben un diseño ya definido y solo implementan, así que la IA puede acelerarles el trabajo
No estoy de acuerdo con la afirmación de que “la IA no puede reflejar cambios de diseño”
Más bien, ese es precisamente el rol del humano
Por ejemplo, si le pides cambiar la estructura de un API, la IA puede encontrar todas las partes relacionadas, modificarlas e incluso ejecutar pruebas
Se obsesiona con detalles de implementación o deja fuera validaciones conceptuales
Aun así, lo entiendo, porque las pruebas escritas por humanos también suelen caer en algo parecido
Si no escribes el código tú mismo, no llegas a percibir lo ásperas y desbalanceadas que son ciertas abstracciones, y eso termina derivando en una caída de la calidad estructural
Esa diferencia es lo que define el nivel de acabado del código
Pero lo importante es tener la capacidad de juzgar qué tareas realmente requieren intervención manual
Eso sí, solo rinde de verdad si pagas una suscripción avanzada, por ejemplo Claude Max de 200 dólares
Me genera dudas la frase “llevo 2 años haciendo vibe coding”
Karpathy acuñó ese término hace apenas un año (fuente)
Le parecía interesante que GPT diseñara por sí solo el API que luego iba a usar, e implementara en función de eso
Pero comenta que después los modelos empezaron a bloquear las conversaciones relacionadas con automodificación y replicación
No hace falta que sea una herramienta totalmente agentica; con ChatGPT o Claude ya se puede
y que ahora obtiene buenos resultados colaborando con la IA desde la etapa de investigación
Yo les digo a mis estudiantes que “ver deportes por TV no te pone en forma”
Con el vibe coding pasa lo mismo: existe una sensación de logro que solo obtienes escribiendo código con tus propias manos
el “código medio terminado” que genera la IA me devuelve las ganas de seguir
Dudo que los ingenieros de verdad practiquen “vibe coding” de forma ciega
Yo más bien uso un enfoque de ir puliendo el código como si lo esculpiera mediante conversación
Presento los requisitos, reviso con la IA las propuestas de diseño y completo la estructura de forma gradual
Este proceso es lento, pero permite mantener la colaboración y la profundidad del pensamiento
La IA propone ideas nuevas a partir de haber aprendido de enormes cantidades de código, y yo las calibro con mi experiencia
Al final, la IA se siente como una versión ampliada de mí mismo (me++)
Todavía no estoy listo para delegarlo todo en un agente completo, pero este método es el más productivo
Siento que el código escrito por IA es como una novela excelente por partes pero desastrosa en conjunto
Si la ves capítulo por capítulo parece perfecta, pero en el contexto completo resulta confusa
Si no, esperar que una codebase de 10 mil líneas hecha con vibe coding funcione bien es demasiado pedir
Si no refleja el pensamiento y las emociones humanas, la experiencia de usuario también pierde coherencia y aparece fricción cognitiva
y que cuando el diseño está claro el LLM acelera explosivamente el trabajo de boilerplate
Pero el diseño sigue siendo tarea humana
Su proyecto puede verse en la versión pública en GitHub
Reconozco que el código generado por LLM puede ser excelente en partes, pero débil en su estructura general
Aun así, si entiendes la codebase y la revisas tú mismo, se puede compensar bastante bien
El vibe coding es excelente para crear prototipos
Funciona bien para captar rápido la idea y luego expandirla mediante refactorización
Es decir, según esa postura, el verdadero vibe coding consiste en juzgar solo el resultado final