Lo que le doy a la IA antes de dejarla escribir

Casi todo lo que leo sobre programar con IA va de cómo pedirle las cosas. En mi experiencia el trabajo no está ahí. Está en lo que le pones delante antes de que escriba la primera línea.

Lo que decido yo

Cómo quiero trabajar, la arquitectura y la base las decido yo. No las discuto con la herramienta, porque no son decisiones de implementación: son las que determinan qué se puede construir encima y qué no.

El dominio también sale de mí, y ahí el motivo es otro. Las reglas de lo que hace el sistema son negocio, y no están en ningún sitio del que la IA pueda sacarlas. Están en las conversaciones a las que voy yo.

De la idea a la tarea

Antes de que haya ningún spec hay una conversación. Le cuento que quiero hacer una cosa y la trabajo con ella hasta que deja de ser una idea y se convierte en tareas concretas, con su alcance y su motivo, que acaban en Jira.

Esa parte la tengo apoyada en skills, para que el resultado salga siempre con la misma forma en lugar de depender de cómo lo cuente yo ese día.

Esas tareas son las mismas que coge el equipo. Por eso esta fase no es una manía mía de productividad: es donde se decide qué van a construir ellos, y con cuánta ambigüedad encima.

Solo cuando una tarea está así de aterrizada empiezo con el spec. Los escribo, los reviso, los corrijo, y hasta que esa fase no está bien no la dejo implementar.

Ahí es donde meto la mayor parte del esfuerzo, y es deliberado. Un spec flojo no se arregla con instrucciones posteriores, porque para entonces el problema ya está dentro del código.

Por qué insisto tanto en esa primera fase

Lo que más me ha tocado deshacer son cosas mal colocadas. Una query metida donde solo debería haber reglas de negocio. Lógica de negocio que acaba en el controlador en vez de en el sitio que le tocaba.

Eso lo pillo revisando el código, que es donde se pilla. Pero cuando se me ha colado, el motivo ha sido casi siempre el mismo: demasiado código de golpe.

Ahí está la trampa de trabajar así. La velocidad a la que sale el código no cambia la velocidad a la que puedo revisarlo yo, y cuando la entrega es grande la revisión se vuelve más superficial sin que te enteres. La herramienta no te engaña: le pides demasiado de una vez y acabas mirando con menos detalle del que hacía falta.

Por eso el spec importa más de lo que parece a primera vista. Uno bien acotado no solo dice qué construir. También decide cuánto llega de una vez, que es lo que determina si vas a poder revisarlo de verdad.

Cómo compruebo que ha respetado los límites

La arquitectura ya dice dónde va cada cosa, así que la comprobación es concreta: miro si lo ha puesto donde tocaba. Eso lo reviso siempre, y los tests hacen el resto.

No es una revisión de gusto ni de estilo. Es mirar si una pieza está en su capa o se ha colado en otra, y eso tiene respuesta de sí o no. Por eso me interesa dejar la arquitectura decidida antes: convierte la revisión en algo que se puede comprobar en vez de opinar.

Cuando propone algo mejor que lo mío

Pasa, y no lo descarto por venir de donde viene. Pero tampoco lo acepto sobre la marcha: lo discuto antes de decidir.

La diferencia entre esas dos cosas parece pequeña y se nota mucho con el tiempo. Aceptar propuestas buenas una detrás de otra, sin pararte en ninguna, es la forma más rápida de acabar con un diseño que no eligió nadie del todo. Cada decisión por separado era razonable. El conjunto no lo decidió ninguna persona.

Lo que queda igual

Nada de esto va de una herramienta concreta ni de cómo se llame lo que uses. Va de que alguien tiene que haber decidido la forma antes, porque la IA no elige la forma: rellena la que le pongas, y si no le pones ninguna, rellena la que le salga.

Eso no ha cambiado desde que programo. Lo que ha cambiado es la velocidad a la que se llena el hueco si lo dejas vacío.