No me gusta hablar con robots

Tengo un teléfono Android, pero he desactivado los comandos de voz. Nunca he tenido un Alexa. No estoy seguro de qué hace exactamente Siri, porque he logrado vivir sin que me busque una lista de reproducción. Así que cuando las herramientas de codificación con IA se volvieron difíciles de ignorar, me fui convenciendo lentamente. Durante un tiempo, hice lo que algunos llaman 'enfoque de delegación puntual a la IA': trabajaba como siempre, delegando ocasionalmente una parte del trabajo a la IA, y luego esperaba a ver qué devolvía. Es un enfoque muy interesante para quienes les gusta apostar.

Para mí, parte de la fricción era la interfaz de chat misma. La idea de tener una conversación con el modelo me parecía tonta. Yo construyo cosas. No negocio con cajas de texto.

Pero el desarrollo basado en especificaciones no funciona así. Defines el problema con precisión, le dices al modelo qué archivos considerar, describes el resultado deseado, y vas y vienes charlando sobre el plan antes de que la IA genere una línea de código. Los modelos de IA actuales son rápidos para codificar, pero aún son peligrosamente inconsistentes en la toma de decisiones de alto nivel. Cuando trabajas con IA, tu trabajo es convertir tu criterio de diseño en una especificación escrita, para que puedas darle a la IA una lista de pasos de baja decisión que coincidan con lo que harías, si fueras a escribir el código tú mismo. Para que esa especificación sea correcta, tienes que negociar.

He aprendido esto en los últimos seis meses. Y me he vuelto bastante bueno en ello. Rara vez/nunca escribo código a mano, sin embargo, estoy entregando más funciones que nunca antes. Y dado que no estoy delegando el diseño de software al modelo, estoy aplicando los mismos estándares de calidad que he aprendido a mantener en mi carrera de 25 años construyendo productos digitales.

Lo que no esperaba era lo difícil que sería enseñar esto.

¿Ya soy Picasso?

Existe una noción (¿entre la alta dirección?) de que las herramientas de modelos de lenguaje grande aumentarán la productividad de todos los ingenieros. En la práctica, no he visto esto. Lo que veo es que los ingenieros experimentados y adaptables logran múltiplos de lo que solían producir, mientras que otros producen lo mismo o menos.

Esta no es una buena situación para quienes empiezan. Las herramientas de codificación con IA parecen simples porque sus interfaces son solo cuadros de texto. Pero no te haces Picasso embadurnando pintura al azar en un lienzo en blanco.

Síndrome de implementación paralela

Valoro a los ingenieros junior por muchas razones, y no menos importante es que son mis favoritos para trabajar. Su mentalidad abierta no se ha atrofiado todavía, y me ayudan a ver las cosas de manera diferente. Recientemente, emprendí un viaje de aprendizaje en IA con un joven ingeniero que es inteligente, entusiasta de las herramientas de IA, con ganas de involucrarse y sin ninguna vacilación para hablar con el robot.

Y sin embargo, de alguna manera no estaba funcionando.

La primera señal fue el sistema de autenticación. Ella necesitaba añadir OAuth a un servicio existente, y le pidió al modelo que construyera todo el flujo de autenticación en una especificación gigante. Inicio de sesión, renovación de token, gestión de sesiones, acceso basado en roles, y el flujo de cierre de sesión. Todo. El modelo lo hizo con gusto. Produjo varios cientos de líneas de código que parecían completas con un 100% de cobertura de código y pruebas aprobadas.

Pero cuando lo revisé, los problemas eran estructurales. El modelo había creado un nuevo almacén de sesiones en lugar de usar el que ya teníamos. Introdujo un patrón de renovación de tokens que entraba en conflicto con nuestra puerta de enlace de API. La lógica de acceso basada en roles duplicaba reglas de negocio que ya residían en un middleware compartido. Técnicamente, nada de esto estaba mal—funcionaba. Arquitectónicamente, todo lo estaba.

Me senté con ella y le hice una pregunta sencilla: “Antes de que generaras esto, ¿sabías cómo manejamos las sesiones hoy en día?” Ella hizo una pausa. “No exactamente.” Esa era la brecha. No había mapeado el territorio antes de pedirle al modelo que construyera sobre ello.

El siguiente intento fue diferente, pero no lo suficiente. Ella le pidió al modelo que modificara el flujo de inicio de sesión para admitir un nuevo proveedor. Esta vez, ella estaba reduciendo el alcance, lo cual era bueno. Pero describió el cambio en términos de lo que quería que hiciera la interfaz de usuario (IU), no en términos de lo que el código existente ya manejaba. El modelo, sin tener razón para conocer nuestra abstracción de proveedores existente, escribió una implementación paralela desde cero. Mismo resultado: código funcional, arquitectura incorrecta.

Hablamos sobre lo que había sucedido. Le dije que pensara en el modelo de la misma manera en que pensaría en un nuevo contratista en el equipo. Talentoso, rápido, sin experiencia con nuestra base de código. No le entregarías este proyecto a un contratista y te irías. Dirías: aquí está nuestro almacén de sesiones, aquí está el middleware, aquí está el patrón para agregar un nuevo proveedor. Adapta tu trabajo a esto.

Ella entendió el concepto. Pero las siguientes rondas me mostraron que el concepto era la parte fácil. Ella obtendría un solo plan del modelo y lo aprobaría sin insistir en alternativas. Ella veía la disposición del modelo para hacer cambios de código expansivos como ser minucioso; yo lo veía como un riesgo innecesario. Ella aún no tenía el instinto para decir 'no, eso es demasiada área de superficie para este cambio.'

