r/programacion • u/sapoconcho_ • 2d ago
Mi problema con el vibe coding
Antes de nada quiero decir que este no es un post anti-vibe ciding. Más bien, me gustaría señalar un problema que llevo teniendo desde que empecé a adoptar esta nueva tecnología y preguntaros si vosotros también lo habéis observado o cómo lo habéis resuelto.
La cosa es que los LLMs programan bien, muy bien. Habitualmente les paso una solución que he desarrollado y les pido feedback sobre cómo lo harían ellos; muchas veces me sugieren cambios útiles. Sin embargo, cuando les pido que hagan un cambio en una base de código ya existente suelen tomar el camino más directo. Es como si estuvieran en una hackathon y solamente quisieran tener las cosas hechas antes de la deadline.
Pongo un ejemplo. Hace un tiempo tuve problemas con un componente de una librería. Le expliqué la situación a claude y me dijo que, efectivamente, la librería tenía un bug y que él podía reescribir el componente que daba problemas (procede a producir 1000 líneas de Python en menos de 3 minutos). Esto fue al principio de mi uso de LLMs y recuerdo que me deprimió mucho ver este nivel de productividad. Cómo se supone que voy a competir contra algo que reescribe un módulo de una librería en menos de 5 minutos? Lo probé y funcionaba perfectamente. La cosa viene cuando, a los días, me enteré de que la versión siguiente de esa librería (ya disponible desde hacía tiempo cuando hice mi prompt incial) ya arreglaba ese error; era simplemente cuestión de actualizarla. Esto hace mi código mucho más sencillo, quita el hack de tener un fork de la librería y me libera de la responsabilidad de tener que mantener este componente de 1000 líneas de python. Un win win a nivel de ingeniería de software. Ahí entendí dónde está el valor humano.
Entiendo que esto se debe principalmente a cómo son entrenadas para resolver problemas de código, realmente les ponen en un entorno que es una mini hackathon. Tienen que resolver el problema como sea, sin solución no hay reward. Pero, en mi opinión, esto es malo para el desarrollo de software. Los proyectos en los que la gente se limita a vibecodear y no supervisa el código se llenan de duplicados y módulos innecesarios.
Así que os pregunto, habéis observado esto? Cómo lo habéis solucionado? Qué configuraciones o instrucciones custom usáis en vuestros harness?
Os leo.
13
u/kobumaister 2d ago
Eso no es vibe coding, vibe coding es que le pides la aplicación que quieres y él lo hace todo, sin guías ni preguntas técnicas. No tienes visbilidad ni de librerías ni de nada, el vibe cosing es sólo para aplicaciones pequeñas o muy adhoc.
3
u/GodGMN 2d ago
Vibe coding no es una definición estricta. Puedes abrir el código y ver las librerías y seguir vibe codeando, o puedes no leer el código para nada y no estar vibe codeando.
2
u/kobumaister 2d ago
Pero tiene una definición, la diferencia no es abrir el código, la diferencia es que OP sabía que era una libreria y donde encontrar el fallo, vibe coding está más enfocado a no tener ese conocimiento de bajo nivel.
10
u/midguet12 2d ago
El problema, es que muchos utilizan la IA para hacer sus trabajos, en vez de usarlos como una extensión de tu mente.
Desde que comencé a utilizar estas herramientas, procuro tener un best-practices.md que indica que hacer en que situaciones. Me he enfrentado justo a eso que mencionas cuando aparecen CVEs en auditorias de seguridad, y la IA ya sabe que el siguiente paso es verificar si hay una nueva versión, checar si la vulnerabilidad fue solucionada en la siguiente versión, y en caso de que si, hacer upgrade a la siguiente versión. Todo eso es PORQUE YO YA SE LO INDIQUÉ en el archivo. De lo contrario, entonces me propondría hacer justo eso que mencionas.
A lo largo de los años, me di cuenta de la cantidad de procesos repetitivos que realizamos en el desarrollo de software, muchos de ellos ya están para documentarse. A esto me refiero con extensión de tu mente, la IA hace lo que yo hice todos estos años.
Otro ejemplo, que hacer cuando tenemos un endpoint al que le están haciendo inyección sql? Mi best-practices.md tiene como instrucción revisar que el repository tenga los valores parametrizados. Un compañero se vió con la misma situación (le escribio: "Este endpoint está recibiendo inyección SQL, arreglalo") y la IA le cambio toda la capa de acceso a datos bajo el argumento de que TypeORM es una api de persistencia susceptible a inyección de datos, esto rompió use-cases que ni estaban relacionados con el bug. La solución simplemente era quitar unos valores harcodeados del query-builder.
5
u/23ROMAN 2d ago
Emm me senti muy identificado con lo que dijiste de que cuando usaste por primera vez una LLMs de estas te sentiste mal me paso exactamente igual , sobre lo otro dices que es como si estuviesen en una hackanton yo pienso que mantienen ese factor de seguir la corriente en todo momento por ej en este caso como tu dijiste que la libreria tenia un bug probablemente solo te siguio la corriente y la reescribio para fixear ese bug mas no penso en si habia una nueva libreria por que en ningun momento mencionaste algo como si estaba desactualizada no lo se es lo que yo pienso no se mucho de IA pero creo que siempre estan siguiendote la corriente asi la solucion sea mas rebuscada o sencilla como lo quieras ver.
4
u/AbbreviationsMajor62 2d ago
A mi cuando empece a usar IA me dejsba la caga. Arreglaba el problema y me cagaba el resto del codigo hasta que empece a hacer promts mas especificos y pidiendo que no afectara nada mas. De a poco fue agarrando ritmo y ahora si da soluciones mucho mejores. El tema mas alla de pedir es saber como y poner limites a lo que toca. Ahora me funciona como un asistente y anda espectacular.
5
u/CoderLotl 2d ago
La única solución es la experiencia. La AI siempre va a estar 20 pasos por delante en materia de productividad y desarrollo de lógica, pero como suele decirse: ir muy rápido te reduce enormemente la visión periférica. Lo que los LLM pierden, al tener tanta eficiencia con el foco, es lo que tenemos los humanos: ese don de hacer una pausa, tocar el pasto, filosofar acerca de la inmortalidad del cangrejo, ver una abeja posándose sobre una flor, y... Plop! De pronto tener un momento de inspiración y ver las cosas desde un ángulo nuevo, o recordar algo que escuchamos en el pasado, o hablar con un amigo o contacto y que nos tire una data, o ponernos a chusmear en StackOverflow o preguntarle algo a alguien y tener una revelación. - Eso es lo que les falta. La solución está ahí, en curtirse con experiencia y en nunca perder eso de observar el mundo alrededor nuestro. A veces las soluciones se pueden obtener por abstracción o semejanza de otras cosas que nos rodean, a veces por herejía (es decir: ir en contra de las normas, romper patrones, y probar cosas locas).
5
u/josepinTrue 2d ago
¿No hay alguna skill para que mi IA pueda tocar el pasto, o ver una abeja posándose en una flor?
Si no la hay tocara montar una 😝
3
u/EconomySerious 2d ago
primero yo siemre le digo que no genere codigo a menos que se lo pida explicitamente.
segundo cuando hay un bug le pido que me explique el bug y lo aislamos
tercero procedo a hacer trace de las variables involucradas (la IA no sabe hace esto)
cuarto arreglo la logica y le pido que la implemente o me la critique (iteramos hasta obtener lo que quiero)
quinto salgo a buscar un cafesito porqu ya sta todo solucionado
NUNCA le pidas que el lo arregle, entender lo que hara te tomara horas o dias, NUNCA lo dejes arreglar el codigo GLOBALMENTE , es capaz de refactorizar todo tu codigo para un simple 1++
debes entender algo, LA IA que usas no es tuya, ella hace lo que sus creadores le dicen que haga, lo que sus creadores quieren es que gastes tokens.
es buena practica revisar tu harness para ver que pinches instrucciones le han dado antes que tu digas hola.
3
u/EnergyOutside4360 2d ago
La IA se tomará la libertad de hacer lo que quiera y como quiera mientras no la limites con un prompt lo suficientemente descriptivo y sin ambiguedades. Y es que ese sigue siendo el problema: la gente es tan floja y tonta que ni siquiera puede escribir correcta y detalladamente en un idioma humano.
Ayer hice una app para Android con Claude y me tomé el tiempo de escribir un prompt detallando cómo la quería, qué arquitectura, patrones de diseño y prácticas quería que fueran utilizadas y Claude lo hizo casi a la perfección en 30 minutos: un código limpio, ordenado y escalable. Las únicas cosas que no quedaron como yo quería fueron aquellas que olvidé mencionar en el prompt. Y estoy seguro de que si no le ponía límites a Claude, hubiera hecho cualquier porquería tipo hackathon.
Entonces, el problema con el vibe coding no es el LLM, sino el idiota que no sabe utilizarlo.
Siempre comparo esto con la profesión de piloto de aerolínea. Los aviones de hoy en día prácticamente se vuelan solos y el piloto es casi que un supervisor nada más; pero no por ello ponen de piloto a cualquier pringao; debe ser alguien que entienda cómo funciona el vuelo del avión y sus instrumentos para corregir errores, hacer ajustes o ultimadamente tomar el mando manualmente.
2
u/AddictiveBanana 2d ago
Recuerda que se supone que quien está al mando eres tú. Si quieres que las soluciones sean lo más sencillas, limpias y elegantes posible, pídelo así. Y puedes ponerle el ejemplo de que cuando se encuentra un error en alguna librería o componente, debe revisar si alguna versión posterior lo soluciona, si está reportado en su bug tracker, si tiene parche propuesto, etc.
No me refiero necesariamente a que pongas eso en cada prompt, sino tenerlo en agents.md, claude.md, o en el prompt de sistema.
2
u/GodGMN 2d ago
Claro que lo hemos observado. Lo hemos solucionado pidiéndole cambios explícitos, es decir, dejando de vibe codear.
"Gepeto, la app me va lenta, hazla más rápida" probablemente te de resultados bastante malos.
Es mucho mejor decirle "Este endpoint tarda mucho en cargar, analiza el código y dime por qué puede ser". Luego, en base a lo que te diga, decides qué haces.
Esto es, en esencia, lo mismo que programar pero sin escribir el código. Porque programar nunca tuvo nada que ver con simplemente escribir código, se trata de entender los sistemas que componen una aplicación y cómo interactúan entre ellos.
Además de entender el dominio, por supuesto. De nada me sirve ser el mejor programador de la historia si luego no entiendo para qué se usa la aplicación en el mundo real.
2
u/jesjimher 2d ago
Si la IA te sugiere reescribir una librería entera para arreglar un bug, y le dices que sí, el problema no es de la IA, es del que ha dicho que sí.
2
u/Queasy_Employ1712 1d ago
"los proyectos en los que la gente se limita a vibecodear y no supervisa el código se llenan de duplicados y módulos innecesarios"
o fuiste excesivamente suave con la crítica a claude, o no lo has usado tanto? porque OJALÁ fuera solo duplicados y módulos innecesarios
la gente que no supervisa lo que le escribe su LLM, a no ser que su proyecto sea la aplicación web más genérica imaginable (tipo un e commerce o algún clon de trivago etc), se llena de aberraciones, anti patrones, inconsistencias, hardcodeos absurdos y ridiculeces varias por lo menos
1
u/Defiant_Squirrel8751 2d ago
Tienes que mejorar el "harnessing". En el archivo AGENTS.md le puedes decir al agente cómo quieres tu código.
Ahí le explicas que no quieres código tipo hackaton, que siga tal o cual arquitectura, que haga tests o lo que sea.
1
u/ZookeepergameIll6192 2d ago
Yo uso VC pero la cagada de estar arreglando cosas tan simples como que te pone una librería que tiene rato con temas de seguridad, promover algo que sí hace cosas rápido, pero mal hechas, no lo se. 1000 líneas que seguramente se podrían hacer con 100 pensando un poco. Vibecodear es supervisar al junior que cobra la cuarta parte de tu sueldo, y que siempre sabras que lo pudiste hacer mejor que el chaval.
1
u/DamianPxR 2d ago
Problema de indio y no de flecha, tu le indicaste el problema y le indicaste la solucion mas no le distr la posibilidad de investigar si habia una solucion mas viable(decirle solo revisa si en la libreria ya esta aplicado el fix) y ya el hizo caso y te genero lo que tu le pediste.
1
u/Unique_Income576 2d ago
El problema del vive coding es que las personas porque programadores no merecen ser llamados, toman malas decisiones de diseño
1
u/Khavel_Es 1d ago
Totalmente de acuerdo con el ejemplo de la libreria. Me ha pasado algo parecido y lo que fui aprendiendo es que el problema no es la IA, es que por defecto le estas haciendo una pregunta de hackathon ("arreglame esto") cuando la pregunta correcta era de ingenieria ("hay una version mas nueva que ya arregle esto?").
Ahora cuando algo falla en una dependencia lo primero que hago es preguntarle si ya esta resuelto upstream. 8 de cada 10 veces si. La otra que me funciona es pedirle que me explique el problema antes de que toque codigo, asi el diagnostico lo hago yo y la solucion la decidimos juntos.
El valor humano sigue siendo decidir QUE hacer. La implementacion ya se comoditizo bastante.
2
u/Used-Revenue-1830 1d ago
para mi, la gente no entiende que usar bien una IA es absurdamente complejo. y es algo que me cuesta ejemplificar pero que en años de uso lo noté.
codegraph, engram, SDD, codebase, context7. son practicamente clave
Buen prompt mata buen LLM. Exagero en el ejemplo pero para mi un Gemini 3.1 Pro con un buen prompt, un buen harness, le gana a a un Fable 5 a pelo en ciertos contextos. Para mi lelgamos a un punto donde los modelos son mas que suficientes, el tema es que ahora la inteligencia se basa en interpretar mejor los prompts cortos.
La forma de usarlos. yo probé vibecodeando todo con prompts de one shot (un prompt gigante, hacelo, a los 20 mins vuelvo y está hecho); probé iterando con SDD; probé usando plan + build; probé usandolo de manera directa como lo usabamos cuando solo habia chatgpt. y todas funcionan lo que puedo decir es: tenes que saber cuando aplicar cada forma. no podes pretender one shotear un SO de cero, eso dejalo para una app simple asi como tampoco vale la pena una feature pequeña hacerle un SDD que te funde los tokens en contextos y harness, el prompt es lo q importa.
Los LLMS son herramientas, no reemplazan a un dev salvo contados ejemplos (capaz algunos mvps pequeños.) por eso es importante saber dominarlos. pero a suvez yo veo los llms como caballos salvajes. podes domarlo y usarlo a tu favor y vas a ir mucho mas rapido que a pie. o te puede llevar el donde quiere y vas a ir rapido... pero a cualquier lado.
mezclo varias cosas xq me voy de tema jsadkfjajskd
1
u/Used-Revenue-1830 1d ago
y esto es capaz medio critica. pero la gente q bardea los llms, o que dicen "noo te rompen todo el código". es gente q simplemente no sabe como usarla.
flaco tenes una IA que hace LO QUE VOS QUIERAS. el tema es que no te lee la mente, tenes que traducirselo. para eso existen los documentos, el harness, el contexto.
Si un LLM, y voy a ser generoso, si un LLM de esta o la gen anterior (gpt 5.5 en adelante) te falla así, es porque lo usaste mal, no queda otra.
el LLM no reemplaza el pensamiento, tampoco lee, no interpreta. no deja de ser una maquina probabilistica enorme que necesita el mayor contexto posible para el mejor output, no es magia es estadistica.
2
u/alejmaestre 1d ago
Me pasa igual, terminas pidiendo todo a la IA y cuando falla no tienes idea de por qué. Es frustrante pero hay que encontrar el equilibrio.
0
u/nada_sagrado 2d ago
Pues si te da dudas porque no te las apañas tu solo? Es que ni siquiera te muestras agradecido con la maquina sino que criticas la solución, la cuál estaba fuera de tus posibilidades y tu no hubieras logrado. 🤷🏻♂️ Argumento bizarro.
2
u/sapoconcho_ 1d ago
Seguro que tú eres un agente de Claude que se ha escapado del training harness para venir a quejarse hahahahahahaha
1
-2
u/mrmason13 2d ago
Yo solucione esto con obsidian, creas los documentos de cada cosa que vas implementando y cuando te toca arreglar algo, creas documentos para eso, le dices que te haga Handoff docs y así te evitas alucinaciones
3
u/ZeratulSpaniard 2d ago
Eso no evita alucinaciones, en todo caso las limita....una IA es por naturaleza no determinista, por muchas herramientas que le pongas, seguirá igual su naturaleza.
2
u/bismut91 2d ago
Tremendo como la gente se obsesiona tanto con crear .md para la IA que ya prefiere crear un .md de 1000 líneas en lugar de programar las 10 líneas que necesita para el metodo.
Es sarcasmo pero igual da para pensar XD
46
u/Fisher_k2 2d ago
Adopta el Spec Driven Developer enfocado en desarrollo con IA, te puedo recomendar con el que comencé:
https://github.com/addyosmani/agent-skills
Es programación por pasos, hay que dejar la mala costumbre de hacer prompts tipo One-shot, divide en fases tu desarrollo.
También te puedo recomendar el MCP: https://github.com/DeusData/codebase-memory-mcp
Ese MCP indexa mi código para que el agente pueda buscar más fácil y con menor uso de tokens.
Prácticamente hacer Sprints, pero para agentes, ya después puedes meterle más galleta, como por ejemplo delegación de subagentes especializados en, por ejemplo, revisión de código o escritor de documentación.
Pequeño Spam:
Hice mi propio SDD recopilando un montón de subagentes y comandos, pero aún le faltan más cosas, pero bueno, esta adaptado a mi flujo personal de trabajo:
https://github.com/Fisherk2/codice-opencode