Making it right and fast en la era del vibe coding

Mantra

Make it work, make it right, make it fast es una buena forma de pensar el desarrollo de software. No es perfecta porque estas etapas no son tan claras ni secuenciales, pero sigue siendo un buen modelo mental para ordenar las prioridades cuando te sentás a encarar una tarea de programación.

Y además se explica sola: primero hacé que funcione lo básico. Después refactorizá, mejorá la legibilidad, seguí algún patrón de arquitectura, etc. Finalmente, optimizá el código.

El problema con la programación asistida por IA es que pusimos toda la atención en el make it work y le estamos prestando mucha menos atención al resto.

Las herramientas de IA derrumbaron el costo de esa primera etapa. Describís lo que querés, iterás un par de veces, y en minutos tenés algo que corre. Capaz hasta pasa los tests. Listo. A producción.

Make it work, but also make it right and fast

Sin LLMs, cuando uno tenía que programar a mano con nada más que ingenio y Stack Overflow, el proceso de hacerlo funcionar también implicaba hacerlo bien y hacerlo rápido, al menos en parte: la primera versión funcional que resolvía el problema solía tener una calidad más alta que la que sale del nuevo paradigma.

Eso no quiere decir que no necesitara refactors o mejoras. Por eso siempre existió la deuda técnica. Pero en general, el código pasaba revisión sin grandes cambios, salvo que tu reviewer estuviera de mal humor.

Hacerlo funcionar antes significaba más que “corre sin errores”.

Significaba código que encajaba naturalmente en el sistema, usaba las abstracciones correctas, seguía el estilo del proyecto, no sorprendía a quien lo tocara después. No perfecto, con algún code smell, pero aceptable.

Ahora el código anda, pero muchas veces se siente raro.

La era del vibe coding

Los tests dan verde (a veces porque el modelo generó un test que hace un assert que un valor mockeado es igual al mismo valor), y hasta el mensaje del PR suena profesional (porque también está generado y es slop).

Pero se nota cuando algo fue hecho mayormente con vibe coding por pistas obvias:

• Comentarios explicando lo evidente, o incluso cosas como # Delete the load_dataset function since we moved it to its own module (no todos los días ves comentarios sobre código que ni existe).
• Métodos y funciones en archivos donde no deberían estar.
• Código sobredefensivo. No hay modelo Pydantic ni type hint que convenza a Claude de que un argumento no puede ser None y no necesita un if ni un try/except.
• Dependencias nuevas que en realidad no hacen falta.
• Abstracciones y capas de indirección. Los LLM tienden a pensar que líneas de código contiguas y relacionadas deben ir en una función, aunque eso implique que ahora tenga que scrollear 200 líneas para ver qué hace.
• Archivos Markdown llenos de emojis.

Todo eso “funciona”, pero se nota que nadie realmente lo escribió. Alguien simplemente lo pidió¹.

Los puntos de arriba son en su mayoría inofensivos, pero son el canary in a coalmine que te hace pensar “ok, mejor miro el resto del código con más atención”.
Porque escondido entre el slop hay cambios más sutiles que vuelven el código más difícil de seguir y más lento con el tiempo.

Capaz se arregla solo

Hay un tweet que viene circulando:

Mantener apps codeadas con vibe es trabajo para GPT-7, no para humanos.
La deuda técnica se devalúa con cada modelo nuevo.
La idea de que tenés que entender personalmente el código es una visión cortoplacista, propia de alguien que nunca trabajó en una empresa grande con rotación.

Es una forma ingeniosa de pensarlo, y en principio tiene sentido.
Si cada modelo nuevo es mejor escribiendo y refactorizando código, el próximo va a limpiar lo que hizo esta generación.

Ahí es donde no estoy del todo de acuerdo:

• Las chances de que alguien tenga que limpiar el desorden antes de que salga el modelo mejor son bastante altas.
• No le puedo decir a mi jefe que rompimos producción porque nuestro LLM actual se equivocó, pero el próximo lo va a arreglar.

Mi opinión viene de alguien que trabaja en un lugar donde la gente rota entre equipos con frecuencia y suele encontrarse con bases de código nuevas, y donde la arquitectura de microservicios muchas veces hace necesario tener que mandar un pull request a la aplicación de otra persona (Mercado Libre). Con AI slop no vas a llegar muy lejos, y si llegás, le va a costar a alguien en el corto plazo (probablemente a vos mismo).

El paso que falta

La ironía es que la IA nos dio más tiempo, haciendo que construir la primera versión sea órdenes de magnitud más rápido.

Pero en vez de usar ese tiempo para hacerlo bien o rápido, lo usamos para hacer más cosas que funcionan, pero que agregan más deuda técnica en el camino.

El segundo y tercer paso son donde viven la legibilidad, el mantenimiento y el rendimiento a largo plazo.
Son las partes que hacen que tu yo del futuro —o tu compañero de equipo— no te odie por complicarle la vida.

No digo que no haya que trabajar rápido. We definitely should deliver more value to shareholders. Pero tal vez podamos trabajar rápido, pero no tan rápido, y usar ese tiempo extra para no dispararnos en el pie con código de mala calidad.