Qué se transfiere realmente
La superficie de personalización de Copilot tiene cinco capas, y solo tres de ellas son archivos.
Instrucciones personales. La documentación es explícita tanto sobre el alcance como sobre la ubicación: solo son compatibles con "GitHub Copilot Chat en GitHub", se configuran "en una ventana emergente en la página de Copilot Chat en GitHub.com" y Copilot "solo las aplicará" a ti. No hay ningún archivo. No hay ningún repositorio. Hay un cuadro de texto en una página web, por persona.
Instrucciones personalizadas del repositorio, de las cuales hay tres tipos. Instrucciones para todo el repositorio en un archivo copilot-instructions.md en el directorio .github. Instrucciones específicas de la ruta en uno o más archivos que terminan en .instructions.md dentro o debajo de .github/instructions. Y las instrucciones del agente, que la documentación describe como "similares a las instrucciones personalizadas para todo el repositorio, pero actualmente no son compatibles con todas las funciones de Copilot", especificadas en archivos llamados AGENTS.md, CLAUDE.md o GEMINI.md.
Instrucciones personalizadas de la organización, configuradas por los propietarios de la organización en los ajustes de Copilot y aplicadas —en palabras de la documentación— "para todos los miembros de la organización, independientemente de si reciben su suscripción de Copilot de esa organización".
Ahora, el orden en que se resuelven:
"Se pueden aplicar varios tipos de instrucciones personalizadas a una solicitud enviada a Copilot. Las instrucciones personales tienen la prioridad más alta. Las instrucciones del repositorio van a continuación y, por último, se priorizan las instrucciones de la organización. Sin embargo, todos los conjuntos de instrucciones relevantes se proporcionan a Copilot."
Esa última frase es la que la gente suele pasar por alto. La precedencia resuelve conflictos; no elimina capas. Se siguen enviando todas las instrucciones aplicables. Por lo tanto, una instrucción personal que contradiga un estándar de la organización no lo reemplaza: lo supera en rango, mientras que ambos permanecen en el contexto.
Por el lado de Tabnine, las superficies equivalentes son las directrices (guidelines). La documentación las describe como "archivos Markdown almacenados en el directorio /.tabnine/guidelines/ de tu proyecto" y señala que el directorio puede residir en tu directorio de inicio o por proyecto. Su propia analogía para ellos: "Piensa en ellos de manera similar al archivo agents.md que usan otras herramientas de agentes". El consejo sobre el tamaño es "mantén tu archivo guidelines.md en 500 líneas o menos".
Luego, la frase que invierte tu migración. Al describir las directrices introducidas en la Consola de Administración:
"Las directrices que se introduzcan aquí tendrán el mismo efecto que las directrices enumeradas en tu archivo guidelines.md, pero tendrán precedencia sobre las directrices personales que existan en el archivo guidelines.md."
Por lo tanto: los archivos se transfieren. El alcance específico de la ruta se transfiere, aproximadamente, ya que Tabnine admite múltiples archivos de directrices. Lo que no se transfiere es el orden de resolución. Y lo que no tiene ningún destino en absoluto es la ventana emergente: las instrucciones por persona que nunca estuvieron en un repositorio, nunca se revisaron y nunca fueron visibles para nadie más.
Vale la pena separar de todo esto: ninguna de estas capas es el conocimiento de la base de código. Los archivos de instrucciones le dicen al asistente cómo comportarse, no qué contiene tu código, razón por la cual el hecho de que Copilot olvide el contexto de la base de código es una queja diferente a la de que Copilot ignore tus reglas. La respuesta de Tabnine al primer problema es la Personalización y su función Connection; su respuesta al segundo son las directrices. No migres uno esperando solucionar el otro.
Hay una segunda diferencia estructural que vale la pena conocer antes de planificar el trabajo, porque divide a tu equipo en dos. La CLI de Tabnine no lee el directorio de directrices del proyecto de la misma manera que lo hace el complemento del IDE. Su documentación comienza exponiendo claramente la diferencia:
"Las directrices del agente se gestionan de forma diferente en la CLI de Tabnine que en el complemento de IDE de Tabnine."
En la CLI hay dos flujos. Las instrucciones de la organización y de la cuenta de servicio se "añaden al contexto operativo del agente", y se obtienen automáticamente para tu cuenta autenticada cuando se inicia la CLI. Por separado, se puede acceder a las directrices de codificación a través de una herramienta integrada Tabnine Coaching Guidelines que el agente llama cuando necesita reglas específicas del lenguaje. La documentación tiene cuidado de separar ambas cosas, porque el interruptor solo rige una de ellas:
"Esta configuración no controla si las instrucciones de la organización o de la cuenta de servicio se obtienen y se añaden al contexto de la sesión."
La migración manual
Dos pasos, y el primero es el que todo el mundo se salta.
Paso 1: Extraer las instrucciones personales de la ventana emergente
Antes de tocar un solo archivo, pide a cada persona del equipo que abra la página de Copilot Chat en GitHub.com y te lea sus instrucciones personales en voz alta. No parafrasear: leer.
Esto parece un trabajo rutinario, pero es la hora de mayor valor de toda la migración, por dos razones. Primero, las instrucciones personales están en la cima del orden de precedencia de Copilot, lo que significa que lo que esté allí ha estado ganando silenciosamente los conflictos contra los estándares de tu repositorio y la configuración de tu organización. Segundo, son invisibles: no hay ningún archivo para buscar con grep, ninguna PR para revisar, ningún registro de auditoría. Si alguien escribió "usar siempre la biblioteca de cliente más antigua, la nueva rompe nuestro proxy" hace ocho meses, esa instrucción ha estado dando forma a sus resultados desde entonces y nadie más sabe que existe.
Clasifica lo que salga en dos montones. Las preferencias personales genuinas (idioma de respuesta, nivel de detalle, explicar un concepto por línea) siguen siendo personales. Los datos del proyecto disfrazados de preferencia personal van al repositorio, porque ahí es donde siempre debieron estar. Este es el mismo modo de fallo que hay detrás de los agentes que ignoran tus archivos de instrucciones: la instrucción que gana no es la que crees haber escrito.
Mientras estás en esa ventana emergente, ten en cuenta que la otra superficie por usuario de Copilot —la función de memoria en el IDE, tratada en la configuración de la memoria de Copilot en VS Code— también es por persona y tampoco es un archivo. Lee esas también.
Paso 2: Reconstruir las capas de archivos como directrices y luego volver a decidir cada conflicto
Ahora viene la copia, que es mecánica, seguida de la parte que no lo es.
Tu archivo copilot-instructions.md para todo el repositorio se convierte en un archivo de directrices en .tabnine/guidelines/. Tus archivos .instructions.md específicos de la ruta se convierten en archivos de directrices adicionales; Tabnine lee múltiples archivos del directorio, así que mantenlos separados en lugar de fusionarlos y nómbralos según lo que cubren. Tu AGENTS.md puede quedarse exactamente donde está, porque es una convención abierta que leen otras herramientas de tu pila; solo ten en cuenta que el directorio de directrices de Tabnine es al que apunta su propia documentación. Si tus archivos de instrucciones comenzaron su vida al otro lado de esa valla, mover un CLAUDE.md a Copilot cubre la forma en que llegaron.
Una corrección gratuita mientras estás aquí. La documentación de Tabnine escribe la analogía en minúsculas, como agents.md. Otras herramientas que leen la misma convención requieren el nombre de archivo en mayúsculas y omitirán silenciosamente uno en minúsculas. En un repositorio compartido entre herramientas, nómbralo AGENTS.md.
Luego, el trabajo real. Para cada lugar donde el estándar de tu organización y la instrucción personal de alguien no estuvieran de acuerdo, ahora tienes que elegir un ganador, porque la consola de administración de Tabnine elegirá uno por ti y elegirá lo contrario de lo que eligió Copilot. Revisa los conflictos uno a uno y decide qué capa debe contener cada regla. Cualquier cosa que sea genuinamente un estándar de la organización va a la consola de administración, donde ahora supera en rango al archivo local de todos; y ten en cuenta el retraso de propagación que menciona la documentación: los cambios "se aplicarán en la extensión del IDE después de 15 minutos, o al reiniciar el IDE o la extensión".
Aquí también es donde descubres lo que ninguna guía de migración puede hacer por ti. Decidir qué regla gana requiere saber por qué existe cada regla, y esa información no está en ninguna de las dos herramientas.
La mejor manera: una capa de decisión que ninguna consola de administración puede sobrescribir
Los conflictos que estás resolviendo en el Paso 2 solo son difíciles porque las razones nunca se escribieron. "Usar la biblioteca de cliente más antigua" frente a "estandarizar en el SDK actual" es irresoluble como dos imperativos. Es trivial una vez que sabes que uno de ellos se escribió la semana en que se rompió el proxy y el proxy se reemplazó en junio.
MemoryLake mantiene esa capa —las decisiones, las alternativas rechazadas y las razones— fuera de ambas herramientas, y las sirve a cualquier agente que las solicite a través de MCP o la API. Tus directrices siguen siendo cortas e imperativas en .tabnine/guidelines/, tu consola de administración contiene los estándares y el "porqué" detrás de cada uno es consultable por cualquier persona en cualquier herramienta.
Paso 1: Crear una clave API
Genera una clave y realiza tu primera solicitud en unos treinta segundos. Haz esto antes del Paso 2 anterior, para que tengas un lugar donde registrar cada conflicto a medida que lo resuelves.

Paso 2: Subir tus primeras memorias
Para cada regla que hayas conservado, escribe qué se decidió, qué se descartó y por qué. Las instrucciones personales que recopilaste en el Paso 1 son la fuente más rica aquí; la mayoría de ellas codifican un incidente real. Los documentos y archivos de soporte van al mismo lugar.

Paso 3: Conectar tu IA y agentes
Dale acceso a Tabnine, Claude, Codex y tus otros agentes a través de MCP o la API. Cuando se proponga el próximo estándar, la respuesta a "¿no intentamos eso ya?" llegará con su razonamiento adjunto.

Qué cambia esto en la práctica
El primer cambio es que la capa invisible deja de ser invisible. La superficie de instrucciones de mayor prioridad de Copilot era un cuadro de texto por persona; después de esta migración, el contenido equivalente es una preferencia personal explícita o una decisión de proyecto registrada, y el segundo tipo es legible por todo el equipo.
El segundo es que la precedencia de la consola de administración se convierte en una característica en lugar de una trampa. Una vez que los estándares organizacionales son genuinamente organizacionales (revisados, razonados, registrados), lo que deseas es que superen en rango a los archivos locales. La inversión solo perjudica cuando la consola de administración contiene suposiciones.
El tercero es que la división entre IDE y CLI deja de fragmentar a tu equipo. Los desarrolladores en el IDE leen archivos de directrices; los desarrolladores en la CLI obtienen instrucciones de la organización y de la cuenta de servicio, además de la herramienta Coaching Guidelines. Esos son mecanismos diferentes, y una capa de razonamiento compartida que ambas partes puedan consultar es lo que hace que sus respuestas coincidan.
El cuarto es que la próxima migración será realmente una copia de archivos. La parte que hizo difícil esta —reconstruir la intención a partir de imperativos— ocurre una sola vez. Esta es la misma razón por la que lo que realmente leen los agentes de codificación importa más que el formato de archivo que prefiera una herramienta determinada.
Buenas prácticas después de mudarse a Tabnine
Audita la ventana emergente antes de auditar los archivos. Las instrucciones personales tienen la máxima prioridad en Copilot y no dejan rastro de archivos. Son la única parte de tu antigua configuración que no se puede reconstruir más tarde.
Coloca los estándares en la consola de administración y las preferencias en el archivo local. El orden de precedencia ahora premia esa división, y luchar contra ella duplicando los estándares localmente solo crea conflictos que la consola ganará de todos modos.
Mantén los archivos de directrices cortos y separados. La documentación recomienda 500 líneas o menos por archivo, y el directorio admite múltiples archivos. Un tema por archivo es mejor que un solo archivo largo.
Recuerda el retraso de propagación. Los cambios en la consola de administración llegan a la extensión del IDE después de una espera o un reinicio. Cuando cambie un estándar, infórmalo a la gente en lugar de asumir que lo vieron.
No asumas que la CLI ve las directrices de tu proyecto. Los flujos documentados de la CLI son las instrucciones de la organización y de la cuenta de servicio, además de la herramienta Coaching Guidelines. Si tu equipo está dividido entre ambas superficies, verifica qué está cargando realmente cada una.
Usa AGENTS.md en mayúsculas. El ejemplo en minúsculas de un proveedor es la omisión silenciosa de otro, y no cuesta nada hacerlo bien.
Escribe la razón junto a la regla. Cada conflicto que resolviste en esta migración existía porque alguien escribió un imperativo sin su causa. El próximo también lo hará, a menos que la razón tenga un lugar donde vivir.
Conclusión
La migración de GitHub Copilot a Tabnine mueve tres capas de archivos de forma limpia e invierte la única cosa que no puedes ver. Copilot documenta las instrucciones personales como su prioridad más alta y las instrucciones de la organización como la más baja, mientras sigue enviando cada capa aplicable al modelo. Tabnine documenta que la consola de administración tiene precedencia sobre el archivo personal guidelines.md. Copia los archivos sin abordar eso, y las reglas que solían ganar comenzarán a perder, silenciosamente, con las mismas entradas.
El trabajo que hace que la migración sea segura no es la copia. Consiste en vaciar la ventana emergente, separar las preferencias genuinas de los datos del proyecto y decidir qué capa debe ser propietaria de cada regla, lo cual solo puedes hacer si sabes por qué existen las reglas. Registra eso una vez, fuera de ambas herramientas, y cada movimiento futuro se convertirá en lo que este parecía desde fuera: mover un poco de markdown e iniciar sesión.