Un ingeniero experimentado habría manejado esa misma tarea de OAuth en seis o siete rondas enfocadas, cada una con alcance limitado a una parte del sistema que ya entendía.

Las habilidades blandas son las nuevas habilidades técnicas

Esto podría sonar como una sobrecarga que eliminaría las ganancias de productividad de la codificación con IA. Pero estas no son habilidades nuevas. Los ingenieros experimentados han estado haciendo esto en sus cabezas todo el tiempo. La diferencia es que el desarrollo basado en especificaciones externaliza la planificación del diseño de software de todas las tareas. La negociación de diseño que solía ocurrir internamente, entre tú y tu propio juicio, ahora ocurre en una ventana de chat.

Antes de abrir el chat, necesitas saber lo que quieres. No la implementación, sino el comportamiento, las restricciones, la forma en que debe ser. Necesitas conocer tu base de código lo suficientemente bien para indicarle al modelo dónde debe encajar su trabajo. Cuando el modelo devuelva una respuesta, probablemente funcionará. Eso no es suficiente. Necesitas saber si realmente encaja en el sistema que ya tienes.

A veces reconoces que el modelo está en lo correcto y tú te equivocas, y necesitas la humildad para evaluarlo con imparcialidad.

En todo el proceso, lo que separa a las personas que usan estas herramientas bien de las que las usan rápido es la paciencia: la disposición a ir y venir cinco o seis veces en lugar de aceptar algo mediocre en la segunda ronda. También está la habilidad de escribir con precisión sobre el código sin escribir código, describiendo flujos de datos, casos límite y modos de fallo en lenguaje sencillo. Y está el criterio, que es más difícil de definir pero fácil de reconocer: una sensación de cómo se siente el buen software desde la perspectiva del mantenimiento a largo plazo, no solo de si funciona.

Y luego está la parte incómoda. La mayoría de estas habilidades son reconocimiento de patrones construido a partir de años de equivocarse. Reconoces una mala decisión arquitectónica porque has vivido con las consecuencias de una. Te resistes a la respuesta inicial del modelo porque has implementado tu primera idea antes y te has arrepentido.

Los ingenieros junior se están viendo en situaciones donde necesitan realizar una negociación de diseño a un alto nivel, pero no parece haber un plan de estudios para eso. Es hora de alejarse de 'LeetCode' hacia la negociación de diseño, y este será el tema de futuras publicaciones en esta serie.

Adenda

Habilidades Blandas para la Negociación de Especificaciones con IA

Durante la Negociación

• Fluidez en lectura de código: Examina lo que produce el modelo para solidez estructural, no solo sintaxis. Estás leyendo para ajuste, no para errores. Por qué importa: El modelo puede generar código válido que no pertenece a tu sistema. Necesitas detectarlo rápidamente.

• Criterio arquitectónico: Reconocer cuando una solución es técnicamente válida pero incorrecta para este sistema. Por qué importa: El modelo no sabe lo que significa 'incorrecto para nosotros'. Tú lo sabes.

• Dirección creativa: Encuentra enfoques alternativos cuando el modelo se atasque. Replantea el problema, ofrece una analogía, constrínalo de manera diferente. Por qué es importante: El modelo responde a cómo enfoques las cosas, y un mejor enfoque produce un mejor resultado.

• Saber cuándo tomar una postura: El modelo presenta opciones de manera neutral. Tú decides y articulas por qué un enfoque es mejor para tu contexto. Por qué es importante: Eso es juicio de ingeniería, y lleva años desarrollarlo.

• Escepticismo productivo: Asume que la primera respuesta del modelo es un borrador, no una solución. No es cinismo, sino el hábito de la prueba de resistencia antes de aceptar. Por qué es importante: Las salidas de primera pasada son seductoras porque son fluidas. La fluidez no es corrección.

• Saber lo que no sabes: Reconocer cuando el modelo podría tener razón y tú podrías estar equivocado. Por qué importa: La negociación va en ambos sentidos. A veces saca a la luz un enfoque que no habías considerado, y necesitas la humildad para evaluarlo de manera justa.

A lo largo de todo el proceso

• Paciencia: Ir y volver cinco o seis veces en lugar de aceptar algo mediocre en la segunda ronda. Por qué importa: Esto separa a las personas que usan bien la herramienta de las que la usan rápido.

• Comunicación técnica: Escribe con precisión sobre el código sin escribir código. Describe flujos de datos, cambios de estado, casos límite y modos de fallo en lenguaje sencillo. Por qué es importante: Esto es más difícil de lo que la mayoría de los ingenieros piensa, y es la interfaz principal entre tú y el modelo.

• Mantener la complejidad en la mente: Seguir cómo la decisión actual interactúa con otras tres partes del sistema que el modelo no conoce. Por qué es importante: El modelo no tiene un contexto arquitectónico persistente. Tú eres la memoria de trabajo.

• gusto: Un sentido de cómo se siente un buen software desde la perspectiva del usuario. No solo "¿funciona?" sino "¿es esta la experiencia correcta, el comportamiento correcto, el nivel de complejidad correcto?" Por qué es importante: Sin esto, aceptarás soluciones que son funcionales pero incorrectas.

• Saber cuándo parar: Reconocer cuándo la especificación es lo suficientemente buena para entregarla a la ejecución, y cuándo estás sobreperfeccionando. Por qué es importante: Los rendimientos decrecientes son reales. En algún momento, una negociación adicional cuesta más de lo que mejora.