|
| 1 | +--- |
| 2 | +slug: steering |
| 3 | +date: 2025-11-06 |
| 4 | +draft: true |
| 5 | +tags: |
| 6 | + - asistentes-de-programación |
| 7 | +journal: Website |
| 8 | +journal-date: 2025-11-06 |
| 9 | +--- |
| 10 | +En esta cuarta entrega de la serie de Principios Fundamentales para el uso de Asistentes de Programación, está enfocada en el "steering", con lo que me refiero a las prácticas que nos permiten que el un [Asistente de Programación](/2025/11/03/una-vision-de-sistemas-para-la-programacion-asistida-por-ia) favorezca de forma consistente la producción de [alucinaciones positivas](/2025/10/20/la-alucinacion-es-el-feature-fundamental-de-los-llms), alucinaciones que aportan valor a los desarrolladores y a los usuarios de nuestra aplicación. |
| 11 | + |
| 12 | +En esencia el *steering* consiste en crear y mantener el entorno *mínimo indispensable* de *instrucciones* y *ejemplos* (patrones) *alineados* que se integran contexto en el *momento necesario* y *propician* que el modelo genere "buen software". |
| 13 | + |
| 14 | +Aquí tenemos que ampliar nuestra perspectiva del sistema para abarcar tanto el asistente como el código y tooling existente, por que este steering opera en dos dimensiones que son complementarias y alineadas: |
| 15 | + |
| 16 | +- Nuestro propio software y tooling que es nuestro objeto de interés, y... |
| 17 | + |
| 18 | +- Toda la información específica al asistente con el fin de alinearlo mejor con nuestro código y entorno de desarrollo, el ejemplo más conocido y sencillos de esto son los archivos `AGENTS.md` o `CLAUDE.md` |
| 19 | + |
| 20 | +Y la realidad más brutal del desarrollo de software es que **el grueso del código se hereda y de alguna u otra forma hay que vivir con las decisiones del pasado hayan sido nuestras o no**. Y estemos claros de que estamos agregando una nueva dimensión a esta "herencia" y la punta del iceberg es `AGENTS.md` |
| 21 | +## Lo que se hereda no se hurta |
| 22 | + |
| 23 | +Si nuestro código ya sigue buenas prácticas de forma consistente, entonces cuando este código se cargue en el contexto va a servir como un patrón de referencia para el modelo. |
| 24 | + |
| 25 | +Este steering puede ocurrir "naturalmente", porque el asistente siempre va a leer y a cargar código existente en contexto, pero es aún mejor si nosotros lo fomentamos al pedirle de forma explícita que busque ejemplos dentro del código y que los analice antes de planificar o moverse adelante con alguna tarea. |
| 26 | + |
| 27 | +Como política es útil favorecer cambios al código que no solo tengan un impacto positivo *inmediato*, sino que sirvan como retroalimentación positiva al sistema y que en el futuro ayudan a favorecer nuestras necesidades. |
| 28 | +## La espiral descendente del Vibecoding |
| 29 | + |
| 30 | +Ni que decir que si nuestro código no sigue buenas prácticas, no es consistente o tiene deuda técnica no explícita y no atendida, su sola presencia en el contexto es un driver potente para continuar en una espiral descendente de calidad en cada generación. |
| 31 | + |
| 32 | +Y esta es la explicación de por qué a medida que los proyectos "vibecoded" crecen tienden a colapsar bajo el efecto compuesto de todas las malas prácticas, practicas contradictorias y errores, llegando a un punto donde no importa cuanto código se agregue es imposible reconciliarla toda esta mala herencia en algo que funcione. |
| 33 | + |
| 34 | +**Aclaratoria**: Cuando Karpathy acuña el término "Vibecoding" se refiere a software desechable, del tipo prueba de concepto (PoC), que permite explorar una idea y del que no se espera un uso ni desarrollo continuado en el tiempo. |
| 35 | +## Mientras tanto del lado del Asistente |
| 36 | + |
| 37 | +El steering está distribuido entre todos estos artefactos que son específicos a los asistentes. En la lista a continuación algunos son específicos a Claude Code que es el sistema con el que tengo más experiencia, pero muchos están en el roadmap otras compañías o pueden ser emulados de diferentes formas, en particular *sub-agentes* y *skills*: |
| 38 | + |
| 39 | +| Artefacto | Definición y problemas asociados | |
| 40 | +| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 41 | +| `modelo` | Los modelos son entrenados, reforzados, destilados, fine tuneados, etc y entre sus capacidades como *generalistas* está desarrollar software en sus diferentes dimensiones; **pero todo este proceso sigue siendo limitado, sujeto a sesgos y a una fecha de corte para su conocimien | |
| 42 | +| `AGENTS.md` | `CLAUDE.md` o `WHATEVER.md` se mantienen como un estándar para dar instrucciones específicas a los asistentes en la dirección en que nosotros creemos que es la mejor forma de desarrollar software; **pero es un solo archivo, tiende a volverse monolítico, y no es contextual a diferentes tipos de | |
| 43 | +| `dir/AGENTS.md` | Ofreció una primera aproximación a *contextualizar* las instrucciones para el asistente en base a la jerarquía de directorios; **el problema es que la organización de los archivos no necesariamente hace match con las diferentes tareas, y la lectura de estos archivos no es deter | |
| 44 | +| `/commands` | Son prompts almacenados por ser frecuentemente utilizados y que invocamos de forma explícita mediando un atajo `/nombre-del-comando`, nos ahorran repetir instrucciones y pueden ser orientados a la tarea; **sin embargo somos nosotros quienes tenemos que | |
| 45 | +| `SKILL.md` | Hasta donde sé son únicos a Claude Code, y permiten dar acceso al asistente a un sistema estructurado de conocimientos bajo el principio de "*progressive disclosure*" aka diferentes niveles de profundidad; **suena bonito, es potente y muy lejos de ser triviales de c De nuevo un feature único a Claude Code, creo, permite *que el agente en el main-thread* **delegue** *tareas específicas* a diferentes agentes con sus propios contextos aislados; **permite una ejecución autónoma pero agrega la complejidad de la *orquestración*, al esfuerzo de definir los agentes y mantenerlos.*** s.* ** s.* ** s * ** | |
| 46 | + |
| 47 | +Esto nos da una visión mucho más granular del sistema de contexto on-demand en el que se apoya un asistente, y nos revela un nuevo nivel de complejidad en nuestro objetivo de *generar* software de calidad de una forma repetible y mejorable en el tiempo. |
| 48 | + |
| 49 | +Esto sucede porque el desarrollo de software implica una diversidad de tareas en diferentes contextos, arquitectura, diseño, QA, etc, "programar" es una simplificación muy básica de lo que significa desarrollo de software. Todos estos artefactos mencionados anteriormente obedecen a diferentes estrategias para construir una aproximación a este proceso complejo de transformar una idea en algo que le da valor a los usuarios. |
| 50 | +## La nueva tarea |
| 51 | + |
| 52 | +Entonces nuestro trabajo no solo consiste en determinar cuál es la mejor combinación de instrucciones, ejemplos, "textos", distribuidos entre los diferentes artefactos, que alimentan el **contexto** para que el proceso de inferencia tienda a generar **alucinaciones positivas**; sino que adicionalmente nos enfrentamos al desafío de refinar este sub-sistema para mantenerlo alineado con el código y que cada vez sea más eficiente. |
| 53 | + |
| 54 | +El primer caso es obvio, pero el segundo no tanto, aquí un ejemplo sencillo: Actualizamos de una forma *significativa* una dependencia en nuestro proyecto, y si no actualizamos los artefactos de soporte para el asistente entonces el código generado, las alucinaciones, van a sufrir un bias hacia la versión de la librería que teníamos en el pasado introduciendo errores ([alucinaciones negativas](/2025/10/20/la-alucinacion-es-el-feature-fundamental-de-los-llms)). |
| 55 | + |
| 56 | +## Revisemos el valor de la alucinaciones |
| 57 | + |
| 58 | +Vamos a crear una nueva versión de la "fórmula" del valor de las interacciones con el asistente que introdujimos en Las matemáticas del Código Asistido por IA donde `v(i(ap,e,p))` representa: |
| 59 | + |
| 60 | +- El valor (*v*) que nos da... |
| 61 | +- Una interacción (*i*)... |
| 62 | +- Con un asistente de programación (*ap*)... |
| 63 | +- En nuestro entorno (*e*)... |
| 64 | +- Con el prompt (*p*) |
| 65 | + |
| 66 | + Y es igual a: |
| 67 | + |
| 68 | + - El valor (*v*)... |
| 69 | + - Del entorno anterior (*e*)... |
| 70 | + - Más el valor de la suma del valor todas alucinaciones positivas v(∑a₊)... |
| 71 | + - Menos la suma del valor de todas las alucinaciones negativas `v(∑a₋)` |
| 72 | + - Menos el **costo** (*k*) de detectar y rechazar las alucinaciones negativas `k(∑a₋)` |
| 73 | + |
| 74 | +Es decir: |
| 75 | + |
| 76 | +``` |
| 77 | +v(i(ap,e,p)) = v(e) + v(∑a₊) - v(∑a₋) - k(∑a₋) |
| 78 | +``` |
| 79 | + |
| 80 | +**Pero** ya descubrimos que el steering *no es gratuito*, que implica mantener un sub-sistema nuevo, por lo tanto podemos decir que: |
| 81 | + |
| 82 | +``` |
| 83 | +v(f(ap,e,p)) = v(e) + v(∑a₊) - k(∑a₊) - v(∑a₋) - k(∑a₋) |
| 84 | +``` |
| 85 | + |
| 86 | +Donde `- k(∑a₊)` es el costo (negativo) de "*promover*" esas alucinaciones positivas, que llamamos *steering* y que acabamos de entender que tiene un costo no-trivial. De nuevo, esto no pretende ser una formulación matemática sino un mecanismo que nos ayude a sistematizar nuestra aproximación a estas herramientas. |
| 87 | + |
| 88 | +## En conclusión |
| 89 | + |
| 90 | +No hay **una** solución buena para esto, siempre hay un tradeoff, y en los extremos está la persona que ignora por completo los artefactos y que prompt a prompt revisa el resultado y acepta o rechaza las alucinaciones; y en el otro extremo está la persona que se dedica a componer los diferentes artefactos para maximizar al autonomía y eficiencia del sistema. |
| 91 | + |
| 92 | +Como después de muchísimos años como manager aún estoy lejos de ser programador, yo le estoy apostando a la segunda, que es bastante más compleja y cuyo ROI aún están por verse. |
| 93 | + |
| 94 | +En el próxima entrega vamos a enfocarnos en entender qué significa detectar y rechazar las alucinaciones negativas (`- k(∑a₊)`) a lo que a mi me gusta llamar **backpressure**. |
0 commit comments