Disciplina en la programación con IA — Por qué importan los prompts estructurados y los Contracts
Configurar la IA correctamente
La programación asistida por IA plantea preguntas reales, a menudo sin respuesta: ¿cómo se configuran la IA y sus Agents individuales para que todo funcione correctamente sin romper el código y la lógica que ya existen? La refactorización nunca debe romper la estructura que ya hay en la base de código.
Lo que más importa a la IA
- Un prompt preciso y detallado: cuanto más claramente se describe un requisito, mejor se ejecuta.
- Dividir el trabajo en pasos más pequeños y granulares, con verificación tras cada uno, da mejores resultados que un único prompt grande.
- Reducir la alucinación: la IA tiende a elegir la opción de sonido más cercano por coincidencia de palabras clave, aunque no corresponda al requisito real.
- Incorporar la lógica de negocio y restricciones explícitas de "lo que no debe romperse" en el prompt produce mejores resultados que un prompt con pruebas unitarias solamente.
- Las pruebas unitarias, de integración y de extremo a extremo existen para confirmar que un cambio dado no rompió funcionalidad fuera del alcance de la propia Task.
Qué añade AITM sobre un Agent de IA estándar
- Contracts, elementos DOM, cadenas de comportamiento y descripciones de lógica de negocio a los que un Agent de IA simple no tiene acceso.
- Las Tasks generadas desde Chat o Brainstorm usan Contracts, documentación y lógica de negocio de comportamiento para localizar rápidamente las partes del código que no deben cambiar, e inyectan la lógica de negocio relevante en el prompt antes de que la IA toque nada, produciendo un prompt adaptado a la IA con una alucinación mínima y la mejor implementación posible.
- Los prompts reciben además Skills y Contracts específicos, lo que permite orientar una Task con precisión hacia patrones de codificación existentes y lógica de negocio existente, mejorando el encaje del cambio con el código actual.
- Cada Task de la Pipeline se genera según su tipo de solicitud (Bug, Enhancement o Feature) y se ejecuta y verifica de forma distinta en la Pipeline para cada tipo, manteniendo una alta calidad del código de forma constante.
- Los requisitos grandes se dividen en Tasks más pequeñas y dependientes que se apoyan unas en otras; la última Task de la cadena verifica que todas se crearon de forma correcta y precisa.
- Los cambios grandes o ilógicos hacen que la Task se detenga, exigiendo que una persona (o un modelo más potente) confirme que el cambio es realmente correcto antes de continuar.
- El paso Architect recopila qué cambiará y dónde, revisa las métricas de cobertura de código y deja por escrito con precisión lo que ocurre; nada más, nada especulativo.