1. Empezar por el proceso, no por la herramienta
Elijo una actividad que conozco bien y que repito. Los datos deben ser suficientemente estables, las reglas explicables y el resultado controlable. No empiezo por el proceso más complejo: empiezo por uno que pueda comparar con un working paper o resultado histórico ya fiable.
- Se repite mensual, trimestral o anualmente.
- Los datos tienen una estructura reconocible o pueden normalizarse.
- Las reglas ordinarias y las principales excepciones pueden escribirse.
- Existen cuadres o resultados históricos con los que verificar el output.
2. Asignar un papel a cada entorno
No hace falta conocer todos los modelos. Lo importante es separar diseño, desarrollo, memoria y control. Un entorno puede ayudar a estructurar el proceso y el brief; otro puede escribir el código; una base documental conserva fuentes, mappings, decisiones y pruebas; una conversación nueva realiza la revisión.
3. Enseñar el proceso antes de pedir código
La primera petición no debería ser «escribe el programa». Primero describo el objetivo, aporto datos reales, explico columnas, signos y líneas que deben ignorarse, escribo reglas y excepciones y defino resultados y controles. Después pido al modelo que devuelva un brief completo e indique qué no está claro.
- Si falta un dato esencial, la herramienta debe detenerse y señalarlo.
- Las decisiones profesionales no deben quedar implícitas en el prompt.
- El brief se aprueba antes de iniciar el desarrollo.
4. Definir las pruebas antes del prototipo
Una aplicación no es correcta solo porque produzca un número. Antes del desarrollo preparo casos y resultados esperados. Después intento deliberadamente hacerla fallar. Los criterios PASS o FAIL se definen de antemano para no adaptarlos al resultado obtenido.
- Caso ordinario con resultado verificado manualmente.
- Caso límite con signos invertidos, cuentas nuevas o saldos cero.
- Input erróneo: columnas ausentes, formato incorrecto o datos incoherentes.
- Comparación con el resultado esperado preparado antes del prototipo.
5. Desarrollar en versiones pequeñas
La primera versión debe hacer pocas cosas y hacerlas verificables. Una función cada vez, datos reales y changelog. La complejidad se añade solo cuando la versión anterior es estable y las pruebas de regresión siguen superándose.
6. Separar producción y revisión
La misma conversación que construyó la herramienta no debería certificarla. Abro una conversación nueva y aporto el código, el brief y la matriz de pruebas, pero no la historia del desarrollo. Le pido que busque errores, supuestos no respaldados y casos no gestionados, devolviendo PASS o FAIL, motivación, evidencia y corrección para cada control.
7. Publicar con límites, manual y memoria
La publicación no coincide con el final del código. Se necesita un manual de uso, un changelog, la descripción de los datos aceptados, los controles realizados, los supuestos abiertos y los límites de la herramienta. El profesional debe entender no solo cómo usarla, sino también cuándo no usarla.