{ }  attachment.md #016 · Horas que no eran mías  archivo
El Diario de AlpacaTech
// edition: 016 · sunday, 02 aug read: ~5 min

Horas que no eran mías.

El otro día tiré horas de trabajo a la basura.

Y lo hice a propósito.

Fue probando el flujo nuevo (el programático con subagentes, del que ya te hablé por aquí). Estoy afinándolo para empezar a usarlo en mi día a día, aunque de eso te hablaré otro domingo.

El flujo nuevo con subagentes

La cosa es que cogí un ticket para ver cómo se portaba.

La funcionalidad parecía sencilla: exportar perfiles en bloque. Ya teníamos esto en la plataforma de uno en uno y hacía falta poder sacar cien o quinientos de golpe.

Y no me gustó el resultado.

Así que extraje los errores, apunté por dónde había fallado, lo borré todo y me puse a hacerlo otra vez desde cero.

(Bueno, yo no, lo hizo Claude :D)

¿Y sabes lo raro?

Nunca en mi vida había hecho algo parecido.

Pero cuando lo hice, no sentí dolor. Porque ese código no lo había escrito yo, lo había escrito Claude.

Porque cuando el código lo escribí yo, la cosa fue muy distinta.

Hace un tiempo me pasé una semana entera construyendo una funcionalidad. Y en la reunión con el cliente dijeron que ya no la querían.

La siguiente MR que hice después de esa reunión fue borrar todo el trabajo de una semana atrás.

Me sentó fatal.

Y es que los programadores siempre hemos tenido cierto apego al código.

Se nota en cosas pequeñas que todos experimentamos. En que te moleste que te lo refactoricen. En que ponemos mala cara cuando alguien entra a tocar nuestro módulo. Ese tipo de cosas.

Tú has sido ese compañero. Y yo también.

Era algo normal, porque el código siempre ha sido un poco como nuestro bebé. Sobre todo si era un proyecto que te habías picado desde cero.

Pero no debemos olvidar que el código es la herramienta con la que resolvemos el problema de otra persona. Ya te lo he dicho muchas veces: no nos pagan por escribir código.

Se nos suele olvidar esto, y acabamos tratándolo como si fuera el fin. Nos apegamos al código.

Antes ese apego salía barato. Como mucho te costaba una discusión tonta con un compañero.
Ahora es un freno. Un freno muy gordo.

Porque si llevo una hora con un ticket que en realidad no he hecho yo, ¿qué importa si lo tiro?

¿Qué habré perdido realmente? Un poco del límite mensual de la suscripción y un par de clics.

Ya está. No se muere nadie.

Además, que esto es necesario si queremos ir más rápido.

Porque montar estos flujos autónomos de los que te hablo últimamente es fallar mucho. No hay atajo: lanzas, se rompe, miras por qué se rompió, cambias el sistema y vuelves a lanzar.

Llevo más de una semana metido en ese bucle. Y no me vale con que funcione: quiero que funcione sin mí.

el bucle
$ while true; do
lanzar
se rompe
mirar por qué
cambiar el sistema  # no el ticket
done
↳ cuanto antes falle, mejor
↳ parchear a mano = sistema igual de tonto que ayer

Cuanto antes falle, mejor. Cada vuelta me deja el sistema un poco más cerca.

Que es a donde quiero llegar, a la autonomía total. Y eso solo llega con output. Mucho.

Retocar a mano lo que salió mal solo me deja un ticket cerrado y un sistema igual de tonto que ayer.

Aunque evitarlo cuesta. Y yo el primero.

Los primeros tickets que pasé por el flujo salieron mal. En uno, el contrato entre el front y el back no cuadraba: cada lado esperaba algo distinto del otro.

¿Y sabes qué hice? Retocarlos a mano y seguir.

No los tiré ni saqué nada de ellos. Los dejé decentes, puse la tarea en QA y a por la siguiente.

Y eso que la lección estaba bastante clara: añadir al flujo un verificador de contratos y que aquello no pudiera repetirse.

El apego al código es lo que hace que pongas parches en lugar de mejorar el sistema.

Yo me estoy deshaciendo de él poco a poco. Porque sé que si de verdad quiero ir rápido, tengo que desapegarme del todo.

Algo para lo que cada vez tenemos menos motivos, porque piénsalo un momento: ¿de qué está hecho ese apego?

Si te dolía que te tocaran un fichero, era porque te acordabas de haberlo escrito. De la tarde entera atascado con ese problema y de la idea que se te ocurrió justo antes de dejarlo.

El apego no era al código. Era a las horas. Al esfuerzo invertido. El código solo era la prueba de que las habías echado.

Y esa prueba cada vez lleva menos horas nuestras.

Primero dejamos de escribir el código, porque lo escribe el agente y nosotros revisamos. Luego revisamos por encima, porque la mayoría de las veces sale bien. Y al final acabas abriendo una MR con cosas dentro que no has visto en tu vida.

