[🧑‍💻] Hacerlo rápido con IA no es lo mismo que hacerlo profesionalmente

✨ Resumen de GPT-5.6 Sol 　

Aceleré la implementación con IA y harnesses, pero descuidé la coherencia de planificación, diseño y documentación, y revisé mi arrogancia al ver el trabajo en Figma y el manual de un equipo externo.

Al final, hay que ser humilde.

Hace unos días, cuando vi un sistema de trabajo que la empresa había encargado a un equipo externo y que había llevado bastante tiempo construir, pensé con sinceridad: “Si lo hubiera hecho yo, habría terminado mucho más rápido…”

La velocidad que gané con IA y harnesses

Aunque el vibe coding con IA tenga muchos huecos, sigo pensando que se puede mejorar lo suficiente. Si se avanza con todo el cuidado posible sobre una base de TDD y se construyen buenos harnesses para prevenir problemas recurrentes, debería ser posible. Al ver a las Big Tech que están realmente metidas en IA, también pensé que quizá siga reduciéndose el peso de los desarrolladores que escriben código directamente.

Por supuesto, esa opinión no ha cambiado nada. Si se usa bien la IA, se colocan pruebas y harnesses como corresponde, y se construyen con cuidado estructuras para evitar que los problemas reaparezcan, la velocidad y la calidad del desarrollo pueden cambiar mucho.

Pero sí sentí que debía revisar la arrogancia detrás de “habría terminado mucho más rápido…”

Últimamente suelo desarrollar así. Voy y vengo con agentes, sigo mejorando la estructura de harness engineering, evito la recurrencia de distintos problemas, agrego nuevas funciones, recibo feedback y vuelvo a corregir. Para trabajos repetitivos, creo agentes worker/coordinator y los ejecuto.

Mi desarrollo dejó fuera la coherencia

Esa rutina me dio velocidad de desarrollo y cambios rápidos de dirección, y también funcionó bastante bien para evitar que problemas similares se repitieran. Pero era débil para unir todo el producto bajo una sola filosofía de planificación y diseño. Podía empujar la implementación rápido, pero la coherencia de diseño, función y planificación era muy baja.

Aun así, no veo esto como una limitación inherente del vibe coding. Es más bien que todavía no he incorporado suficientemente criterios de planificación, diseño y documentación dentro de mi harness engineering.

El profesionalismo que vi en Figma y en el manual

Pero al ver que aquel equipo externo usaba Figma de forma activa para registrar distintas estructuras de pantalla y dejar descriptions y flows, algo quedó claro. Había un profesionalismo distinto de mi forma de lanzarme sin suficiente estructura. La alta coherencia de sus propuestas y entregables daba una fuerte sensación de confianza.

Ese profesionalismo también aparecía en el manual de GitBook. Yo solo pensaba: si lo hago bien, los usuarios se las arreglarán; si la UI/UX es intuitiva, bastará. Nunca había imaginado crear una guía para el personal interno.

Claro, si la UX es buena y los botones de ayuda están justo donde uno espera encontrarlos, todavía me queda la duda honesta de si realmente hace falta una guía.

En fin… todavía pienso que minimizar el uso de LLM y programar directamente es una cultura de desarrollo bastante antigua y difícil de recomendar. Pero sí entendí claramente que no estoy en un nivel profesional como para tomarlos a la ligera y despedazarlos con críticas.

Siempre ser humilde. Siempre aprender.