Diagnóstico

Ocho cosas que todo el mundo le atribuye al modelo, agrupadas por la disciplina que en realidad falta. Buscá el síntoma que estás viendo. Casi ninguna se arregla cambiando de modelo.

Si cambiaste de modelo tres veces y el problema sigue, el problema no era el modelo.

Memoria

no recuerda nada de ayer

Amnesia entre sesiones

“Ayer decidimos esto y hoy propone lo contrario.”

Por qué pasa

El modelo no aporta memoria durable del proyecto. Un arnés que guarda historial de sesión te da transcripciones de conversaciones, que no es lo mismo que un registro de lo que el proyecto decidió, y además queda atado a ese producto. Al cerrar la terminal, todo lo que resolvieron juntos desaparece si no lo pusiste en algún lado que controles vos: no lo olvidó, nunca lo tuvo.

La reparación

Una capa de memoria que guarde decisiones y las recupere al iniciar. Lo importante no es guardar mucho: es guardar el porqué. Y que sea portable, o la perdés cuando cambies de herramienta.

Contexto

nunca vio tu código

API inventada

“Llamó a una función que no existe en ninguna parte.”

Por qué pasa

El modelo completa el patrón más probable. Si nunca vio tu código, la función más probable es la que tendría sentido que existiera — y suena perfectamente razonable, porque está entrenado para sonar razonable.

La reparación

Mostrale lo que realmente existe: un índice de tu código, y la documentación actual de la versión de librería que tenés instalada. Cambiar a un modelo mejor baja la frecuencia; no toca la causa.

Reinvención

“Escribió un helper que ya existía tres carpetas más allá.”

Por qué pasa

Escribir de cero es lo más barato que puede hacer el agente. Encontrar lo que ya existe requiere buscar, y buscar sin un mapa del código es caro e incompleto.

La reparación

Hacer que encontrar salga más barato que escribir. Un índice de símbolos consultable convierte “¿existe algo así?” en una consulta en vez de una expedición.

Estándares

no sabe cómo trabajan acá

Dos features, dos estilos

“Cada vez lo resuelve distinto, y ninguna está mal.”

Por qué pasa

El modelo sabe cómo se escribe software en general, no cómo se escribe acá. Si la convención no está escrita en un lugar que lea solo, la reinventa en cada sesión — razonablemente, pero distinto.

La reparación

Escribir las reglas permanentes en el archivo de instrucciones del proyecto y los procedimientos repetidos como algo que se cargue cuando la tarea aparece.

Capacidad

no tiene manos, o tiene demasiadas

Acción irreversible sin aviso

“Corrió un comando destructivo sin preguntar.”

Por qué pasa

El modelo no distingue borrar un archivo temporal de borrar tu rama. Esa distinción la pone el entorno, y si nadie la declaró, no existe.

La reparación

Permisos explícitos y controles deterministas. Todo lo irreversible pasa por una confirmación o por un comando que se ejecuta pase lo que pase.

Método

no tiene proceso

Degradación en tareas largas

“Arrancó bien y a la hora empezó a hacer cualquier cosa.”

Por qué pasa

A medida que la ventana se llena, la señal se diluye: la instrucción del principio compite con doscientas líneas de salida de tests. Ventanas más grandes corren el problema de lugar, no lo eliminan.

La reparación

Sacar el trabajo ruidoso del hilo principal y cortar la tarea en fases con entregables en el medio. Que la exploración la haga un agente aparte y devuelva solo la conclusión.

Control

nadie lo revisa de verdad

Complacencia

“Le digo que se equivocó y me da la razón aunque yo esté mal.”

Por qué pasa

El entrenamiento premia respuestas que a la gente le gustan, y a la gente le gusta tener razón. El resultado es un revisor que valida en vez de revisar, e inservible como control de su propio trabajo.

La reparación

Separar quién escribe de quién juzga, y darle al que juzga un criterio explícito en vez de pedirle una opinión. Dos revisores que no ven la conclusión del otro es una defensa real.

Tests huecos

“Todo en verde y la funcionalidad no anda.”

Por qué pasa

Si pedís los tests después de escribir el código, el agente escribe tests que pasan. Es literalmente lo que pediste. Un test moldeado para que el código existente pase no te dice que el comportamiento está: te dice que el código y el test se dan la razón entre ellos.

La reparación

Invertir el orden. El test primero, viéndolo fallar, y recién después el código. Sobre comportamiento nuevo, un test que nunca se puso en rojo no probó nada: solo probó que corre.