¿Qué debo revisar de privacidad antes de usar un asistente de código?

Si tus prompts y código se usan para entrenar modelos (y si puedes desactivarlo), cuánto tiempo se retienen los datos, si hay logs y borrado bajo petición, y la diferencia entre plan personal y plan empresa, que suele incluir más garantías de control.

¿Cómo compruebo si un asistente entiende realmente mi repositorio?

Con pruebas cortas de 30 minutos: dale un bug real y pide un fix mínimo con test, entrégale una convención de estilo y mira si la respeta, y pídele un refactor con reglas explícitas ("no cambies la firma pública") para ver si obedece restricciones.

¿Qué permisos son más peligrosos al dar acceso a un asistente de IA?

El acceso a terminal (puede ejecutar comandos) y a red (puede llamar APIs o descargar dependencias) son los más delicados. Empieza dando solo acceso al archivo actual o autocompletado, y añade permisos de workspace completo o integraciones solo cuando tengas confianza.

¿Cuál es el coste real de un asistente de código, más allá de la suscripción?

El coste grande suele ser el tiempo de revisión: mide los minutos por PR con y sin asistente durante una semana. Si baja tu tiempo total incluyendo corregir lo que propuso, vas bien; si sube porque toca arreglar sus sugerencias, te sale caro aunque sea barato en euros.

Mejor IA para programar: cómo elegir asistente de código sin meter la pata (privacidad, contexto y coste)

GUÍAS & TUTORIALES · DESARROLLO · PRIVACIDAD

⏱️ 12–16 min de lectura Checklist práctica para probar copilotos e IDEs con cabeza: permisos, pruebas reales y cómo evitar fugas de repo y prompts

Privacidad

Qué sale de tu editor, cuánto se guarda y si puede usarse para entrenar.

Contexto

Si entiende tu repo (arquitectura, convenciones, dependencias) o solo improvisa.

Coste

Suscripción vs uso, pero también tiempo: revisiones, bugs y deuda técnica.

El error más caro con un asistente de código no es que falle un test: es que le des acceso a cosas que no debería ver.

Porque cuando metes prisas, es tentador: pegas un fragmento “rápido” del repo, sueltas un stacktrace con tokens por ahí, y listo. El problema es que, si no eliges bien (y no configuras bien), ese “rápido” puede convertirse en una fuga, una auditoría incómoda o una semana arreglando un refactor sugerido con demasiada alegría.

Vamos a hacerlo como lo haría un equipo serio: con pruebas cortas, permisos mínimos y una checklist que te deje dormir tranquilo. Y, de paso, te vas a ahorrar el clásico drama de “la IA me inventó una API” (si te suena, te va a encajar también este artículo sobre errores típicos: alucinaciones y privacidad).

1) Antes de comparar herramientas: define tu “modo” de trabajo

La pregunta “¿cuál es la mejor IA para programar?” tiene trampa: no es lo mismo querer autocompletado rápido que necesitar un copiloto que entienda un monorepo, o querer un chat para pensar arquitectura.

Para elegir sin perderte, piensa en tres escenarios (puedes usar uno o mezclarlos, pero conviene diferenciarlos):

Autocompletado y refactors pequeños: velocidad, precisión y que no te rompa el estilo del proyecto.
Chat “ingeniero”: entender contexto, discutir diseño, revisar PRs, generar tests, documentar.
Agente/IDE inteligente: ejecuta acciones (crear archivos, modificar varios módulos, correr tests) con más poder… y más riesgo si no lo controlas.

Tu elección (y tu configuración) cambia muchísimo según el modo. Si solo quieres autocompletado, probablemente no necesitas darle a nada acceso completo al repo. Si quieres un agente que arregle cosas “de extremo a extremo”, ahí entra la conversación seria de permisos y aislamiento.

2) El triángulo que manda: privacidad, contexto y coste

La mayoría de comparativas se obsesionan con “qué modelo escribe mejor”. Pero en la vida real, lo que te hace acertar (o meter la pata) es esto:

