Por qué está escrito así
Cuando le pides a una IA que comente código, tiende a añadir notas en cada línea: encima de total = sum(...) suele escribir "Calcula la suma". Aunque no sea incorrecto, solo repite la sintaxis en lenguaje natural, alargando el archivo sin explicar por qué, por ejemplo, existe un límite del 30%. Este prompt no solo pide comentarios, sino que define dónde y por qué colocarlos.
Incluir un ejemplo contrastado dentro de la instrucción es clave. Decir "haz comentarios útiles" es ambiguo y no cambia el resultado. Al mostrar un mal comentario frente a uno bueno, la IA asimila el estándar de calidad y lo replica con la misma densidad en el resto del bloque.
Se aplican restricciones en dos sentidos: la orden "no cambies ni un solo carácter del código" evita que la IA refactorice variables o simplifique condicionales por su cuenta, facilitando el diff de la revisión. Por su parte, "no comentes línea por línea" previene la saturación, mientras que la sección de "Puntos pendientes de validación" evita que el modelo invente lógica de negocio desconocida.
Especificar el formato por su nombre estándar (JSDoc, Google Style, etc.) garantiza coherencia: evita que unas funciones tengan tablas de parámetros detalladas y otras solo una línea descriptiva. El uso de delimitadores """ previene que comentarios previos del código se interpreten como instrucciones del sistema.
¿Términos desconocidos? Consulta Aha AI: few-shot, output-format
Comparado con un mal ejemplo
Comenta este código:
(código pegado)
Generará comentarios redundantes en casi todas las líneas traduciendo el código a texto plano, dificultando la lectura. Además, es común que renombre variables o altere la indentación silenciosamente, arriesgando commits con cambios no deseados.
Variaciones
Cuando ya existen comentarios pero contradicen el código
El siguiente código en {{idioma especificado}} ya cuenta con comentarios. Compara el código con dichos comentarios e identifica exclusivamente aquellos que hayan quedado desactualizados o contradigan la lógica actual. Organízalos en una tabla con las columnas: "Ubicación · Lo que dice el comentario · Lo que hace el código realmente · Comentario corregido". No incluyas los comentarios que ya sean correctos.
""" {{código fuente}} """
Un comentario desactualizado es más peligroso que la falta de comentarios. Pedir una auditoría comparativa evita que el modelo reescriba documentación que aún es válida.
Documentación general para traspaso de proyecto
Redacta el encabezado descriptivo del archivo en formato {{formato de nota}} para quien herede este código en {{idioma especificado}}. Debe explicar: 1) responsabilidad principal del módulo, 2) supuestos o datos de entrada esperados, y 3) componentes relacionados que deben revisarse al hacer cambios. Todo estructurado en ese orden y en no más de 10 líneas.
""" {{código fuente}} """
Útil para documentar la arquitectura a nivel de archivo en lugar de función por función. El límite de líneas evita resúmenes excesivamente largos o triviales.
Notas por modelo
Si introduces un archivo muy largo de golpe, los comentarios de las últimas funciones serán más escuetos. Conviene dividirlo en bloques de 5 a 6 funciones e indicar el formato en cada iteración.
Al solicitar que devuelva archivos extensos completos con comentarios, algunos modelos pueden truncar la salida o resumir partes con "...". En esos casos, es más seguro procesar bloques de 5 o 6 funciones a la vez, o solicitar únicamente una tabla con los comentarios y sus números de línea correspondientes para insertarlos manualmente.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos