El código barato y el juicio caro

Hay un chiste recurrente en los círculos de desarrollo: el código generado por IA es "basura"—resultado de baja calidad que no deberías confiar. Pero esa forma de verlo pierde lo esencial. La basura no es el código escrito por IA. La basura es el código que parece terminado pero esconde bugs, desajustes y fragilidad. Nunca se trata de la herramienta. Se trata del pensamiento detrás.

Esto es lo que he observado después de meses trabajando con herramientas de desarrollo asistido por IA: la alegría de programar no desapareció. Se mudó.

Escribir nunca fue lo importante

¿Recuerdas la primera vez que una pieza de código encajó perfectamente? El momento en que una solución cubría no solo el problema frente a ti, sino también casos extremos que ni siquiera habías considerado. Esa sensación—ese clic—es lo que realmente protegemos.

Durante años, ese clic ocurría mientras escribías. Luchabas con un problema, probabas variaciones, borrabas la mitad, y finalmente llegabas a algo elegante. El teclado era donde vivía el pensamiento.

Pero aquí está el punto: el clic nunca estuvo en las teclas. Estaba en el reconocimiento. El momento en que veías una solución que iba más allá de lo específico—algo que seguía la estructura real del problema. Eso era lo satisfactorio. Eso era la ingeniería.

Código barato, juicio caro

La IA redujo drásticamente el costo de entregar una funcionalidad. Escribes un prompt, obtienes código funcional, lo envías. El umbral de calificación se movió. Y para muchos desarrolladores, eso es incómodo. Siente como si el oficio se hubiera diluido.

Pero hay otro costo que no bajó: saber qué solución elegir.

Cuando trabajo en un nuevo proyecto en NameOcean o ayudo a clientes a depurar infraestructura compleja, la IA me da opciones rápido. Tres versiones de una configuración de DNS. Cuatro enfoques para manejar certificados SSL. Cinco formas de estructurar un pipeline de despliegue.

La primera versión es casi siempre la específica—resuelve exactamente lo que describí, y nada más. Útil, pero limitada. La cuarta o quinta intención a menudo revela algo diferente: una estructura que contempla casos que no mencioné, patrones que escalan más allá de mi planteamiento inicial.

Ahí es donde vive el juicio de ingeniería ahora. No en escribir el código desde cero, sino en reconocer cuál de los candidatos realmente sigue la forma real del problema.

Leer es el nuevo escribir

El cambio suena simple: genera más, lee más, elige sabiamente. Pero es un cambio genuino en el flujo de trabajo.

Cuando escribías código a mano, buscabas dentro de lo que ya conocías. Tus hábitos, tus patrones, tu vocabulario mental. Con asistencia de IA, el espacio de búsqueda explota. Puedes pedir enfoques poco convencionales, patrones de máquina de estados cuando normalmente llegarías a if-statements, pensamiento schema-first cuando defaultearías a validación campo por campo.

El apalancamiento no está en la generación—está en la lectura. Estás buscando en una cuenca mucho más amplia de posibilidades, y el costo es leer entre intentos en lugar de escribir uno.

Esto es por qué el "vibe coding" funciona cuando se hace bien. No estás simplemente aceptando la primera salida. Estás iterando, critiquando, empujando a la IA hacia mejores planteamientos. Lo estás usando como un socio de pensamiento, no como una máquina de escribir con esteroides.

El impuesto del juicio

Hay un detalle que vale la pena nombrar: la capacidad de reconocer la solución elegante no se abarató junto con todo lo demás. Años de depurar, refactorizar y enviar código construyeron ese músculo silenciosamente. Sigue siendo caro.

Puedes generar cincuenta candidatos en el tiempo que antes tomaba escribir uno. Pero elegir el que viaja más lejos—el que resuelve el problema de hoy sin crear la deuda de mañana—ese juicio sigue siendo tuyo.

Los ingenieros que prosperan en este nuevo mundo no son los que escriben código más rápido. Son los que leen más ampliamente y juzgan más afiladamente. El oficio no murió. Subió de nivel.

Donde vive el clic ahora

Aquí está mi parte favorita: el clic sigue existiendo. Ese momento de reconocimiento cuando una forma encaja y ves que cubre casos que nadie pidió todavía. Sigue ahí. Solo ocurre mientras lees entre cuatro intentos en lugar de escribir uno.

La semana pasada estaba trabajando en un parser de configuración para la infraestructura de hosting de un cliente. La primera sugerencia de IA manejaba el camino feliz. La tercera sugerencia usó una declaración de schema que hizo que todo encajara—validación, seguridad de tipos, documentación y extensibilidad futura saliendo de una sola estructura.

No escribí esa solución. Pero la reconocí cuando la vi. Y eso es lo que se sintió exactamente igual.

La alegría no se fue. Se mudó a donde el trabajo real de ingeniería sucede: entender problemas lo suficientemente profundo para reconocer cuando una solución es más de lo que parece.

Si sientes resistencia al desarrollo asistido por IA, te pediría que notes qué estás defendiendo realmente. ¿Escribir? Eso se está volviendo barato. El reconocimiento, el juicio, el gusto por las soluciones elegantes—ahí es donde vive el oficio ahora. Y esa parte se transferió perfectamente.

La banda sonora de construir software cambió. Pero la música sigue ahí.