Programar describiendo lo que quieres funciona. Esa es la parte que se salta todo el que discute sobre el tema. Describes algo, el modelo lo escribe, lo ejecutas, y existe una cosa que hace una hora no existía.
Donde deja de funcionar es concreto y merece nombre, porque el fallo no es «el código está mal». El código suele estar bien. El fallo es que ya no sabes qué hay dentro, y cada cambio nuevo hay que describírselo a un modelo que tampoco lo sabe, porque la descripción del sistema no vive en ningún sitio.
La forma del muro
Va así. Los diez primeros cambios son rápidos. Hacia el quince se rompe algo que no tocaste. Describes el fallo, el modelo lo arregla, se rompe otra cosa. Describes esa. Por el cambio veinticinco pasas más tiempo explicando el estado actual de la aplicación que describiendo lo que quieres, y el modelo gasta más tokens releyendo ficheros para deducir qué hicieron las sesiones anteriores.
No ha fallado nada. Simplemente has cruzado el punto en el que el sistema es más grande que lo que cabe en la cabeza de cualquiera de los dos, y ninguno lo escribió.
Cuatro hábitos alejan ese muro bastante. Ninguno exige que te conviertas en programador.
1. Que funcione, y luego que se quede
El hábito de mayor valor: cuando algo funcione, déjalo en un estado al que puedas volver.
Un commit. Una copia de la carpeta. Un fichero duplicado. Lo que vayas a hacer de verdad. El mecanismo importa menos que tener uno, porque la alternativa es que cada sesión ponga en riesgo lo que ya funcionaba.
Con un agente esto pesa más que sin él: un agente edita varios ficheros a la vez, así que cuando un cambio sale mal, sale mal repartido por el proyecto, y «deshacer» no es una tecla. Codoro deja las ediciones detrás de un diff que apruebas y tiene deshacer optimista, lo cual ayuda dentro de una sesión. No te devuelve al martes.
2. Pide el plan antes de la edición
Dos tercios de las sesiones caras empiezan con una tarea que el modelo entendió distinto que tú.
Pregúntale qué va a hacer. Léelo. Corrige la parte que está mal. Después déjale escribir.
Cuesta un turno barato y ahorra diez caros de forma rutinaria, porque un plan con el que no estás de acuerdo se detecta antes de que exista código en lugar de después de revisar un diff construido sobre él. Además te deja algo contra lo que contrastar el resultado: puedes ver si el cambio se parece al plan sin leer cada línea.
3. Di qué no debe tocar
Los modelos son serviciales de una forma que a veces destruye cosas. Si le pides que arregle el formulario de registro, encantado te ordena también el CSS, renombra una variable que le parecía confusa y actualiza tres ficheros sin relación que leyó de paso.
Acótalo: «cambia solo el formulario de registro; no toques nada más». Y luego mira qué ficheros aparecen en el diff antes de aprobarlo. Si hay uno que no esperabas, esa es la señal completa: no hace falta leer el cambio para saber que algo se torció.
4. Ten un fichero que diga qué es esto
Un fichero de texto. Qué hace la aplicación, cuáles son las piezas principales, qué has decidido no hacer, qué está roto ahora mismo.
Es el que más aleja el muro, porque es el artefacto que falta. Cada sesión empieza deduciendo el contexto a partir del código. Un fichero que lo declare hace que el modelo lea un párrafo en vez de ocho ficheros: más barato, más rápido y con más probabilidad de acertar, porque un párrafo escrito por ti describe tu intención mejor que el código.
Codoro lee reglas acotadas de .codoro/rules/*.md, que es la versión formal de la misma idea. Un
fichero de texto en la raíz funciona casi igual de bien.
A dónde se va el dinero
Conviene entenderlo, porque la factura es lo que hace que la gente lo deje.
Cada turno reenvía toda la conversación acumulada como entrada. El turno doce lleva dentro los once anteriores: los ficheros leídos, los diffs propuestos, los resultados de las herramientas, todo. Una sesión larga no es lineal, es una curva, y una tarea que se descontrola es el suceso caro.
Por eso los hábitos de arriba son también controles de coste. Un plan acordado en un turno barato evita diez caros. Una tarea acotada lee menos ficheros. Un fichero de contexto sustituye a una fase de exploración entera.
En concreto: pon un tope por ejecución. En Codoro son 2,00 $ por tarea por defecto, editable, con un respaldo de 25,00 $ al día. Ponlo en una cifra que te molestaría alcanzar —un tope por encima de tu peor caso no ha saltado nunca y no protege nada. Cuando salta, la ejecución se pausa y ofrece un modelo más barato en lugar de cambiarlo en silencio, así que decides tú.
Si ya tienes una clave de algún proveedor, úsala: el recargo es del 0 %, la clave se queda en el llavero de macOS y los topes siguen aplicando. El crédito alojado lleva un 40 % sobre coste, que paga tener una sola factura y ninguna clave que gestionar, y nada más.
El límite honesto
Nada de esto te permite arreglar lo que no puedes leer. Llega un punto en que una aplicación necesita a alguien que la entienda, y los hábitos de arriba te compran tiempo y una entrega mejor, no inmunidad.
Lo que sí evitan de forma fiable es llegar a ese punto sin idea de cómo llegaste, que es la diferencia entre «esto ya necesita un programador» y «esto necesita un programador y nadie sabe explicarle qué hace».
Estado
Codoro está en vista previa para macOS. Todavía no hay descarga pública: la página es una lista de espera hasta que exista una release firmada. Todo lo de arriba vale para cualquier editor con agentes; los topes, el diff aprobado y las reglas acotadas son cómo lo hace Codoro en concreto.