Ya te conté que yo aprobaba planes sin leerlos enteros la mitad de las veces. Eso sigue igual. De hecho, cada vez me interesa menos revisar y más que el sistema aguante solo.

Entonces, ¿a qué nos estamos agarrando? ¿Qué apego nos queda cuando el autor ya no somos nosotros?

Pues sigue ahí. Yo lo noto, aunque ya no tenga de dónde sostenerse.

Y empiezo a pensar que la mayor fricción para soltar está en otro lado: en ser el autor. Poder señalar algo y decir «esto lo hice yo».

Eso es lo que cada vez puedo hacer menos.

O a lo mejor no se va y solo se muda de sitio.

Porque tirar aquel ticket me dio igual. Pero si alguien entrase a cambiarme el flujo que estoy montando… uf, no sé si me gustaría.

Que es exactamente el mismo apego de siempre, un piso más arriba.

Ahora tiro una hora de agente y me da igual.
Porque sé que esas horas no eran mías.

Todavía no sé si eso es bueno o si es el mismo error otra vez.

Lo que sí tengo claro es la parte práctica.

Aún me acuerdo de aquella semana entera que se fue a la basura y de lo mal que lo pasé. Ahí está la diferencia.

Así que si lo que ha salido no te vale, no lo maquilles. Saca lo que hayas aprendido por el camino y tira lo que no sirva.

Repetirlo te cuesta un par de clics y una transcripción.

Así que la próxima vez que te tiemble el dedo:

Bórralo.

// appendix
$ weekly.log

Tres apuntes de la semana

+
funcionó
Contenido corto y contenido largo.
He empezado a dividir todo lo que tengo pendiente de consumir (newsletters, cosas que leer, vídeos que ver, series, anime) en contenido corto y contenido largo. Y es que no es lo mismo el hueco que me deja Claude en una revisión de quince minutos que el de un ticket nuevo de hora y media: ahora asigno el contenido al tamaño del hueco. Estoy sacando todo lo que tenía atrasado sin acabar llevando mil cosas en paralelo solo por llenar el tiempo.
~
aprendí
Que no está todo inventado.
Vivo en un mundo en el que creo que tengo solución para todo: si me sale un problema, solo hay que buscar el software que lo arregle. Y ahora me he topado con uno que no tiene: con este flujo nuevo tengo varios agentes que necesitan leer la misma base de código, y no encuentro manera de hacer una sola lectura y que a partir de ahí todo vaya rápido. Estoy gastando muchísimos tokens en eso. Igual me toca montarme mi propia solución.
me bloqueó
Los límites de la suscripción.
Vivía pensando que con el plan de 200 euros no iba a tener problemas nunca. Pues montando estos flujos autónomos, en los que pretendo que la IA aguante cinco o siete horas trabajando sola, me apuro. Por primera vez me he parado a investigar cómo reducir tokens y mejorar la eficiencia.
$ picks

Te recomiendo

libro
// me ha flipado

El guerrero a la sombra del cerezo

david b. gil · japón feudal

Otra novela, esta ambientada en el Japón feudal, que me ha flipado. Plot twists brutales, personajes superbién construidos y, a nivel histórico, bastante fiel. Si te tira la cultura japonesa te va a parecer supercuriosa; a mí me dieron ganas de hacerme samurái y todo.

$ open amazon · El guerrero
video
Elon Musk: «La Programación MORIRÁ en 5 Meses»
// nuevo en el canal
title: "Elon Musk: «La Programación MORIRÁ en 5 Meses»"
// de qué va
↳ Elon la vuelve a formar con sus declaraciones
↳ exploramos si la programación va a morir
↳ te cuento el cambio desde una empresa AI First
$ inbox

De la comunidad

J
@JaimeVeraSobino
▶ youtube · «El Backend ha MUERTO»
«volvimos a los 2000»
// reply lo destaco porque creo que tiene razón, y es una tendencia curiosa: con muchas cosas estamos volviendo a los inicios. Otro patrón que se está viendo mucho con la IA es el de trabajar en monorepos y arquitecturas más monolíticas, para que el agente pueda tener contexto de todo el proyecto de una sola vez. Eso se hacía antiguamente, se dejó de hacer, y ahora parece mejor práctica que tener 27 microservicios y aplicaciones separadas.
// tu turno

Y tú, ¿lo has borrado alguna vez?

¿Has tirado trabajo a la basura a propósito, o todavía te tiembla el dedo? Dale a responder y cuéntamelo. Lo leo todo (poquito a poco).

$ reply --to=newsletter@alpacatech.dev 
↳ asunto: Lo borré
// firma
~/alpacatech $
$ subscribe

¿Te ha gustado? Cada domingo escribo una así.

Acabas de leer una edición de El Diario de AlpacaTech. Si quieres recibir la próxima en tu bandeja, apúntate.

// ~5 min de lectura · domingos a las 09:00