Privacidad: qué datos salen de tu máquina y bajo qué condiciones. Contexto: qué entiende de tu proyecto y cómo de consistente es. Coste: no solo dinero, también horas de revisión y bugs que te crea.

Regla rápida: si una herramienta te promete “entender todo tu repo”, asume que algo tiene que leer y algo puede salir. Tu trabajo es decidir cuánto, cómo y con qué garantías.

3) Checklist de privacidad: lo que debes revisar antes de dar permisos

Aquí no hay magia: un asistente de código funciona porque ve tu código (o parte) y tu contexto. La pregunta es: ¿qué exactamente se envía? y ¿qué pasa después?

3.1 Entrenamiento, retención y uso de tus datos

Busca (y exige) respuestas claras a estas preguntas:

¿Se usan tus prompts/código para entrenar modelos? ¿Puedes desactivarlo?
¿Cuánto tiempo se retienen los datos? ¿Hay logs? ¿Puedes pedir borrado?
¿Qué diferencia hay entre plan personal y plan equipo/empresa?

3.2 Dónde corre y por dónde viaja

No necesitas ser experto en compliance para hacerte una idea del riesgo:

¿Hay opción de nube, nube privada o local?
¿Puedes limitar regiones (residencia de datos)?
¿La herramienta permite un enfoque “chat con documentos internos” sin subirlo todo? (Aquí te puede interesar montar un chatbot privado con documentos en local para casos sensibles).

3.3 Qué permisos exactos le estás dando

Este punto se pasa por alto: muchas fugas no ocurren “porque el modelo”, sino porque una extensión tenía más permisos de la cuenta.

Lectura del workspace: ¿lee todo el repo o solo el archivo actual?
Acceso a terminal: si puede ejecutar comandos, ya estás en otro nivel de riesgo.
Acceso a red: ¿puede llamar a APIs o descargar dependencias?
Integraciones: GitHub/GitLab/Jira/Slack… ¿qué scopes estás autorizando?

4) Cómo probar el contexto sin autoengañarte (tests de 30 minutos)

La mayoría de demos funcionan porque están preparadas. Tu prueba debe parecerse a tu semana real. Aquí tienes un “pack” de pruebas rápidas que te dice si el asistente entiende tu proyecto o solo te da respuestas bonitas.

4.1 Prueba A: bug real + fix mínimo

Elige un bug que ya exista (o un issue pequeño). Pídele:

que identifique el archivo y la función probable,
que proponga un fix con cambios mínimos,
y que añada un test que falle antes y pase después.

Si te sugiere tocar medio proyecto para arreglar un bug pequeño, mala señal: no entiende límites ni impacto.

4.2 Prueba B: “respeta mi estilo”

Dale una convención que sea importante para ti (nombres, estructura, lint, arquitectura por capas) y pídele un cambio en un módulo. Evalúa si:

mantiene los patrones existentes,
no inventa utilidades que ya existen,
y no mete dependencias nuevas por deporte.

4.3 Prueba C: refactor con “contrato”

Pídele un refactor con reglas: “no cambies firma pública”, “no toques X carpeta”, “mantén compatibilidad”. Un buen asistente no es el que reescribe todo: es el que obedece restricciones y documenta trade-offs. Si quieres mejorar cómo formulas estas instrucciones, te va a ayudar esta guía de prompts para ChatGPT y Gemini (aunque aquí lo aplicamos a código).

5) Configuración segura: permisos mínimos y hábitos que evitan sustos

Da igual lo buena que sea la herramienta: si la usas “a lo loco”, te vas a meter en un lío. Aquí van prácticas que reducen riesgo sin matarte la productividad.

5.1 El mínimo viable (para empezar)

Empieza con archivo actual + autocompletado. No des acceso total al workspace el día 1.
Desactiva (o limita) funciones de ejecución en terminal hasta tener confianza y políticas.
Evita integraciones extra al inicio. Cada integración es otra puerta.

