💡 Buenas Prácticas y Ahorro de Tokens

1.1. Autocompletado y NES antes de abrir el chat

No todo requiere iniciar una conversación. El autocompletado básico de código en tu editor y las sugerencias de la siguiente edición (Next Edit Suggestions) resuelven de forma instantánea tareas repetitivas como terminar una línea, generar boilerplate simple, mapear DTOs o escribir condiciones. En planes de pago, estas funciones no consumen créditos de IA.

1.2. Elige el modelo adecuado para cada tarea

Usar el modelo más potente y costoso para preguntar cómo centrar un div o generar una estructura básica es un desperdicio de recursos. La recomendación oficial es clara: mantén Auto como predeterminado (deja que el sistema determine la complejidad) y cambia manualmente a un modelo de razonamiento profundo solo cuando te enfrentes a algoritmos complejos o depuración multifichero.

2.1. Inicia nuevos chats al cambiar de tarea

Este es uno de los errores más comunes. A medida que un chat se alarga, acumula contexto de mensajes anteriores, outputs de herramientas y código ya revisado. Si cambias de tarea (por ejemplo, pasas de depurar un test a escribir documentación) en la misma sesión, el modelo seguirá leyendo y procesando todo el historial irrelevante, cobrándote miles de tokens innecesarios.

Chat 1 (Sesión única gigante):
- Depurar tests
- Luego diseñar arquitectura
- Luego generar README
- Luego revisar Dockerfile
- Luego explicar un error de Azure
- Luego pedir que escriba un tweet

Chat 1: Depurar tests
Chat 2: Diseño de arquitectura del servicio
Chat 3: Generar documentación README
Chat 4: Configurar y optimizar Dockerfile
Chat 5: Resolver problema de despliegue en Azure

2.2. Usa /compact y /fork cuando sea necesario

Si estás en una sesión de trabajo larga y el contexto empieza a ser gigantesco, pero hay información útil acumulada que no quieres perder, no necesitas empezar de cero totalmente a ciegas. Puedes usar comandos de compactación o pedirle al modelo un resumen del estado actual para copiarlo en una sesión nueva y limpia.

Summarize the current state, decisions made, files changed, and next steps. Keep it short and actionable.

2.3. No envíes todo el repositorio si solo necesitas tres archivos

Evita las consultas de alcance infinito que fuercen al modelo a realizar búsquedas vectoriales masivas en todo tu proyecto. Especificar con qué archivos exactos quieres trabajar limita de inmediato el consumo de tokens y reduce drásticamente las alucinaciones de la IA.

Analiza todo este repositorio y dime qué está mal.

Analiza únicamente estos archivos:
- src/MyApp.Api/Program.cs
- src/MyApp.Core/Services/OrderService.cs
- tests/MyApp.Tests/OrderServiceTests.cs

Objetivo: Encontrar por qué falla el test de OrderService.
No modifiques ningún archivo todavía. Explica primero la causa probable.

3.1. Separa planificación, implementación y validación

Pedirle a un agente de IA que "analice, diseñe, implemente, corra tests, corrija errores y documente todo a la vez" es una receta para bucles infinitos de herramientas y facturas astronómicas. La clave es trabajar en fases lógicas e independientes:

<!-- Fase 1: Planificar -->
"Crea un plan de implementación corto. No modifiques archivos todavía. Concéntrate en la ruta de código mínima."

<!-- Fase 2: Implementación acotada -->
"Implementa el paso 1 únicamente. Modifica solo los archivos listados en el plan."

<!-- Fase 3: Validación -->
"Ejecuta solo los tests relevantes. Si fallan, explica el error antes de cambiar más código."

3.2. Cuidado con los logs y usa herramientas tradicionales primero

Los logs de compilación o de ejecución de tests son los asesinos silenciosos del presupuesto de tokens. Pegar un log de 2,000 líneas cuando el error real se describe en las últimas 20 es sumamente costoso. Limita el volcado a las líneas significativas.

Además, deja que las herramientas tradicionales hagan su trabajo. Deja que tu linter corrija el estilo, que tu formateador ordene las llaves, y que el compilador te muestre los errores de tipo. No consumas tokens para tareas que se pueden resolver de forma local y determinista en milisegundos.

4.1. Mantén tus instrucciones personalizadas cortas y vigentes

Los archivos de instrucciones personalizadas (como .github/copilot-instructions.md o similares) viajan con cada una de tus solicitudes al servidor. Si este archivo es una constitución nacional gigante con reglas obsoletas y directivas contradictorias que nadie sigue, estarás pagando un peaje innecesario en cada prompt.

# Instrucciones de Copilot
- Usa convenciones de C# 13 y .NET 10.
- Mantén los cambios mínimos y enfocados.
- No agregues dependencias sin explicar la razón.
- Ejecuta `dotnet build -c Release` tras modificar código.
- Prefiere los valores por defecto de Aspire al añadir servicios.
- No modifiques archivos autogenerados.

4.2. Gestiona tus servidores y herramientas MCP

Model Context Protocol (MCP) es extremadamente potente para dotar de herramientas a tus agentes. No obstante, cada servidor MCP activo añade descripciones de herramientas que incrementan el espacio de decisión y el tamaño del contexto. Si estás programando una API en local, desactiva servidores de Jira, Slack o búsquedas en la nube que no vayas a necesitar.

4.3. Aprovecha la potencia de los modelos locales

Para tareas sencillas y repetitivas, como formatear logs, generar drafts de documentación técnica básica, o traducir código, puedes utilizar herramientas locales como Ollama en lugar de enviar peticiones a la nube. Esto no solo es completamente gratuito, sino que además garantiza una privacidad absoluta de tus datos y código fuente.

5.1. Uso estratégico de la revisión de código por IA (Code Review)

Las herramientas de revisión automática de código de Copilot o similares consumen gran volumen de tokens y minutos de CI/CD. Activar revisiones exhaustivas y automatizadas en cada commit de cada rama de pruebas es inviable. Limita el uso del revisor de IA a Pull Requests terminadas y significativas, y apóyate en analizadores estáticos locales primero.

5.2. Definir perfiles de uso por tipo de tarea

En lugar de dar total libertad sin guías en equipos grandes, establece directrices claras para los tipos de tareas comunes: