Integrando AI al desarrollo

La IA te acelera mucho en analisis, prototipado y documentacion. Permite cambiar el foco cognitivo, podes pasar muchisimo menos tiempo escribiendo codigo y tenemos mas tiempo para pensar en que caminos elegir a la hora de implementar una nueva solucion. El problema arranca cuando usamos el chat como basurero universal: metemos todo junto, mezclamos objetivos y despues nos sorprendemos cuando la salida cae o no corresponde con la solucion que queriamos.

La IA no reemplaza pensamiento tecnico, es una herramienta que debe ayudarnos a potenciarlo. Si no hay claridad de objetivo el modelo rellena huecos con su promedio estadistico y eso casi siempre deriva en ruido, sobreingenieria o soluciones que no se ajustan a lo que realmente necesitamos.

Contexto es todo lo que entra al modelo en cada llamada: instrucciones de sistema, historial, mensajes del usuario, herramientas y resultados previos.

Es clave entender que, el modelo no "memoriza" nada, no tiene memoria persistente entre turnos como la entendemos los humanos, sino que en cada iteracion se le envia el contexto completo de la conversacion.

Cada iteracion es una request nueva. El sistema vuelve a enviar el paquete completo de contexto, por eso el payload crece en cada turno: mas tokens, mas costo y mas chance de ruido.

Si no gestionas esa carga, el modelo no "recuerda mejor" por conversar mas tiempo: solo recibe mas texto acumulado. O sea, no es memoria real, es relectura continua del historial con riesgo de truncacion y perdida de foco o informacion clave.

En chats largos aparecen tres efectos: overflow de ventana, anclaje a errores previos y verbosidad acumulada. Esto no solo baja precision: tambien vuelve inestable la calidad entre corridas.

Otro concepto clave a entender es que, aunque no alcancemos el limite de tokens de entrada del modelo, el mismo empeora drasticamente su funcionamiento mucho antes de llegar, por la acumulacion de ruido.

Si el modelo asumio algo mal temprano y seguimos corrigiendo dentro del mismo hilo, muchas veces queda sesgado por ese estado sucio y cuesta remontarlo. Esto aplica con una mayor intensidad en los casos donde el modelo ya dio una salida como solucion, mas que nada en codigo. Lo que suele ocurrir es que basicamnete si la salida inicial no es la esperada, en vez de crearla de nuevo, tiende a corregirla en vez de generarla nuevamente.

El paper confirma una intuicion de campo: al pasar de single-turn completo a multi-turn subespecificado, cae fuerte el rendimiento promedio. Lo interesante es que la mayor parte de la caida se explica por aumento de no confiabilidad, no solo por perdida de capacidad.

Tambien prueban estrategias de recap/snowball (repetir info) y ayudan parcialmente, pero no igualan el escenario single-turn limpio. O sea: parchea, pero no arregla de raiz.

La mejora mas efectiva y barata: separar conversaciones por objetivo. Un chat para planificar, otro para implementar, otro para revisar. Esto reduce contaminacion cruzada y te deja prompts mas cortos y verificables.

Si el modelo se pierde, en vez de seguir parchando en el mismo hilo, consolidas todo en un prompt limpio y reinicias. En la practica suele rendir mejor que seguir corrigiendo infinito.

Si queremos ir un paso mas alla debemos tener en cuenta algunos otros conceptos. La capa que realmente define consistencia es el agent harness: el sistema de contexto, herramientas y guardrails que rodea al modelo.

Cuando digo harness, hablo literalmente de un arnes operativo: una estructura que sujeta, guia y limita al agente para que no se desvie, igual que un arnes de seguridad evita movimientos peligrosos en trabajo de altura.

La diferencia entre resultados random y resultados repetibles no suele ser el modelo, generalmente va mas por el lado de cuanto contexto util metes en cada iteracion y cuanto ruido dejas afuera.

AGENTS.md funciona como contrato base del repo: arquitectura, convenciones, comandos de verificacion y limites. Las skills son modulos especializados que el agente carga solo cuando toca esa capa (frontend, backend, testing, etc.).

Resultado practico: menos repeticion en prompts, menos desvio de estilo y mas velocidad para entrar en tarea. Es documentacion para humanos y para agentes a la vez.

Un harness solido combina cuatro palancas que se potencian entre si. Si falta una, el sistema funciona, pero pierde estabilidad cuando crece la complejidad.

Si todavia queremos mejorar el rendimiento de los agentes, podemos usar sub-agentes a los que un agente principal (orquestador) delegue tareas especificas.

Que nos permite esto? Basicamente delegamos tokens a un modelo que nace y muere luego de iterar, permitiendonos ahorrarnos esos tokens de planificacion, implementacion y revision

Con un orquestador y subagentes separas roles: uno analiza y planifica, otro ejecuta, otro verifica. Cada subagente nace con contexto limpio y foco acotado, resuelve su tarea y termina.

El orquestador solo conoce lo que solicito y el resultado de cada subagente, sin acumular todo el ruido de las iteraciones intermedias.

Esta arquitectura evita el agente "dios" que acumula todo: tickets, debates, codigo viejo, errores previos y decisiones cruzadas.

El harness define que sabe el agente, pero el feedback loop define cuando puede dar una tarea por cerrada. Si no hay validacion automatica, todo depende de buena voluntad.

Tests, lint, typecheck y builds no son post-proceso: son parte del loop de autocorreccion del agente.

A escala, el desafio no es solo tecnico: es de consistencia entre stacks, versiones y repos heredados. Por eso conviene separar reglas base organizacionales de reglas locales por proyecto.

Base comun para seguridad y calidad, capa local para no romper contextos legacy ni flujos particulares de cada equipo.

No todos los enfoques se comportan igual. La diferencia grande aparece en escalabilidad, consistencia y costo cognitivo.

Esta checklist es la que mas retorno me dio para no romper flujo al trabajar con IA.

El paper mismo marca limitaciones de simulacion. No hay que venderlo como verdad absoluta, sino como evidencia fuerte alineada con experiencia real de uso.

Seguridad y responsabilidad siguen del lado humano: nada de credenciales en prompts y nada a produccion sin revision tecnica seria.