5.2 Higiene de prompts (sí, también en programación)

Tu prompt puede filtrar más que tu código. Reglas simples:

Nunca pegues secrets (tokens, llaves, credenciales). Si hay dudas: asume que es secreto.
No pegues dumps con datos personales o de clientes. Si necesitas contexto, anonimiza.
Evita “pega aquí todo mi repo”. Mejor: describe el contrato, pega interfaces y añade trozos mínimos.
Cuando la IA proponga cambios grandes, pídele plan primero, luego commits pequeños.

Truco práctico: crea un “prompt de cabecera” para tu proyecto (convenciones, arquitectura, limitaciones). Lo reutilizas y reduces la tentación de pegar contexto sensible cada vez.

6) Coste real: el precio que se ve y el que se esconde

Cuando comparas herramientas, es fácil quedarse con “X €/mes”. Pero en programación, el coste grande suele ser otro: tiempo de revisión y errores que entran en producción.

6.1 La métrica que importa: minutos por PR

Haz un experimento de una semana: mide cuánto tardas en cerrar PRs similares con y sin asistente. Si baja tu tiempo total (incluyendo revisar, adaptar y corregir), vas bien. Si sube porque “toca arreglar lo que propuso”, te está saliendo caro aunque sea barato.

6.2 El coste del contexto: cuanto más metes, más pagas (de una forma u otra)

Cada vez que envías más contexto, aumentas coste (directo o indirecto) y riesgo. Por eso, muchas empresas terminan usando arquitecturas más controladas: en vez de “todo en el prompt”, van a enfoques que recuperan solo lo relevante. Si quieres ponerle nombre a esa decisión, te va a encajar este mapa para elegir entre RAG vs fine-tuning vs agentes.

7) Patrones “sin meter la pata” para equipos (cuando el repo importa)

Si trabajas con código sensible (propietario, regulado, cliente grande), suele funcionar mejor pensar en diseño que en “qué extensión instalo”. Tres patrones típicos:

7.1 Gateway/Proxy: un único punto de control

En vez de que cada editor hable directamente con el proveedor, pasas por un gateway: logs controlados, políticas de redacción, límites de contexto, y posibilidad de bloquear datos sensibles (por ejemplo, patrones tipo AWS_SECRET o archivos .env).

7.2 “Contexto por demanda”: RAG interno para docs, no para secretos

Mucho del contexto que la IA necesita no es “código entero”, sino documentación interna, decisiones de arquitectura, contratos de APIs, ejemplos. Recuperas lo relevante y reduces el impulso de pegar trozos enormes.

7.3 Local/híbrido: cuando el perímetro manda

Hay equipos que prefieren que ciertas tareas se queden en local (o en infraestructura propia): autocompletado, búsqueda semántica del repo, análisis de patrones. No siempre es “lo mejor” en calidad, pero puede ser “lo mejor” en control. La clave es elegir conscientemente qué haces local y qué mandas fuera.

8) Checklist final: la decisión en 15 minutos

Si solo haces una cosa hoy: instala dos opciones, pásalas por estas preguntas y elige la que gane por “calidad con control”, no por hype.

Privacidad: ¿puedo desactivar entrenamiento/retención? ¿qué permisos pide? ¿lee repo entero?
Contexto: ¿pasa la prueba del bug real, respeta convenciones y obedece restricciones?
Coste real: ¿reduce minutos por PR o me crea deuda? ¿cuánto reviso lo que sugiere?
Control: ¿puedo limitar acceso a terminal/red? ¿puedo auditar lo que se envía?
Salida segura: ¿me ayuda a escribir tests, docs y refactors pequeños en vez de “reescribir el universo”?

La mejor IA para programar no es la que “escribe más”, sino la que te hace más rápido sin volverte imprudente. Si eliges bien, el asistente se convierte en un compañero de equipo. Si eliges mal, es un becario hiperactivo con acceso a llaves maestras. Y ya sabes: en ingeniería, los sustos suelen venir más por permisos que por líneas de código.