Empezar por lo que alguien necesita resolver
Uso herramientas de IA en el desarrollo. Para orientar el trabajo, parto de los requisitos y de la forma en que está construido el proyecto. Me interesa poder explicar qué necesita cambiar y por qué le importa a quien lo va a usar. Con esa idea clara es más fácil pedir ayuda y reconocer si la propuesta responde al problema.
Imagina un formulario de reservas que permite elegir una fecha que ya pasó. La persona puede completar sus datos y descubrir demasiado tarde que no podrá reservar. Antes de pedir código, describiría qué debería poder elegir, qué mensaje necesita ver y qué zona horaria usa el negocio.
Después revisaría dónde debe cumplirse esa regla. Cambiar el calendario de la pantalla puede ser parte de la solución, pero aún hay que revisar qué acepta el servidor y qué pasa si la reserva llega por una API o un panel interno. Seguir la necesidad de la persona me ayuda a ver lo que falta.
Compartir el contexto que ayuda
Para trabajar sobre ese formulario, compartiría los archivos relacionados y las convenciones del proyecto. Si ya existe una validación parecida, empezaría por ahí. Aprovechar algo que el equipo conoce puede hacer más sencillo el cambio para quien tenga que mantenerlo después.
También acordaría qué puede hacer la herramienta: proponer un cambio, probarlo en un entorno local o desplegarlo son acciones diferentes. No hace falta darle acceso a todo para resolver una tarea pequeña. Con los datos reales y las credenciales, seguiría las reglas del proyecto y compartiría solo lo necesario y permitido.
Tomarse el tiempo de entender la propuesta
La propia documentación de GitHub señala que las sugerencias de Copilot pueden ser incorrectas o no reflejar lo que quería el desarrollador. Recomienda revisar el código, probarlo y comprobar que encaja en el proyecto. Conviene tenerlo presente cuando una respuesta parece convincente a primera vista.GitHub: limitaciones y uso responsable de sugerencias de código ↗
Al leer la propuesta, volvería al formulario del ejemplo: ¿impide reservar una fecha pasada donde corresponde? ¿Qué ocurre si falta un dato? ¿El mensaje ayuda a corregirlo? Si una parte no se entiende, vale la pena detenerse y pedir una explicación. Entender el cambio forma parte de poder hacerse cargo de él.
Mantendría esa revisión centrada en la fecha. Reorganizar todo el formulario o cambiar sus estilos puede esperar a otra tarea. Un cambio pequeño permite seguir mejor las decisiones y deja más espacio para que otra persona lo revise con atención.
Probar pensando en quien está frente a la pantalla
En el ejemplo, probaría una fecha válida, una pasada y lo que ocurre cerca de medianoche en la zona horaria del negocio. También intentaría equivocarme y corregir la selección. Quiero saber si la persona puede continuar sin perderse, además de comprobar que el código hace lo esperado.
Al compartir el resultado, diría qué comprobé y qué falta revisar. Que la aplicación compile es un paso; todavía hay que recorrer el formulario. Una prueba local con datos ficticios tampoco cuenta lo que ocurre con un proveedor real en producción. Explicar esas diferencias permite al equipo decidir el siguiente paso con más claridad.
Dejarle un buen punto de partida a quien sigue
Al cerrar la tarea, dejaría una nota breve: qué problema había, qué cambié y cómo lo probé. Si hubo una decisión importante, explicaría el motivo. La próxima persona que abra ese código no debería necesitar toda la conversación para poder continuar. Esa persona también puede ser uno mismo dentro de unos meses.
Me interesa trabajar con IA de una forma que deje espacio para comprender y aprender. Avanzar tiene valor, y también lo tiene poder explicar lo que entrego. Cuando alguien use el producto, confiará en que me tomé el tiempo de cuidarlo. Esa responsabilidad sigue siendo mía.