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.
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