Qué hacemos las personas todo el día

Hace unas semanas, un amigo me preguntó durante la cena qué hago ahora. Lo preguntó con cuidado, como se pregunta por un trabajo que quizá esté desapareciendo.

Es una pregunta justa. Las cuatro notas anteriores describen un sistema que escribe código, lo revisa, lo valida en un navegador y lo promueve a producción mientras yo duermo. Si todo eso es cierto, y lo es, la siguiente pregunta resulta obvia: ¿qué me queda por hacer?

Más de lo que esperaba. Solo que no son las partes que habría imaginado.

Decidir dónde separar el trabajo

La hora más valiosa de mi día es la que uso para convertir algo vago en tareas.

Suena a gestión de proyectos, pero no lo es. Es el trabajo de diseño que decide los límites. Qué cabe en un cambio, qué necesita tres, qué debe llegar primero y dónde debe quedar la interfaz para que dos piezas puedan construirse de forma independiente. Cuando esas divisiones están bien, el trabajo avanza sin mucha fricción. Cuando están mal, ningún agente capaz logra rescatarlo.

Ya escribí sobre aquella tarea de “internacionalizar toda la aplicación” que en realidad no era una tarea. Un ejemplo más útil fue la importación de documentos bancarios. Para una persona es una sola frase. Para nosotros fueron siete tareas y el orden era todo. El contrato común que devuelve cada parser tenía que existir antes que cualquier parser. La primera tarea no mostró nada visible, pero permitió construir las cuatro siguientes en cualquier orden sin que se tocaran.

Elegir esa secuencia tomó una tarde y evitó una semana de trabajo repetido. El repositorio no podía tomar esa decisión porque depende de los formatos que queremos soportar el próximo año. Eso está en nuestros planes, no en el código.

Decir que no

Ningún agente me ha dicho que una función no debería existir.

Me dirá que un enfoque es arriesgado, que un esquema está mal o que un plan tiene un hueco. Pide una función y recibirás una función competente con pruebas. El juicio de que una idea es mala, que es correcta pero no ahora o que es el síntoma de otro problema sigue de mi lado.

Lo mismo ocurre con el gusto. El mes pasado dedicamos tiempo a hacer nuestras alertas más silenciosas. Usamos líneas más finas, menos color y menos cajas. Nada de eso corregía un error. La versión anterior funcionaba. Simplemente gritaba.

Creo que esta división va a durar, no por una limitación de los modelos. Estas preguntas no tienen una respuesta que pueda deducirse del repositorio. Dependen de quién usa el producto y de lo que estoy dispuesto a mantener durante los próximos cinco años.

Las tareas que esperan

La parte más instructiva de mi semana es la pequeña pila de tareas que el pipeline se niega a construir.

Vuelven una tanda tras otra. En lugar de intentarlas, los agentes piden una decisión. Cuando las leo, tienen razón. Cada una está bloqueada por una decisión de producto que nadie ha tomado.

La que lleva más tiempo es un estado de préstamo que muestra un pago sin decir desde qué cuenta salió. Podríamos inventar la transferencia correspondiente. Los libros cuadrarían, pero quizá estaríamos mintiendo. Podríamos dejar el pago sin conectar. Sería honesto y parecería roto. Podríamos buscar una transacción parecida y enlazarla. Casi siempre acertaríamos y alguna vez nos equivocaríamos de forma seria.

Las tres opciones se pueden defender. Ninguna vive en el código.

Un agente que adivinara produciría código funcional para una decisión que nadie examinó. Ese es el resultado más caro porque parece terminado y te compromete en silencio. Dejar la tarea quieta es el comportamiento correcto. Pero no se desbloqueará sola. Un pipeline capaz de construir cualquier cosa sirve de poco si la cola está llena de decisiones que solo yo puedo tomar. Algunas semanas, el cuello de botella soy yo.

La pila también muestra patrones. Una tarea que vuelve tres veces rara vez tiene un problema técnico. Normalmente, yo la definí mal y tengo que corregirla desde el principio.

Decidir si sale y leer el momento

Antes de que algo llegue a producción decido si debe salir. Casi todos los días es rápido porque los controles ya hicieron el trabajo y solo leo un resumen. Otros días no lo es. Puede ser un cambio que pasó todas las pruebas pero que ya no me convence, o una entrega técnicamente correcta en el peor momento posible.

Nunca he sentido que esa decisión se pueda automatizar. Tampoco quiero hacerlo. Alguien debe responder por lo que reciben nuestros usuarios de una manera que una ejecución de pruebas no puede asumir.

Lo que cambió de verdad

Mi número de commits bajó casi a cero. Mi número de pestañas abiertas no.

Escribo mucho menos código y leo mucho más. La parte de teclear desapareció. Decidir pesa más y ocurre con mayor frecuencia porque la maquinaria posterior avanza tan rápido que mis decisiones son ahora el límite. También tuve que aprender a decir con mucha precisión lo que quiero. Una instrucción vaga ya no pierde una tarde. Produce una gran cantidad de trabajo equivocado, entregado a tiempo y con mucha seguridad.

La parte incómoda es descubrir cuánto de mi día anterior era una forma de evitar el trabajo difícil. Escribir la versión obvia de una función que ya había diseñado parecía trabajo. Era teclear. Al quitarlo, quedaron menos lugares donde esconderse y más horas dedicadas a las decisiones que sí cuestan.

Sobre esta serie

Estas cinco notas empezaron como tareas. Las redactamos con ayuda de un asistente y una guía escrita sobre cómo queríamos sonar. Después, una revisión separada buscó señales de texto generado y encontró bastantes, incluso en frases que yo habría defendido.

Yo decidí qué debía contar la serie, cuáles historias valían la pena y dónde el texto estaba demasiado satisfecho consigo mismo. Es la misma división que usamos en el resto del trabajo.

Si llegaste hasta aquí y quieres discutir alguna parte, de verdad quiero leerte.