El libro enseña a programar acompañado por un agente de línea de comandos: cómo se le da memoria del proyecto, cómo se conectan servidores externos que le dan herramientas, cómo se le encargan tareas a subagentes, cómo se automatizan pasos con ganchos. Es un manual de producto, y hay que leerlo sabiéndolo.
Qué me llevé
La distinción entre pedirle bien las cosas a un modelo y administrarle el contexto. Lo primero es redacción; lo segundo es ingeniería: qué se escribe de forma permanente, qué se recupera solo cuando hace falta, qué se comprime y qué se aísla en un proceso aparte para que no contamine el resto. Esa cuadrícula de cuatro me sirve para cualquier herramienta, y seguirá sirviendo cuando esta ya no exista.
La segunda: el archivo de memoria del proyecto es documentación que sí se mantiene, porque tiene un lector que la usa todos los días. Es el único caso que conozco donde escribir las convenciones de un repositorio deja de ser un gesto voluntarioso.
Y la tercera, en contra de la moda: antes de repartir el trabajo entre varios agentes, agotar lo que hace uno solo bien informado. Los autores lo muestran sin decirlo, porque los ejemplos de varios agentes son los que más se enredan.
Qué dejé fuera
Casi todo lo demás, por el motivo obvio: precios, planes, pantallas y nombres de comandos cambian cada pocas semanas. Un libro impreso sobre una herramienta que se actualiza sola es un instrumento raro, útil el primer mes y arqueológico al año. Lo leí por la parte conceptual y por ver cómo alguien más ordena el oficio; para lo operativo, la documentación del propio producto está más al día y es gratis.