Cómo formular prompts a ChatGPT para programar

Formula prompts a ChatGPT para programar describiendo la decisión de ingeniería, no solo el código que quieres que devuelva. Proporciónale el código o contexto del repositorio que sea relevante, el comportamiento que debe conservar, un resultado concreto y una forma de verificar el resultado.

“Escribe una función que haga X” puede bastar para una pequeña utilidad. No basta cuando un cambio afecta al comportamiento de los usuarios, a un contrato compartido o a un sistema de producción.

Antes de pedir código, indica cuatro cosas:

• Qué existe ahora: el componente, la función, la API o el fallo relevantes.
• Qué debe cambiar: un resultado visible para el usuario o para el sistema.
• Qué no debe cambiar: compatibilidad, rendimiento, accesibilidad, contratos o APIs públicas.
• Cómo comprobarlo: pruebas, pasos de reproducción, comprobaciones de tipos o criterios de aceptación manuales.

Si usas un espacio de trabajo de ChatGPT de larga duración, conserva juntas las notas de arquitectura, los requisitos y los archivos relevantes. Los Proyectos de ChatGPT pueden organizar chats, archivos de referencia e instrucciones específicas del proyecto; revisa los controles de tu plan y espacio de trabajo actuales antes de subir material fuente.

Evita esto:

Crea un componente para subir archivos.

No define la responsabilidad, el manejo de errores, los límites de archivos, la accesibilidad ni el contrato de la interfaz de usuario circundante.

Usa una solicitud delimitada en su lugar:

Tenemos una página de configuración de React que ya controla el envío del
formulario y los mensajes de error. Añade un cargador de archivos al formulario
existente.

Resultado: Una persona usuaria puede seleccionar un PNG o JPEG de menos de 5 MB,
ver el nombre de archivo seleccionado, eliminarlo antes de enviar el formulario
y recibir el mensaje de error localizado existente para archivos no válidos.

Restricciones: No añadas una nueva biblioteca de estado, no crees un endpoint de
subida y conserva el controlador de envío actual como único propietario del
estado del formulario.

Devuelve el conjunto más pequeño de archivos modificados, explica cada cambio e
incluye pruebas para tipo no válido, límite de tamaño, eliminación y selección
correcta.

La solicitud hace que el componente sea más pequeño porque descarta una arquitectura innecesaria.

Para depurar, pide una hipótesis y una ruta de reproducción antes de pedir un parche:

Síntoma: El botón Guardar permanece deshabilitado después de que se complete
correctamente un reintento de API.

Comportamiento esperado: El botón queda disponible después del reintento
correcto.
Comportamiento observado: Aparecen los datos de respuesta, pero el botón sigue
deshabilitado.

Contexto relevante: El botón depende de isPending y form.isDirty. Esto comenzó
después de añadir reintentos al hook de mutación.

Primero, enumera las transiciones de estado más probables y la evidencia
necesaria para confirmar cada una. Después, propone la corrección más pequeña y
la prueba de regresión.

Esto es más seguro que “corrige el botón deshabilitado” porque pide a ChatGPT que distinga un error de estado obsoleto de un problema de validación o de renderizado de la interfaz de usuario.

Las solicitudes de refactorización necesitan una cláusula de conservación más sólida:

Refactoriza la lista de tarjetas de precios para eliminar la lógica duplicada de
renderizado de planes.

Conserva: props públicos, nombres de eventos de analítica, destinos de checkout,
comportamiento de teclado, estados de carga y el diseño móvil existente.

Alcance: Limita los cambios a la funcionalidad de precios y sus pruebas
directamente relacionadas. No introduzcas una abstracción de sistema de diseño a
menos que el componente existente no pueda expresar el comportamiento compartido.

Criterios de aceptación: Las pruebas de snapshot o interacción cubren cada estado
del plan, y los enlaces renderizados y las cargas de eventos permanecen sin
cambios.

Antes de editar, identifica la duplicación y cualquier comportamiento oculto que
las dos tarjetas implementen actualmente de forma distinta.

La frase “conserva el comportamiento” no basta por sí sola. Nombra el comportamiento que importa.

No pidas “pruebas para este componente” sin un contrato. Nombra los escenarios:

Escribe pruebas para el formulario de restablecimiento de contraseña usando la
infraestructura de pruebas existente.

Cubre:
1. un correo electrónico no válido muestra el mensaje de validación localizado;
2. al enviar se manda el correo electrónico normalizado una vez;
3. un error de red conserva el valor introducido y muestra el estado de error
   existente;
4. una respuesta correcta anuncia la confirmación sin revelar si existe una
   cuenta.

No simules detalles de implementación. Prefiere roles y etiquetas accesibles.

Esto le indica al asistente qué debe poder hacer el usuario y qué comportamiento de privacidad no puede sufrir una regresión.

Un prompt de explicación debe solicitar un recorrido de evidencia, no un resumen:

Explica cómo llega el estado de autenticación a la pantalla de facturación en
este repositorio.

Sigue el recorrido desde el proveedor hasta el protector de rutas y la llamada
de checkout. Nombra los archivos y símbolos exportados implicados. Separa el
comportamiento confirmado de los supuestos e indica qué inspeccionarías después
si alguna parte no está clara.

Ese formato facilita detectar una dependencia ausente o una conexión inventada.

ChatGPT es más fiable cuando le das el contexto más acotado que responde a la pregunta:

• una prueba que falla junto con el código que ejercita;
• el componente y el hook que controla su estado;
• un ejemplo de solicitud/respuesta con los valores sensibles eliminados;
• las convenciones del proyecto que restringen el cambio;
• una lista breve de archivos que están intencionalmente fuera de alcance.

No subas secretos, tokens de acceso de producción, datos de clientes ni registros privados que no tengas permiso para compartir. Sustituye esos valores por redacciones realistas y conserva el comportamiento que necesitas analizar.

Para el marco general que sustenta estos prompts, lee cómo escribir mejores prompts para IA. Para un conjunto de patrones de implementación y revisión basado en roles, continúa con ingeniería de prompts para desarrolladores. Usa ejemplos de ingeniería de prompts para ingenieros de software cuando quieras ver una solicitud trabajada antes y después, y usa las plantillas de prompts para depurar problemas de producción antes de investigar una incidencia en producción.

El código generado es una propuesta. Ejecuta las pruebas pertinentes, inspecciona el diff y prueba tú mismo la ruta afectada. Cuando el trabajo implique salida de comandos, errores o scripts de shell, reproducir el flujo de trabajo forma parte de la validación, no es un extra opcional. Usa el área de práctica de línea de comandos en el navegador para adquirir ese hábito con entradas de comandos y comentarios reales.