Como ya llevaba rato sin escribir en el blog, el otro día un compañero de PHP México preguntó cómo podría ser más eficiente a la hora de trabajar con la IA y pues tras un año de trabajar con ella aquí les comparto algunos tips de cómo usarla (que en mi opinión y experiencia) me han ayudado bastante.
Lo primero es saber qué tanto uso podemos darle, como sabrán, la IA no es barata y muchas empresas empezaron ahora sí a limitarnos en cantidad de $ que podemos usar para pagar la IA… entonces hay que intentar ser lo más eficientes posibles. Entonces empecemos por ahí.
Mi primer recomendación o tip es trabajar con algunas skills que reducen el output como Caveman para reducir el consumo de tokens, e implementar Skills que nos permitan decirle a la IA «hey, no hagas X o Y cosa», por ejemplo, muchas veces la IA para verificar sus cambios hace rondines de validación, ¿qué es esto?, que ejecuta eslint en JavaScript por ejemplo, o que ejecuta el build, el problema con el build por ejemplo es que luego da muchísima salida que considera la IA como parte de sus procesos y nos termina costando (no solo tiempo incluso hasta dinero dado que pues nos va diciendo «Ahora voy a ejecutar el build» más allá del thinking)
Entonces para reducir todos estos consumos skills ligeras pueden ayudarnos para reducir y algunos plugins, ahora también presta mucha atención en lo que conoces y no conoces de un proyecto porque es ahí donde vas a necesitar hacer preguntas básicas para encontrar X cosa que bien pudiste haber hecho con el simple filtro del IDE, por lo que mi recomendación es que cada vez que trabajes con un proyecto no tan grande o hasta grandes pero en un feature que vaya a ser general te tomes un tiempo para generar una «nota» (o un markdown o algo que te sirva de referencia y a la IA) y quemes algunos tokens inicialmente para que la IA genere un documento de contexto, este documento será el que le dirá a la IA «aquí está todo lo relacionado a A, acá lo relacionado a B, aquí podría ser que ocupes estos valores, aquí estánalgunas keys o cosas que se ocupen» y así sucesivamente, esta será una pasada un poco pesada pero después, podrás usarla para decirle a la IA «usa esto como referencia» y así si inicias nuevas conversaciones para diferentes tickets o lo que quieras, ese contexto base ya existe y la IA ya no ocupa hacer varias pasadas.
Ahora, de aquí vamos a cómo es mi flujo de características y primero viene la pregunta que yo me hago: «¿Tengo idea de lo que estoy haciendo?» porque por ejemplo en mi caso no soy un pitonizo (desarrollador de Python) así que no conozco mucho del lenguaje, si a eso le sumo que trabajo con muchas cosas que desconozco estoy «en 0» y debo gastar tokens para tener más entendimiento… pero de ahí, si ya sabes lo que estás haciendo te puedes ahorrar tiempo y dinero… es por eso que, si la respuesta es «Sí, tengo idea», entonces nos saltamos este paso, pero si la respuesta es «No…» aquí es donde empezamos.
Sabemos que ya tenemos un contexto, la IA ya sabe qué queremos construir gracias al archivo contextual que le solicitamos generar, pero aquí es donde vamos a hacerle la primera pregunta de cuándo no sabemos qué hacemos… «Explícame más a profundidad los pasos que debemos hacer y todos los cambios que podrían ocuparse para generar X característica, recuerda considerar el archivo de contexto [x.md] para referencias» y aunque este paso nos hará gastar $$$ y tiempo, sí, humanamente podremos leer más apropiadamente y entender más a profundidad, porque, recordemos, el contexto que generó la IA es para ella, no para nosotros.
Ya que entendemos (de preferencia mi recomendación es que las salidas le pidas que te las dé algo resumidas para que tampoco te abrumes con tanta información y en un Markdown, para que sea más fácil de leer que en su ventana de chat y que luego te mete demasiadas cosas que es complejo y toma mucho luego leer sus salidas y en «markdowns» tiende a ser más fácil), vamos ahora sí al siguiente paso que es el planing, ponemos la IA en modo Planning (el paso anterior puede ser en modo Ask/Agent pero, en general el modo ask al no modificar archivos no te genera el Markdown que te comento entonces, si no lo hace puedes hacerlo tu con copy/paste o dejarlo en modo agente, solo en modo agente asegúrate de darle la instrucción de que no genere nada más que dicho markdown). En este paso de Planning lo que haremos es que le digas a la IA que genere un plan con el contexto para la característica que vamos a trabajar (o tarea o cosas así, en bugs no te recomiendo este proceso porque puede ser más extenso, en modo de bugs es más rápido pasarle un prompt directo comentándole que hay un error y hay que repararlo).
En este paso, asegúrate de que el modo planning a través de tu prompt haga cambios pequeños, graduales, con el tipo «Cada paso de la planeación deberá hacer cambios que pueda ir comprobando fácilmente y que pueda leer para asegurarnos de que el código está correctamente escrito». Además, te recomiendo también decirle al modo agente dado que ahora los IDEs/CLIs y demás te pueden hacer preguntas y esperarte, que le anexes un paso donde «Antes de pasar al siguiente paso, asegúrate de preguntarme si está todo correcto o debemos hacer algún ajuste» para que de esta manera el agente se «atore» y no avance paso a paso haciendo todo «como loco»… incluso en mi caso, a veces hace cambios fuera del contexto por alguna razón y pues es mejor irla «regañando».
De esta manera podrás ir avanzando, inclusive podrás ir generando commits ya sea manualmente o también irle dando las instrucciones a la IA para que suba los commits una vez tú lo valides y entonces avance al siguiente paso. Otra recomendación para esto es que le digas que agregue un paso para pruebas manuales (o sea que directamente tú harás) y automatizadas (o sea unit test, E2E o así) y en estos pasos, primero tú corroboras y después la IA asigna las nuevas pruebas. Cabe mencionar aquí, que muchas veces se hacen modificaciones a las pruebas unitarias para que dichas pruebas se ajusten a los cambios que hiciste, también es un buen paso asegurarte a través de tu planeación, que en dicho paso, no haga ajustes que no debería, incluso algún skill que nos aporte valor a esto porque a veces la IA dice «yo hice un cambio aquí y debo adaptar ese test porque ya no funciona» pero en realidad fue porque introdujo un error no porque en realidad así sea lo correcto.
Otro detalle que te recomiendo considerar en esta fase, como en la de ask, es que generes un Markdown que te sirva como guía, que te agregue todo como un «TODO» (o sea los pasos que hará) y que te anexe pequeños contextos que te vayan sirviendo como guía, todo esto ojo, si es que no tenemos problema con las tokens… si sí, entonces quizá no valga tanto la pena…
Una vez que termines todo, con tu planeación, si es que tienes una segunda IA (más allá que tu Pull Request tenga procesos en los pipelines que te verifique otra IA tu código) te recomiendo ejecutar con esta segunda IA una revisión pidiéndole que te valide los cambios encontrando (o intentando al menos) problemas graves, críticos, que te haga un resumen (otra vez yo prefiero Markdown, así que casi siempre le pido así la salida) y ya podrás verificar, si después tienes algún sistema tipo Cursor, Coderabbit o algo por el estilo que te re-revise y es algo que esta pasada de verificación no cachó podrás corregir.
Y esto termina, en mi experiencia y opinión nuevamente, en mejor código, menos errores, mejores validaciones, aunque, eso sí, más gasto de tokens…
Por último y no menos importante, un último tip que te doy es que los prompts enormes y «súper cuidados» son poco funcionales, es mejor que hagas prompts pequeños para cambios pequeños y que como digo, uses la planeación y las preguntas para llegar a un buen punto, porque el prompt «enorme» se verá muy mono pero podría terminar en la IA descontrolándose y terminar con muchísimas líneas cambiadas o cosas que no fueron relevantes porque «se me olvidó agregarle esto, aquello, acuquello al prompt»…
Espero te sirvan estos tips, ¡hasta la próxima!
